Un post pour vous démontrer que c’est toujours intéressant de lire les documentations et que parfois, les petites lignes en bas de page peuvent révéler des informations importantes.

J’étais récemment chez un client pour un audit de performance dans un environnement Windev / MySQL.
Je ne suis pas un grand spécialiste de Windev, bien qu’ayant déjà réalisé des audits sur ce type d’environnement, je n’avais jamais eu l’occasion d’aller aussi loin dans la compréhension du code applicatif.

Au hasard de l’analyse des requêtes lentes (via le log des requêtes lentes), je me suis aperçu qu’une requête apparaissait systématiquement deux fois consécutivement dans le log.

Après avoir identifié avec mon client le bout de code exécutant cette requête, nous avons travaillé avec le log général de MySQL afin d’essayer de comprendre pourquoi cette requête était lancée deux fois alors qu’elle n’apparaissait qu’une fois dans le code applicatif.

Le code utilisé est le suivant :

SD est une Source de Données
MaReq est une chaîne

####################################################################################

MaReq = "SELECT nom, prenom FROM client WHERE type =  1"

// Exécution de la requête

HExécuteRequêteSQL(SD,  MaConnexionMySQL,  hRequêteSansCorrection,  MaReq)

// Boucle sur le résultat

HLitPremier(SD)

TANTQUE  PAS HEnDehors(SD)

Trace(SD.Nom)

HLitSuivant(SD)

FIN

####################################################################################

Le verdict du log général est sans appel, la requête est bien exécutée deux fois !

Petite parenthèse, la fonction HExécuteRequêteSQL réalise systématiquement une modification de code SQL (Ajout d’un ORDER BY par exemple). Si vous souhaitez conserver votre code SQL original, n’oubliez pas d’ajouter le paramètre hRequêteSansCorrection comme fait ici.

Mais revenons à nos moutons, la mystérieuse requête en double…
Après plusieurs tests, nous avons réussi à identifier la cause de cette double exécution, il s’agissait de la fonction HLitPremier.

En effet, cette fonction exécute une nouvelle fois la requête, certainement pour intégrer d’éventuelles modifications de données entre le moment où l’on exécute la requête et le moment où l’on entre dans la boucle.
Simplement, si la requête est déjà coûteuse, elle l’est d’autant plus si elle est lancée deux fois et la seconde exécution n’est pas forcement nécessaire.
Cela dépend évidemment du contexte applicatif dans lequel vous vous trouvez. Dans le cas présent, ce n’était pas nécessaire.

Nous voici donc en train d’éplucher la documentation Windev (c’est là que vous comprenez mon introduction) à la recherche d’une information capitale dans notre cas : Comment désactiver cette double exécution ?

Et nous n’avons pas mis longtemps (enfin, un peu quand même…) à repérer de petites lignes en bas de la page de la documentation de l’accès natif MySQL pour Windev :

Optimisations des fonctions HyperFileSQL (Réf :  http://doc.pcsoft.fr/fr-FR/?acces-natif-mysql-pour-windev-webdev)

• Les Tables fichiers basées sur des requêtes sont optimisées : il est possible de trier la table en cliquant sur une de ses colonnes.
• Pour éviter de ré-exécuter plusieurs fois la même requête lors du parcours de son résultat, il est conseillé d’utiliser la constante hSansRafraichir (par exemple si un seul poste modifie les données).

Donc, pour résumer, si vous utilisez la fonction HLitPremier et que vous ne souhaitez pas que celle-ci ré-exécute la requête précédemment exécutée par la fonction HExécuteRequêteSQL, vous devez utiliser la fonction avec le paramètre suivant :

• HLitPremier(SD,  hSansRafraîchir)

Et effectivement, le log général ne mentionnait plus qu’une seule exécution après cette correction de code Windev !

J’espère que cette information vous sera utile pour vos devs Windev existants ou à venir. N’hésitez pas à nous faire un retour si vous aviez déjà rencontré ce problème ou pour tout retour d’expérience Windev / MySQL.

Un grand merci à toute l’équipe qui se reconnaitra et à bientôt sur le blog de capdata.
Cédric

Documentation sur le log des requêtes lentes : http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html
Documentation sur le log général :  http://dev.mysql.com/doc/refman/5.1/en/query-log.html
Documentation Windev : http://doc.pcsoft.fr/fr-FR/Continuez votre lecture sur le blog :

• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]
• Abonnez-vous au blog de la CapData team ! (Cédric PEINTRE) [GénéralMySQLOracleSQL ServerSybase]
• Intérêt de créer des indexes cluster uniques (David BAFFALEUF) [SQL Server]
• Générer le DDL complet d’une base en C# / SMO / multithreading (David BAFFALEUF) [SQL Server]
• Que faire des « [Warning] Aborted connection » avec MySQL ? (Cédric PEINTRE) [MySQL]

