Die DOAG 2013 Konferenz + Ausstellung findet von Dienstag, den 19. November 2013 bis Donnerstag, 21. November 2013 in Nürnberg statt.

Der erste Termin der DOAG SIG - MySQL 2013 steht nun fest. Er findet am Mittwoch, den 27. Februar 2013 in München statt.

Mehr:
http://www.doag.org/de/events/sigs/sig-mysql.html

Wenn Sie in Ihrem OXID eShop Ihr Administrator-Passwort vergessen haben, können Sie dieses auch über einen SQL Befehl neu setzen (z.Bsp. über phpMySqlAdmin):

update oxuser set oxpassword = md5(concat('12345',unhex(oxpasssalt))) where oxid = 'oxdefaultadmin'

Ersetzen Sie “12345″ bitte durch Ihr neues Passwort.

Alternative über den eShop

Sie können Ihr Administratorpasswort auch online neu setzen lassen:

1. Klicken Sie im OXID Shop auf “Konto” und wählen Sie dann “Mein Konto”
2. Dort klicken Sie auf den Link “Passwort vergessen ?”
3. Geben Sie Ihre hinterlegte E-Mailadresse ein
4. Folgen Sie den Anweisungen in der Ihnen zugeschickten E-Mail

Kommende Woche beginnt in Birmingham die ORACLE Anwendergruppe der UKOUG. Es gibt viele interessante Vorträge, auch von ORACLE ACEs und ORACLE ACE Direktoren. Die DOAG wird auch vertreten sein.Auch trifft sich das OAK Table Network und es wird einen RAC Attack Workshop geben. Die ORACLE Datenbank und die MySQL Datenbank werden im Mittelpunkt der Konferenz stehen.

More:
http://2012.ukoug.org/

Die DOAG 2013 Konferenz + Ausstellung findet von Dienstag, den 19. November 2013 bis Donnerstag, den 21. November 2013 mit dem DOAG Schulungstag am Freitag, den 22. November 2013 im Congreß Center Nürnberg statt. Es wird wieder zahlreiche Präsentationen von nahmhaften Referenten, Endanwendern, ORACLE ACEs, ORACLE ACE Direktoren, ORACLE Partnern, ORACLE Mitarbeitern und Ausstellern geben.

Mehr:
http://www.doag.org/termine/termine.php?tid=441438

Der ORACLE Information InDepth MySQL EDITION Newsletter Ausgabe November 2012 ist erschienen.

More:
http://www.oracle.com/us/dm/h2fy11/nsl100122318-index-1872673.html?msgid=3-7430641624

Hintergrund dieses damaligen Benchmarks war der Fakt, dass zwei neue eigentlich identisch ausgelegte Server deutlich unterschiedliche Ergebnisse beim gleichen MySQL Benchmark Test lieferten.
Nach kurzem Suchen, fiel uns doch ein Unterschied auf: Auf einem Server war Intel Hyper Threading aktiviert, auf dem anderen nicht.
Normalerweise war auf all unseren Datenbankservern Hyper Threading deaktiviert. Nach kurzem Suchen im Netz fand ich folgenden Blog-Eintrag, in dem ein Benchmark-Ergebnis beschrieben wurde, bei die MySQL-Instanz mit aktiviertem Intel Hyper Threading bessere Ergebnisse lieferte als mit deaktiviertem Hyper Threading. Aus diesem Grund starteten wir zwei Benchmark-Test-Läufe um ein eigenes Bild zu machen.

Die Ausgangssituation:
Hardware:

Server: HP DL380 G7
2 x …

"Kris, bitte schau Dir mal unsere Datenbank an. Wir haben hier einen Generator für unsere Materialized Views, und auf einer Datenbank von 6 GB Größe werden 40 GB Speicher gefüllt und wir kommen sogar ins Swappen."

Na, das ist mal interessant. The fragliche Kiste hat 48 GB RAM, und in der Tat kaum 6 GB Daten.

CODE:mysql> select 

 -> sum(data_length+index_length)/1024/1024/1024 as gb 

 -> from tables 

 -> where table_schema not in ('information_schema', 'performance_schema', 'mysql');

+----------------+

| gb             |

+----------------+

| 5.832778930664 |

+----------------+

1 row in set (0.00 sec)

Aber in "top" sieht das so aus, …

"Kris, guck mal, connection surge auf $WICHTIGER_MASTER, davor kurzer Activity drop. Alle anderen Graphen sehen normal aus."

und

Ich gucke. Alle anderen Graphen sehen in der Tat normal aus. Aber um 13:20 kommt für kurze Zeit alles Processing zum Stillstand.

Wir haben ja log_processlist.pl. Falls es sich also um irgendein wildgewordenes Lock handeln sollte, würde ich das also in den 13_20 und 13_21 Dateien sehen. Beide sind in der Tat größer: Statt 250 Connections zeichnen wir deutlich über 400 Connections in diesen beiden Minuten auf.

Aber: In der Processlist sind keine Irregularitäten zu sehen. Es handelt sich, wenn unser Monitoring keine Löcher hat, nicht um einen Stall und Pileup im Datenbankserver, sondern eine externe Ursache.

Dies ist ein Master. Der hat sein Datadir auf einer …

Wenn der MySQL Slave nach START SLAVE mit dem Fehler 1236 "log event entry exceeded max_allowed_packet" stoppt dann kann das Problem tatsächlich ein zu großes Paket im Master-Binlog sein. Viel wahrscheinlicher ist es jedoch, daß der Slave versucht, ein Binlog-Event von einer falschen Position zu lesen.

"MySQL Replikation: Fehler 1236" vollständig lesen