From iukaccent at seh.com Tue Oct 23 08:07:23 2007 From: iukaccent at seh.com (Hazel Raines) Date: Tue, 23 Oct 2007 16:07:23 +1000 Subject: ***SPAM*** Energy fur ihren Schwanz, kaufen und 85% sparen Message-ID: <01c8158e$cc066690$da1cf0dc@iukaccent> Sie leben nur einmal - warum dann nicht was neues ausprobieren? Original - 100% wirksam Ciiiaaaaaalis 10 Pack. 26,99 Euro Viiiaaaagra 10 Pack. 20,99 Euro - Diskrete Verpackung und Zahlung - Kein peinlicher Arztbesuch erforderlich - Kostenlose, arztliche Telefon-Beratung - Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen - Bequem und diskret online bestellen. - Visa verifizierter Onlineshop - keine versteckte Kosten Mit unseren Produkten vergessen Sie Ihre Enttauschungen, anhaltende Versagensangste und wiederholte peinliche Situationen Vier Dosen gibt's bei jeder Bestellung umsonst
Spamit.com
(bitte warten Sie einen Moment bis die Seite vollstandig geladen wird) -------------- nächster Teil -------------- Ein Dateianhang mit HTML-Daten wurde abgetrennt... URL: http://lists.mushaake.org/pipermail/mysql-de/attachments/20071023/2ce2f5e0/attachment.html From tobias at gfz-potsdam.de Thu Oct 25 17:24:35 2007 From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana) Date: Thu, 25 Oct 2007 17:24:35 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... Message-ID: <4720B533.9030409@gfz-potsdam.de> Hallöchen, ich habe erfoglreich ein Replikations-System (Master-Slave) aufgezogen. Nun möchte ich folgendes umsetzen (da die Datenbank sehr schnell sehr voll läuft - hohe Perfomance) Ein Haupt MySQL-Server soll Daten der letzten 7 Tage vorrätig halten. Ein zweiter MySQL-Server soll ALLE Daten vorrätig haben. So weit so gut & einfach ;-) Doch sollen beide zu jedem Zeitpunkt aktuell sein. Was in den 1. geschrieben/gelöscht wird, soll auch in den 2. geschrieben/gelöscht werden... MASTER (7 Tage) und SLAVE (alle Daten) geht nicht, da ich alle Daten, die älter als 7 Tage sind, auch auf dem SLAVE verliere...(-> Replikation) MASTER (alle Daten) und SLAVE (7 Tage) geht nicht, da die Replikation nicht in "Echtzeit" vollzogen wird und es dann zu ungewollten Verzögerungen beim Slave kommt. Ist ein Cluster die einzige Alternative??? Oder gäbe es eine MASTER (7 Tage) und SLAVE (alle Daten) Option, in der die Daten auf dem Slave, die älter als 7 Tage sind, NICHT gelöscht werden (über Rechte Managment)!? -- Tobias ------------------------------ Tobias Mueller-Wrana GFZ Potsdam, Sektion 2.4, E251 Telegrafenberg. D-14773 Potsdam Tel.: +49-(0)331-288-1241 ------------------------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From mysql at universalware.de Thu Oct 25 17:52:30 2007 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Thu, 25 Oct 2007 17:52:30 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <4720B533.9030409@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de> Message-ID: <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> Hallo Tobias, die Frage die sich mir hier sofort stellt ist: Was bedeutet "voll läuft". Ich habe noch keine MySQL Datenbank gesehen die abgesehen vom verfügbaren Plattenplatz vollgelaufen wäre. Eine MySQL interne Lösung für deine Idee gibt es so nicht. Da ich aber zu wenig vom eigentlichen Problem weiss kann ich auch keinen alternativen Vorschlag machen. Gruß, Andreas _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From tobias at gfz-potsdam.de Thu Oct 25 17:58:32 2007 From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana) Date: Thu, 25 Oct 2007 17:58:32 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> Message-ID: <4720BD28.2020002@gfz-potsdam.de> Hallo Andreas, also mit >>voll laufen<< meine ich, dass Abfragen bei einer vollen Datenbank zu lange dauern. Ich spreche hier von Antworten von wenigen Skunden bis max. 1 min. Wenn das System 1 Woche läuft, wird die Antwortzeit sichtlich langsamer. Daher der Wunsch nach einer >>7 Tages<< Datenbank und wegen der kostbaren Daten eine >>vollständige<< Datenbank. Beide sollen aber immer auf dem aktuellsten Stand sein. Ich hatte daher an Replikation gedacht... > die Frage die sich mir hier sofort stellt ist: Was bedeutet "voll läuft". > Ich habe noch keine MySQL Datenbank gesehen die abgesehen vom verfügbaren > Plattenplatz vollgelaufen wäre. > Bin auch für "tolle" Cronjob / Skript Lösungen zu haben. Jedoch scheidet ein >>Datenbank runterfahren<< aus... -- Tobias ------------------------------ Tobias Mueller-Wrana GFZ Potsdam, Sektion 2.4, E251 Telegrafenberg. D-14773 Potsdam Tel.: +49-(0)331-288-1241 ------------------------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From ks at codebiz.de Thu Oct 25 18:03:32 2007 From: ks at codebiz.de (Kai Szymanski) Date: Thu, 25 Oct 2007 18:03:32 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <4720BD28.2020002@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> Message-ID: <4720BE54.3030202@codebiz.de> Hallo Tobias! Auf was (Raid ? Einzelne Festplatte ?) liegt Deine Datenbank. Wenn auf einem Raid, was für ein Raidtyp ? Es kommt auch ganz stark darauf an, wie Deine Tabelle und Daten aussehen und mit was für Abfragen die der Datenbank kommst. We need more Input ;) CU, Kai. _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From tobias at gfz-potsdam.de Thu Oct 25 18:09:20 2007 From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana) Date: Thu, 25 Oct 2007 18:09:20 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <4720BE54.3030202@codebiz.de> References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <4720BE54.3030202@codebiz.de> Message-ID: <4720BFB0.2050901@gfz-potsdam.de> Hallo Kai, die MySQL DB läuft noch auf einem StandAllone System (SuSE 10.2). Wir sind offen, für andere System. Folgende Ansprüche haben wir: - Schnelle Queries fuer das operationale Echtzeitsystem (~ 1 Woche) - Verfuegbarkeit aller Daten auf moeglichst lange Dauer - beide System stets aktuell > Auf was (Raid ? Einzelne Festplatte ?) liegt Deine Datenbank. Wenn auf > einem Raid, was für ein Raidtyp ? Es kommt auch ganz stark darauf an, > wie Deine Tabelle und Daten aussehen und mit was für Abfragen die der > Datenbank kommst. We need more Input ;) > Die Replikations-Idee basiert bisher nur auf meinen Überlegungen. Daher sind wir, was die Umsetzung angeht sehr offen (->CODA etc.). -- Tobias ------------------------------ Tobias Mueller-Wrana GFZ Potsdam, Sektion 2.4, E251 Telegrafenberg. D-14773 Potsdam Tel.: +49-(0)331-288-1241 ------------------------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From mysql at universalware.de Thu Oct 25 18:29:43 2007 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Thu, 25 Oct 2007 18:29:43 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <4720BD28.2020002@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> Message-ID: <061101c81724$400155f0$8119fea9@nbandreas> Hallo Tobias, also wie schon sicher gesehen da fehlt einfach noch ne Menge Info: - Art der Daten und Art des Anfalls - Art der Abfrage - Anzahl Datensätze - Datenvolumen Ich kann dir verraten ich habe z.B. bei einem Kunden eine Datenbank (InnoDB, rund 60 GB Daten) mit eine Tabelle mit über 100 Millionen Datensätzen auf der man in Echtzeit arbeiten kann. Daher glaube ich weniger an ein MySQL Performance Problem sondern vorerst an ein konzeptionelles Problem. Denn eins muss man MySQL lassen - es ist auch geicher Hardware im vergleich zu anderen System nun wirklich flott. Gruß, Andreas _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Thu Oct 25 20:14:21 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Thu, 25 Oct 2007 20:14:21 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <4720B533.9030409@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de> Message-ID: <4720DCFD.3030600@sebastianmendel.de> Tobias Mueller-Wrana schrieb: > Hallöchen, > > [...] da die Datenbank sehr schnell sehr voll läuft - hohe Perfomance) > Ein Haupt MySQL-Server soll Daten der letzten 7 Tage vorrätig halten. > Ein zweiter MySQL-Server soll ALLE Daten vorrätig haben. hast du schon mal an eine MERGE Tabelle gedacht? tabelle1 mit den 7-Tage Daten tabelle2 mit den 'alten' eine MERGE tabelle über beide obige und ein nächtliches script welches die 'alt gewordenen' Daten aus Tabelle 1 in Tabelle 2 verschiebt dann kannst du entweder die aktuellen, die alten oder alle daten abfragen ... wobei die MERGE Tabelle auch durch UNION zu lösen wäre ... aber wie auch die anderen schrieben würde ich eher erstmal die Abfragen und das Db-Design überprüfen ... -- Sebastian _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From tobias at gfz-potsdam.de Fri Oct 26 09:15:30 2007 From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana) Date: Fri, 26 Oct 2007 09:15:30 +0200 Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <061101c81724$400155f0$8119fea9@nbandreas> References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <061101c81724$400155f0$8119fea9@nbandreas> Message-ID: <47219412.4040008@gfz-potsdam.de> Hallo Ihr, Also etwas zum Layout (kann man hier auch Dateien anhängen?): Es sind ca. 42 Tabellen mit je ca. 20 Variablen. Es sind Metadaten aus den Bereichen strings, double, ints usw. Keine Binärdateien. Die Abfrage läuft über vorgefertigte Wrappe in C. Ich habe die DB ca. 'ne knappe Woche laufen lassen, Dabei entstand ein Datenvolumen von knapp 5-10GB. a) sind wir bemüht diese auszumisten, d.h. man könnte das Volumen evtl. auf 3-5GB pro Woche reduzieren b) wenn man das für ein paar Monate / Jahre hoch rechnet.... :-( Aus diesem Grund wollten wir ja eine "7 Tages" Datenbank. Eine extrem lang laufende Abfrage (so in der Art) als Bsp.: select * from Tabelle1, Tabelle2 where Tabelle1.id=Tabelle2.id and Tabelle2.id not in (select distinct(id) from Tabelle3); Anmerkung: Das ist die Abfrage, die wir bräuchten um den "Müll" aus der DB zu entfernen... (Alles was in T1 & T2 ist, aber nicht mit T3 assoziiert, soll raus). Sie dauert ein paar Stündchen *gähn* und legt somit das Echtzeitproblem lahm. @Sebastian: Das konzeptionelle Problem(?) stammt a) nicht von mir und b) wird schwierig sein es generell zu ändern. :-( MERGE habe ich noch nicht ausprobiert. Werde mich mal belesen. Doch mit einem nächtlichen Cronjob/Skript muss hoffentlich nicht die DB runtergefahren werden, denn sie muss 24/7 einsatzbereit sein. Ist MERGE eine Liveupdate? Und ginge MERGE auch über mehrere Tabellen? Wenn ja, könnte man die Replikation ja, über die 7 Tages Tabellen laufen lassen? -- Tobias ------------------------------ Tobias Mueller-Wrana GFZ Potsdam, Sektion 2.4, E251 Telegrafenberg. D-14773 Potsdam Tel.: +49-(0)331-288-1241 ------------------------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From lists at sebastianmendel.de Fri Oct 26 10:03:32 2007 From: lists at sebastianmendel.de (Sebastian Mendel) Date: Fri, 26 Oct 2007 10:03:32 +0200 Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <47219412.4040008@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <061101c81724$400155f0$8119fea9@nbandreas> <47219412.4040008@gfz-potsdam.de> Message-ID: <47219F54.5030805@sebastianmendel.de> Tobias Mueller-Wrana schrieb: > Eine extrem lang laufende Abfrage (so in der Art) als Bsp.: > > select * from Tabelle1, Tabelle2 where Tabelle1.id=Tabelle2.id and > Tabelle2.id not in (select distinct(id) from Tabelle3); ich kenn mich nicht 100% aus bei ... NOT IN (SELECT ...) aber ich würde vermuten das MySQL es hier eher schwer hat den Index vernünftig zu verwenden ... vielleicht wäre folgendes etwas schneller: SELECT * FROM Tabelle1 LEFT JOIN Tabelle2 USING (id) LEFT JOIN Tabelle3 USING (id) WHERE ISNULL(Tabelle3.id) oder HAVING ISNULL(Tabelle3.id) > Anmerkung: Das ist die Abfrage, die wir bräuchten um den "Müll" > aus der DB zu entfernen... (Alles was in T1 & T2 ist, aber nicht mit > T3 assoziiert, soll raus). Sie dauert ein paar Stündchen *gähn* und > legt somit das Echtzeitproblem lahm. okay, nur um sicher zu sein, ein EXPLAIN hast du aber schonmal probiert? und ich vermute mal die ganzen CACHE und Speichereinstellungen wurden schon überprüft? (tmp_table_size, key_cache, sort_buffer, table_cache, ...) > @Sebastian: Das konzeptionelle Problem(?) stammt a) nicht von mir und > b) wird schwierig sein es generell zu ändern. :-( > > MERGE habe ich noch nicht ausprobiert. Werde mich mal belesen. Doch mit > einem nächtlichen Cronjob/Skript muss hoffentlich nicht die DB > runtergefahren nein, ein ganz normales Script welches per SQL alte Daten in die andere Tabelle verschiebt ... > werden, denn sie muss 24/7 einsatzbereit sein. > Ist MERGE eine Liveupdate? Und ginge MERGE auch über mehrere Tabellen? > Wenn ja, könnte man die Replikation ja, über die 7 Tages Tabellen laufen > lassen? MERGE fasst mehrere identische MyISAM Tabellen zu einer zusammen -- Sebastian _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From mysql at universalware.de Fri Oct 26 10:45:15 2007 From: mysql at universalware.de (=?iso-8859-1?Q?Andreas_M=FCller?=) Date: Fri, 26 Oct 2007 10:45:15 +0200 Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <47219412.4040008@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de><061101c81724$400155f0$8119fea9@nbandreas> <47219412.4040008@gfz-potsdam.de> Message-ID: <0aec01c817ac$87e143c0$8119fea9@nbandreas> Hallo Tobias, rein aus dem Bauch heraus würde ich hier folgendes vorschlagen: Wie es scheint gibt es einen Input-Bereich und einen Lager-Bereich. Im Input Bereich fallen Daten an nach einem Aufräumen in den Lager-Bereich überführt werden müssen. Also würde ich den Input Bereich so gestalten das er in möglichst für das Aufräume greifbare Blöcke zerlegt wird und die Aufräumarbeiten in dem Input Bereich noch überschaubar bleiben. z.B. - pro Tag eine Tabelle - am Ende es Tages die Tabelle aufräumen und Daten in Lager-Tabelle schreiben - nicht verarbeitete Daten (weil noch nicht aufräumbar) verschiebe ich in die aktuelle Tagestabelle - usw. Damit halte ich den Input Bereich klein, was ich aufräumen kann Räum ich auf, was nicht verarbeitbar ist verschiebe ich auf den nächsten Zyklus. "Tag" kann man nun auch als 2 Tage, Woche, Monat o.ä. auffassen. Das Aufräumen, Übertragen in Lagertabelle und Säubern des Input Bereiches muss dabei aber in einer Transaktion ablaufen - sprich MyISAM als Storage Engine fällt da aus. Daher würde ich hier (vor allem bei den Datenmengen) auf InnoDB setzen. Eine schönen fetten Datenbankserver nehmen (ordentlich CPU, viel RAM und vor allem sehr schnelle Platten) und dem InnoDB ordentlich Platz (auto extend bremst extrem also lieber gleich auf Partition schrieben lassen oder ordentlich große Tablespace Dateien anlegen) und RAM geben. Evtl. reicht es wenn man den Input Bereich auf InnoDB fährt und die Lager-Tabellen auf MyISAM aber das müsste man in der Praxis sehen wie sich auch Abfragen gestalten denn: Fahre ich zwei vollausgebaute Storage-Engines in MySQL brauch ich für bei jeweils viel RAM denn die Buffer, Caches etc. gehören der jeweiligen Storage Engine. Noch kurz zum Aufräumen: Das Aufräumen nach der Methode von Sebastian ist wesentlich schneller als der Subselect - da hat sich zwar in den 5er Versionen viel am optimizer getan aber so richtig herausoptimieren von solchen Abfragen klappt noch nicht ganz. Bei meinem Vorschlag würde das ganze sogar nochmals vereinfach weil man hier direkt auf einen Inner-Join setzen kann: INSERT INTO lager_tabelle(felder....) SELECT felder.... FROM Tabelle1 INNER JOIN Tabelle2 ON Tabelle2.ID=Tabelle1.ID INNER JOIN Tabelle3 ON Tabelle3.ID=Tabelle2.ID Schneller geht das dann nun wirklich nicht :-) Gruß, Andreas _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From ks at codebiz.de Fri Oct 26 11:17:30 2007 From: ks at codebiz.de (Kai Szymanski) Date: Fri, 26 Oct 2007 11:17:30 +0200 Subject: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <4720BFB0.2050901@gfz-potsdam.de> References: <4720B533.9030409@gfz-potsdam.de> <05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <4720BE54.3030202@codebiz.de> <4720BFB0.2050901@gfz-potsdam.de> Message-ID: <4721B0AA.4010902@codebiz.de> Hi! Wir haben hier Datenbanken mit knapp 280 Mio. Datensätzen. Wichtig ist unter anderem die Hardware (was für eine iowait habt Ihr, wenn die Datenbank Deiner Meinung nach langsamer wird?). Du musst vor allem Monitoren um herauszufinden, wo das Bottleneck liegt (Festplattensystem, Speicher, Suboptimale Queries etc.). Wir setzen hier auf Server mit 16 GB Ram und einem DAS (Raid10 / SAS / 15 x 15.000er Festplatten). Ist gut fix ;) CU, Kai. _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de From tobias at gfz-potsdam.de Fri Oct 26 12:27:36 2007 From: tobias at gfz-potsdam.de (Tobias Mueller-Wrana) Date: Fri, 26 Oct 2007 12:27:36 +0200 Subject: LAYOUT Re: Newbie: Replikation etwas anders/komplizierter... In-Reply-To: <47219F54.5030805@sebastianmendel.de> References: <4720B533.9030409@gfz-potsdam.de><05e701c8171f$0cf0c5b0$8119fea9@nbandreas> <4720BD28.2020002@gfz-potsdam.de> <061101c81724$400155f0$8119fea9@nbandreas> <47219412.4040008@gfz-potsdam.de> <47219F54.5030805@sebastianmendel.de> Message-ID: <4721C118.5000401@gfz-potsdam.de> WoW Sebastian, > ich kenn mich nicht 100% aus bei ... NOT IN (SELECT ...) aber ich würde > vermuten das MySQL es hier eher schwer hat den Index vernünftig zu verwenden ... > > vielleicht wäre folgendes etwas schneller: > > SELECT * > FROM Tabelle1 > LEFT JOIN Tabelle2 > USING (id) > LEFT JOIN Tabelle3 > USING (id) > WHERE ISNULL(Tabelle3.id) > > oder > > HAVING ISNULL(Tabelle3.id) > Ich habe Deinen Befehl mal umgesetzt... WoW! Also der Unterschied meine Befehl braucht Stunden *gähn* Deiner < 1min... Yepee Super herzlichen Dank!!!!! -- Tobias ------------------------------ Tobias Mueller-Wrana GFZ Potsdam, Sektion 2.4, E251 Telegrafenberg. D-14773 Potsdam Tel.: +49-(0)331-288-1241 ------------------------------- _______________________________________________ Allgemeine Infos zur Liste: http://www.4t2.com/mysql/ Verwaltung: https://lists.4t2.com/cgi-bin/mailman/listinfo/mysql-de