Juste un petit post pour vous rappeler les différentes méthodes vous permettant de suivre l’activité débordante du blog de la capdata team :

• Accès standard via la page web : http://blog.capdata.fr
• Vous abonner au flux RSS du blog et être ainsi prévenu de l’arrivée des nouveaux articles : http://feeds.feedburner.com/CapDataTeamBlog
• Nous suivre sur Twitter pour retrouver l’actualité des bases de données : http://twitter.com/capdata_blog

Vous êtes de plus en plus nombreux à nous suivre sur ce blog technique autour des bases de données et nous vous en remercions.

J’en profite pour vous proposer quelques articles qui semblent avoir remportés un vif succès dernièrement :

• http://blog.capdata.fr/index.php/jeux-de-caracteres-unicode-et-base-de-donnees/
• http://blog.capdata.fr/index.php/installation-oracle-11gr2-64-bits-sur-red-hat-5-partie-1/
• http://blog.capdata.fr/index.php/modifier-la-collation-dune-base-sql-2005/
• http://blog.capdata.fr/index.php/mysql-et-les-tables-temporaires-internes/
• http://blog.capdata.fr/index.php/sybase-ase-direct-io-dsync-onoff-raw-device/

Encore une fois, n’hésitez pas à poster vos commentaires sur les articles, l’échange est la richesse du contenu.

A bientôt sur le blog de la capdata team !Continuez votre lecture sur le blog :

• Voucher certification SQL Server 70-432 offert ! (David BAFFALEUF) [SQL Server]
• Scruter les journaux d’évènements Windows avec LogParser (David BAFFALEUF) [SQL Server]
• Intérêt de créer des indexes cluster uniques (David BAFFALEUF) [SQL Server]
• Que faire des « [Warning] Aborted connection » avec MySQL ? (Cédric PEINTRE) [MySQL]
• Planification dans Adaptive Server (David BAFFALEUF) [Sybase]

Le standard ASCII

Afin de répertorier tous les caractères, un standard a été mis en place.

Le premier standard qui voit le jour est l’ASCII.

Pour représenter des caractères dans un fichier texte, on associe un nombre (code) à une lettre, à un chiffre ou à un symbole.

L’encodage le plus connu de l’ASCII est US-ASCII.

A => 65 => 01000001

a => 97 => 01100001

Le codage est réalisé sur 7bits/octet soit 128 symboles possibles. Une trentaine d’entre eux sont des caractères de commande, le reste est constitué de l’alphabet anglais standard, des chiffres et des ponctuations.

L’extension la plus connue est la famille ISO-8859, permettant de représenter les caractères accentués. Le codage est réalisé sur un octet complet, soit 256 caractères possibles. Les codes de 160 à 255 sont affectés au codage des caractères latins accentués.

Standards ISO-8859-1 à 15

ISO-8859-1 puis 15 (euro): Europe de l’Ouest

ISO-8859-2: Europe Centrale ou de l’Est

ISO-8859-5: Cyrillique

ISO-8859-7: Grec

Les principaux problèmes rencontrés avec ce standard sont les suivants :

- On ne peut utiliser plusieurs langues à l’intérieur d’une même instance.

- Deux grands absents de l’ISO-Latin-1 sont la ligature oe « œ », essentielle à la typographie française correcte, et le symbole de l’euro « € ».

- Chaque constructeur d’ordinateur a aussi développé ses propres codes non conformes aux standards internationaux (IBM EBCDIC, Windows-1252,..)

L’unicode

La globalisation consiste à intégrer dans une même table tous les caractères connus du monde.

Le standard Unicode est un mécanisme universel de codage de caractères. Il définit une manière cohérente de coder des textes multilingues et facilite l’échange de données textuelles.

Il est un passage obligatoire pour la plupart des nouveaux protocoles de l’Internet, mis en œuvre dans tous les systèmes d’exploitation et langages informatiques modernes.

Formes de codage

Il existe plusieurs formes de codage de caractères pour l’Universal Character Set:

- UCS-2

- UCS-4

Cependant, les codages UCS-2 et UCS-4 sont difficiles à utiliser dans de nombreuses applications et protocoles qui travaillent avec des caractères codés sur 8 ou même 7 bits. Même certains systèmes plus récents capables de travailler avec des caractères sur 16 bits ne peuvent pas traiter les données codées en UCS-4. Cette situation a conduit au développement de formats de transformation UTF (UCS Transformation Formats). Chacun possédant ses propres caractéristiques.

Encodage UTF 8

UTF-8 a été conçu par Kenneth Thompson en 1992 pour être compatible avec certains logiciels originellement prévus pour traiter des caractères d’un seul octet.

Les caractères de numéro 0 à 127 sont codés sur un octet dont le bit de poids fort est toujours nul.

Les caractères de numéro supérieur à 127 sont codés sur plusieurs octets.

Encodage UTF 16

UTF-16 est une méthode permettant de transformer un sous-ensemble de la table UCS-4 en une paire de valeurs UCS-2 d’une plage réservée.

UTF-16 est décomposé en 2 types.

UTF-16-BE (Big-endian)

UTF-16-LE (Little-endian)

Le codage UTF-16-BE est l’un des codages préconisés par la norme Unicode. Ce codage associe simplement un code de 16 bits (2 octets) à chaque caractère.

Encodage UTF 32

UTF-32 est un protocole pour encoder les caractères sur 32 bits. Du fait que l’UTF-32 utilise 4 bytes par caractère.

Il est aussi  décomposé en 2 types.

UTF-32-BE (Big-endian)

UTF-32-LE (Little-endian)

Il est relativement consommateur d’espace.

Support SGBD

Oracle

Deux paramètres permettent de prendre en charge l’Unicode.

• Database Character Set
• National Character Set

Ces paramètres sont définis lors de la création de la base.

L’instruction CREATE DATABASE dispose de la clause character set et de la clause national character set qui permettent de déclarer le jeu de caractères qui servira de jeu de caractères de la base et de jeu de caractères nationaux.

Sans spécification de la clause national character set, le jeu AL16UTF16 sera utilisé par défaut.

Le paramètre Database Character Set ne peut pas être configuré en UTF-16.

Oracle gère l’unicode au niveau des colonnes grâce National Character Set et au types de données suivantes :

• Nchar
• Nvarchar2
• nclob

Sybase

Au moment de l’installation, vous devez définir le paramètre default character set. Par défaut il est déterminé par celui utilisé sur votre server (Win = 1252, solaris =ISO 8859-1). Sybase recommande de définir UTF 8 pour ce paramètre si vous utiliser de l’unicode.

Sybase supporte la gestion de l’unicode au niveau du type de colonne à l’aide des 3 types suivants :

- Unichar

- Univarchar

- Unitext

Ces 3 types de données sont encodés en UTF 16.

Sql server

Nous  allons introduire la notion de collation.

Une collation est une table de correspondance spécifique à un jeu de caractères.

Un jeu de caractères peut avoir plusieurs collations, en général une par langue (par exemple, latin1 français, latin1 suédois).

Ce paramètre se définit à l’installation, sa valeur par défaut est en fonction de la langue de l’OS sur lequel se fait l’installation (pour les collations de type windows) :

Système en français : French_CI_AS

Système en anglais : Latin1_General_CI_AS

Il sert à déterminer la page de code utilisée dans les champs non unicode (varchar par exemple), l’ordre de tri des chaînes de caractère et aussi la sensibilité aux accents, aux majuscules, etc.

La collation paramétrée s’applique aux bases de données systèmes (master, msdb, tempdb et model) et par défaut aux nouvelles bases de données créées. Elle peut cependant être modifiée lors de la création d’une nouvelle base de données ou lors de l’ajout d’un champ texte grâce au mot clef COLLATE.

Sql server supporte la gestion de l’unicode à travers le type de colonne :

- Nchar

- Nvarchar

- Ntext

My sql

MySQL détermine le jeu de caractères et la collation en fonction de l’option de configuration active quand le serveur démarre ou en fonction des valeurs de configuration à l’exécution.

Vous pouvez utiliser –default-character-set=character_set_name comme jeu de caractères et vous pouvez en même temps ajouter –default-collation=collation_name pour la collation. Par défaut mysql utilise les options suivante –default-charset=latin1 –collation=latin1_swedish_ci car latin1_swedish_ci est la collation par défaut de latin1.

La collation peut aussi être définie au niveau de la base ou de la colonne à l’aide de la clause collate.

En MySQL version 4.x et plus ancien, NCHAR et CHAR étaient synonymes.

MySQL utilise UTF8 comme jeu de caractère prédéfini pour les champs de types Nchar et Nvarchar .Continuez votre lecture sur le blog :

• Consistence des écritures avec SATA (David BAFFALEUF) [Operating SystemSQL Server]
• I/O asynchrones (épisode 1) (David BAFFALEUF) [Operating SystemSQL Server]
• Modes de récupération et journal de transactions, épisode 2 (David BAFFALEUF) [SQL Server]
• Modes de récupération et journal de transactions, épisode 1 (David BAFFALEUF) [SQL Server]
• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]

C’est d’ailleurs une question que l’on s’est posée, autour de la machine café, et qui du coup a fait l’objet d’un petit exercice avec Oracle, SQL Server, MySQL et Sybase… Bon, je vous rassure, nous ne faisons pas que parler bases de données pendant les pauses café mais ça arrive, parfois.

Place aux tests : Un trigger fait-il parti d’une transaction ?

Test Oracle :

SQL > create table t2 ( cnt int );
 SQL > insert into t2 values ( 0 );
 SQL > commit;
 SQL > create table t ( x int check ( x>0 ) );

SQL > create trigger t_trigger
 before insert or delete on t for each row
 begin
 if ( inserting ) then
 update t2 set cnt = cnt +1;
 else
 update t2 set cnt = cnt -1;
 end if;
 dbms_output.put_line( 'I fired and updated ' ||sql%rowcount || ' rows'  );
 end;
 /

Résultat : OUI

SQL > set serveroutput on
 SQL > insert into t values (1);
 I fired and updated 1 rows
 1 row created.
 SQL > insert into t values(-1);
 I fired and updated 1 rows
 insert into t values(-1)
 *
 ERROR at line 1:
 ORA-02290: check constraint (SYS_C009597) violated
 SQL > select * from t2;
 CNT
 ----------
 1

Test MS SQL Server :

use tempdb
 go

create table t2 ( cnt int )
 insert into  t2 values ( 0 )
 select * from t2

create table t ( x int check  ( x>0 ) )

drop trigger t_trigger
 create trigger t_trigger  on t for insert
 as
 begin
 update t2 set cnt = cnt +1
 print( 'I fired and updated ' + CAST(@@ROWCOUNT AS NVARCHAR(8))  + '  rows' )
 end

Résultat : OUI

begin tran
 insert into t values(2);
 insert into t values(-1);

(1 row(s) affected)
 I fired and updated  1 rows

(1 row(s) affected)
 Msg 547, Level 16, State  0, Line 4
 The INSERT statement conflicted with the CHECK constraint  "CK__t__x__7A5DD7C8". The conflict occurred in database "tempdb", table  "dbo.t", column 'x'.
 The statement has been terminated.

Test MySQL (InnoDB) :

Au passage, cela m’a permis de découvrir que les contraintes CHECK n’étaient pas prises en charge par MySQL : The CHECK clause is parsed but ignored by all storage engines

mysql> set autocommit=off;
 Query OK, 0 rows affected (0.02  sec)

mysql> use test
 Database changed
 mysql> create  table t2 ( cnt int ) engine=innodb;
 Query OK, 0 rows affected (0.11  sec)

mysql> insert into t2 values ( 0 );
 Query OK, 1 row  affected (0.02 sec)

mysql> commit;
 Query OK, 0 rows  affected (0.11 sec)

mysql> create table t ( x int primary key)  engine=innodb;
 Query OK, 0 rows affected (0.09 sec)

mysql>  delimiter //

mysql> create trigger t_trigger
 ->             before insert on t for each row
 ->              begin
 ->             update t2 set cnt = cnt +1;
 ->             end;
 -> //
 Query OK, 0 rows affected (0.11  sec)

mysql> delimiter ;

Résultat : OUI

mysql> insert into t values (1);
 Query OK, 1 row affected  (0.02 sec)

mysql> insert into t values (1);
 ERROR 1062  (23000): Duplicate entry '1' for key 'PRIMARY'

mysql> select *  from t2;
 +------+
 | cnt  |
 +------+
 |    1 |
 +------+
 1 row in set (0.00 sec)

Test Sybase :

1> create trigger T1_ins_tr on T1 for insert

2> as

 3> begin

 4> select 1/0

 5> end

 6> go

Résultat : OUI

5> begin tran
 6> go
 1> insert into T1 values ('kjhkjhkjh')
 2> go
 Msg 3607, Level 16, State 0:
 Server 'ASE1502', Procedure 'T1_ins_tr', Line 4:
 Divide by zero occurred.

-----------
 1> select @@trancount
 2> go

-----------
 0

(1 row affected)

Résultat des tests : LE VERDICT !

Oui, un trigger fait bien parti d’une transaction, quel que soit le SGBD, enfin, au moins sur Oracle, SQL Serveur, MySQL et Sybase.

Je vous laisse faire vos tests sur DB2, Postgre et consorts… N’hésitez pas à nous faire un retour dans les commentaires.

A+
CédricContinuez votre lecture sur le blog :

• Mythe: SQL Server associe un thread à chaque connexion (David BAFFALEUF) [SQL Server]
• Fragmentation sur des tables stockées en S-GAM (David BAFFALEUF) [SQL Server]
• Saines lectures (David BAFFALEUF) [SQL Server]
• Scripting et SMO (suite): scripter les objets directement en T-SQL (David BAFFALEUF) [SQL Server]
• Règles d’installation de base (épisode 1) (David BAFFALEUF) [SQL Server]

Je veux parler ici d’erreurs récurrentes, qui se produisent de façon aléatoire plusieurs fois par jour, pas d’une erreur liée à un mauvais mot de passe ou à des privilèges insuffisants qui peuvent également générer ce type d’erreur.

Ce qu’en dit MySQL :

La page de documentation concernant ce problème est la suivante :

• http://dev.mysql.com/doc/refman/5.1/en/communication-errors.html

En fait, il y a deux raisons essentielles pour lesquelles MySQL est susceptible de renvoyer cette erreur : Des problèmes liés au réseau ou des problèmes liés au mode de sortie de session dans le code applicatif.
Pour ce dernier cas, attention à bien utiliser la fonction mysql_close() dans votre code applicatif.

Dans la pratique, que faire de cet avertissement ?

La première question à se poser est de savoir si ce problème affecte, d’une façon ou d’une autre, votre production.
Pour le savoir, plusieurs sources sont à votre disposition : Les utilisateurs qui peuvent vous remonter des erreurs, les logs applicatifs ou vos outils de monitoring qui clignotent trop régulièrement…

Si l’impact de cette erreur sur votre production est nulle, je vous recommande simplement de désactiver la remontée d’info la concernant via le paramètre log-warnings :

• set global log_warnings = 1;

Attention toutefois, la manipulation de ce paramètre peut entraîner la désactivation complète de tous les warnings. Rapprochez vous de la documentation de ce paramètre pour plus d’infos :

• http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_log-warnings

Sinon, je vous invite à suivre le mode opératoire suivant :

• Demander aux admins réseau de vérifier les différents composants réseau de votre architecture afin d’identifier d’éventuels problèmes
• Vérifier votre code applicatif et la bonne utilisation de la fonction mysql_close()
• Vérifier que vos clients MySQL ne dépassent pas le timeout de connexion défini par la variable connect_timeout
• Augmenter la valeur du paramètre max_allowed_packet (cette dernière méthode semble d’ailleurs porter ses fruits chez un grand nombre d’utilisateurs)

Si ces différentes opérations ne permettent pas d’identifier ou de régler votre problème, essayez d’appliquer chaque point préconisé dans la documentation mentionnée en début d’article et croisez les doigts !

N’hésitez pas à me faire un retour d’expérience sur ce point à travers les commentaires. Merci.

Bonne fin de semaine
Cédric.Continuez votre lecture sur le blog :

• Scruter les journaux d’évènements Windows avec LogParser (David BAFFALEUF) [SQL Server]
• MySQL et les tables temporaires internes (Cédric PEINTRE) [MySQL]
• Insert et Update en une seule fois avec MERGE (Guillaume DEFENDINI) [SQL Server]
• Abonnez-vous au blog de la CapData team ! (Cédric PEINTRE) [GénéralMySQLOracleSQL ServerSybase]
• Intérêt de créer des indexes cluster uniques (David BAFFALEUF) [SQL Server]

Sauvegarder le cache, oui, mais pour quoi faire ?

Vous devez effectivement comprendre l’intérêt de la chose si vous vous êtes déjà frotté à l’administration d’un MySQL mais je dois vous avouer qu’en abordant le sujet pendant la pose café, tout le monde n’était pas forcement convaincu.

En effet, la mise en œuvre d’une telle fonctionnalité soulève une autre question : Pourquoi redémarrer MySQL ?

Effectivement, le véritable intérêt de cette sauvegarde est de pouvoir couper son MySQL sans perdre les informations stockées dans le cache. Intérêt évidemment compris de tous dans le cas d’un crash du serveur MySQL.

Dans les faits, XtraDB permet de sauvegarder et restaurer le cache même si il n’y a pas eu d’arrêt de l’instance. Ce qui peut d’ailleurs s’avérer utile dans certaines conditions, après le passage d’un gros batch par exemple, afin de retrouver un cache d’activité transactionnelle standard.

Pour en revenir à la question posée par mon collègue, en dehors du contexte de crash, pourquoi redémarrer MySQL ?
Alors que d’autres éditeurs de bases de données concentrent leurs efforts pour justement limiter au maximum le redémarrage des instances, il semble que MySQL soit plus exposé que les autres à ce type de problématique.
Et effectivement, même si la modification dynamique de paramètres gagne du terrain avec les nouvelles versions, la gestion des fichiers physiques reste problématique dans un environnement de production critique.

Il s’agit donc ici de se poser la question à l’envers et c’est donc pour ces différentes raisons que la sauvegarde du cache de données est pertinente avec MySQL !

Comment ça marche ?

Le pré-requis est évidemment d’installer et d’utiliser le moteur de stockage XtraDB fourni par Percona (lien en fin d’article).

Pour comprendre le fonctionnement de cette sauvegarde, j’ai réalisé un petit test en utilisant le compteur Innodb_buffer_pool_pages_data qui indique combien de pages du cache sont utilisées :

1 – Arrêt et relance de l’instance MySQL (Tous les caches sont vidés)

2 – Je contrôle l’état de mon cache :

• mysql> show global status like ‘Innodb_buffer_pool_pages_data’;

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_buffer_pool_pages_data | 14    |
+-------------------------------+-------+

3 – Je fais une requête simple sur ma table ETAT :

• mysql> select * from capdata_innodb.ETAT;

4 -Nouvelle vérification du cache, à ce stade, la table ETAT a bien été montée dans le cache (au moins une partie de ses données) :

• mysql> show global status like ‘Innodb_buffer_pool_pages_data’;

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_buffer_pool_pages_data | 17    |
+-------------------------------+-------+

5 – Je lance une sauvegarde du cache :

• mysql> select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_DUMP*/;

+------------------------------+
| result_message               |
+------------------------------+
| XTRA_LRU_DUMP was succeeded. |
+------------------------------+

6 – Arrêt et relance de l’instance MySQL (Tous les caches sont vidés)

7 – Vérification du cache :

• mysql> show global status like ‘Innodb_buffer_pool_pages_data’;

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_buffer_pool_pages_data | 14    |
+-------------------------------+-------+

8 -Restauration du cache :

• mysql> select * from information_schema.XTRADB_ADMIN_COMMAND /*!XTRA_LRU_RESTORE*/;

+---------------------------------+
| result_message                  |
+---------------------------------+
| XTRA_LRU_RESTORE was succeeded. |
+---------------------------------+

9 – Dernière vérification du cache :

• mysql> show global status like ‘Innodb_buffer_pool_pages_data’;

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Innodb_buffer_pool_pages_data | 17    |
+-------------------------------+-------+

Le cache a bien été restauré, à vous le warm restart facile !

Percona a réalisé un petit benchmark comparatif dont voici le résultat :

Retrouvez toutes les informations sur le moteur XtraDB ici : http://www.percona.com/docs/wiki/percona-xtradb:startContinuez votre lecture sur le blog :

• Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Bench avec NetApp / Datacore / ESX (David BAFFALEUF) [SQL Server]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• Principes d’une sauvegarde à chaud (David BAFFALEUF) [SQL Server]

Le détail des cas de création de tables temporaires est disponible dans la documentation MySQL :

• http://dev.mysql.com/doc/refman/5.1/en/internal-temporary-tables.html

Ces tables temporaires sont créées en mémoire par défaut, dans la limite de la taille définie par le paramètre tmp_table_size [taille par défaut dépendante de l'OS]. Au delà de cette limite, la table temporaire est créée sur disque. Attention toutefois, si la valeur du paramètre max_heap_table_size [16M par défaut] est inférieure à celle de tmp_table_size, alors les tables temporaires en mémoire seront limitées à max_heap_table_size. Pour simplifier les choses, positionnez les deux paramètres à la même valeur.

Il est évidemment plus performant de provoquer le maximum de création en mémoire en positionnant la valeur du paramètre tmp_table_size à une taille relativement importante (16M à 32M).
Attention toutefois au débordement mémoire, en effet, cette taille peut potentiellement être consommée par chaque thread connecté !

La colonne Extra de la commande EXPLAIN pour une requête de type SELECT permet d’obtenir une information sur la création d’une éventuelle table temporaire.
Dans ce cas (utilisation d’un GROUP BY), une table temporaire sera créée :

*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t_evenement
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 14988
Extra: Using temporary; Using filesort

En revanche, cette commande ne permet pas de savoir si la table temporaire est créée sur disque ou en mémoire, pour cela, il faudra s’appuyer sur les compteurs MySQL évoqués dans la suite de l’article.

Le graphe suivant présente un état des tables temporaires créées en mémoire et sur disque pour notre instance de production  :

Tables temporaires MySQL

Les compteurs MySQL utilisés pour relever ces valeurs sont Created_tmp_table et Created_tmp_disk_tables. Il n’est malheureusement pas possible de connaitre la taille consommée en mémoire ou sur disque par ces tables temporaires.

Ici, la quasi totalité des tables temporaires est créée sur disque. La taille maximum d’une table temporaire en mémoire est pourtant positionnée à une valeur relativement importante (48M).

Le fait d’augmenter la valeur du tmp_table_size ne changera rien dans ce cas ! Explications :

MySQL utilise le moteur de stockage MEMORY pour la création des tables temporaires internes. Ce moteur se comporte quasiment comme MyISAM, cependant, une  contrainte  de ce moteur vient perturber le fonctionnement des tables temporaires internes : Il n’est pas possible d’utiliser des colonnes de type BLOB ou TEXT pour les tables MEMORY.

De ce fait, si MySQL doit créer une table temporaire pour un ordre SELECT contenant ces types de colonne, elle sera automatiquement créée sur disque.

Deux possibilités s’offrent à vous dans ce cas :

• Limiter l’utilisation des colonnes de type BLOB ou TEXT
• Monter un système de fichier mémoire pour le stockage des tables temporaires interne MySQL

[ Cédric P ]Continuez votre lecture sur le blog :

• Que faire des « [Warning] Aborted connection » avec MySQL ? (Cédric PEINTRE) [MySQL]
• How-To: réduire la taille du journal de transactions sur disque (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]
• Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David BAFFALEUF) [SQL Server]
• How-To : réduire l’enveloppe de tempdb (David BAFFALEUF) [SQL Server]