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]

Globalement, ASE utilise des threads pour supporter toutes les tâches qu’il exécute: requêtes, IO réseau ou disque, connexions utilisateur, tâches internes… en conjonction avec son propre planificateur de tâche.

Le rôle du planificateur de tâche sur tout système est de partager le temps d’un CPU entre plusieurs unités d’exécution (tâches). Il existe deux grandes familles de planificateurs, les préemptifs, et les coopératifs.

Le planificateur préemptif a le pouvoir de planifier et d’interrompre les tâches selon des règles qui lui sont propres et sans tenir compte du type de tâche en cours d’exécution. One size fits all, comme on dit. Ce mécanisme, qui garantit qu’aucune tâche ne va monopoliser les ressources CPU, permet à chaque programme de pouvoir avoir la main sur la CPU à un moment où un autre. Sur la plupart des OS (linux, UNIX System V et Windows NT à partir de la 4.0), le planificateur alloue au thread un bail d’exécution ou un quantième. Si la tâche n’a pas terminé son travail dans le temps imparti, elle est interrompue. Lorsqu’il interrompt la tâche en cours, le planificateur sauvegarde son contexte dans un coin (c’est à dire les structures process + thread qui la représentent en mémoire), et planifie une nouvelle tâche sur la CPU. Ce qu’on appelle un changement de contexte.

Le planificateur coopératif, lui, va au contraire laisser à la tâche le soin de se terminer toute seule. C’est là la plus grosse différence, il n’interrompt pas une tâche qui n’a pas terminé son travail. C’est à la charge de la tâche de rendre la main pour laisser de la place aux autres, c’est donc à elle de prévoir un mécanisme de relâche (to yield = « céder »). Windows 3.1 employait un scheduler coopératif, les Windows 98 et 95 aussi pour assurer la compatibilité avec les programmes 16 bits.

Maintenant, on imagine facilement le risque d’employer un tel système de planification: une tâche qui part en vrille ne libèrera jamais la CPU, ça n’a donc plus été employé pour faire des operating systems.

Micheal Stonebraker avait publié un article de quelques pages au début des années 80* expliquant en gros que les ’services’ apportés par UNIX system V n’étaient pas adaptés au monde de la base de données, et notamment en matière de planification. Les tâches typiques issues des SGBD prennent plus de temps à s’effectuer car il ne s’agit pas de calcul mais d’IOs, et le mode préemptif n’est pas adapté car il ‘coupe’ la dynamique et l’efficacité du SGBD en produisant de nombreux changements de contexte.

Donc les développeurs chez Sybase ont répondu en créant un scheduler coopératif ‘on top‘ **, propre à Adaptive Server et par dessus le planificateur de l’OS, de telle manière à ce qu’il masque les choses vis à vis de celui-ci et limite au maximum les changements de contexte.

- Les tranches de temps:
ASE va donc fonctionner comme un OS, mais avec ses règles à lui: il gère sa propre planification, son propre partage du temps CPU, ses propres valeurs de quantième. Car bien que coopératif, il doit pouvoir stopper une tâche qui ne répond plus et éviter la saturation d’un engine. Lorsqu’il planifie une tâche, il va lui allouer un bail. Ce bail n’est pas une valeur temporelle, c’est un nombre de ticks d’horloge qui est décrémenté. Il est calculé en divisant le paramètre ‘timeslice’ par ’sql server clock tick length’. Comme les deux valeurs sont à 100 ms par défaut, le nombre de ticks d’horloge autorisé est de 1. Dans le déroulement de son exécution, une tâche va passer par des parties de code qu’on appelle des yield points, au cours desquels elle va prendre une seconde pour vérifier qu’elle n’a pas dépassé son bail. Si elle découvre que le bail est excédé (bail < 0), elle va demander à ASE de lui accorder une grace supplémentaire (cpu grace time), qui peut aller jusqu’à 500 ticks (soit 50 secondes). Si elle n’a pas terminé au delà de cette valeur, alors ASE sort les gros moyens, termine la tâche, annule ses transactions et affiche une stacktrace dans l’errorlog:

00:00000:00005:2007/04/02 22:09:24.07 kernel  timeslice -501, current process infected
00:00000:00005:2007/04/02 22:09:24.75 kernel  ************************************
00:00000:00005:2007/04/02 22:09:24.77 kernel  curdb = 1 tempdb = 2 pstat = 0x200
00:00000:00005:2007/04/02 22:09:24.77 kernel  lasterror = 0 preverror = 0 transtate = 1
00:00000:00005:2007/04/02 22:09:24.77 kernel  curcmd = 0 program =
...

Tout ceci se passe toujours sans que l’OS ne sache rien, car de son côté, le processus dataserver est toujours en exécution. C’est le but: l’OS ne doit pas interrompre le processus dataserver puisque celui-ci semble toujours travailler.

- Runnable Process search count:
Toujours dans le souci de préserver son exécution vis à vis de l’OS, lorsqu’il a terminé d’exécuter des tâches, et plutôt que de rendre la main tout de suite, Adaptive Server va entrer dans une boucle de vérification des IOs en attente côté réseau puis côté disque. S’il ne trouve rien, il va tourner (spinning) pour rechercher de nouvelles tâches en attente d’exécution, puis de nouvelles IOs réseau, puis de nouvelles IOs disques, etc… tout ça 2000 fois par défaut (runnable process search count), même s’il n’y a rien à traiter dans aucune file d’attente. Ce qui donne une apparente sensation d’hyperactivité côté OS, alors que côté Adaptive Sever, l’électro-encéphalo est plutôt plat.

Pour illustrer tout ça, une petite explication de la section ‘kernel’ de sp_sysmon:

Kernel Utilization
------------------

Your Runnable Process Search Count is set to 5000
and I/O Polling Process Count is set to 10

Engine Busy Utilization        CPU Busy   I/O Busy       Idle
------------------------       --------   --------   --------
Engine 0                       80.0 %      7.5 %     12.5 %
Engine 1                       80.8 %      6.0 %     13.2 %
Engine 2                       82.5 %      5.7 %     11.9 %
Engine 3                       84.0 %      6.7 %      9.3 %
Engine 4                       79.0 %      6.8 %     14.2 %
Engine 5                       80.0 %      7.3 %     12.7 %
Engine 6                       79.6 %      8.3 %     12.0 %
------------------------       --------   --------   --------
Summary           Total         565.9 %     48.4 %     85.7 %
Average                         80.8 %      6.9 %     12.2 %

Avant de commencer, il faut bien rappeler le cheminement de la boucle:

Chaque engine tient le compte de ticks reçus de l’OS (par le biais de signaux SIGALRM) tous les 100ms, et les répertorie selon trois catégories:

CPU Busy: représente le temps (en fait le nombre de ticks ramené en pourcentage) passé par l’engine à exécuter une tâche sur l’intervalle.
Idle: représente le temps passé par l’engine à n’exécuter aucune tâche sur l’intervalle.
I/O Busy: est une soustraction de Idle. Il s’agit du temps passé par l’engine à n’exécuter aucune tâche (donc Idle) mais où il y avait au moins une IO disque en attente dans la file. Elle représente donc la quantité de temps où l’engine n’a pas pu exécuter une tâche parce qu’il y avait au moins une IO disque en attente.

On peut retrouver ces valeurs brutes en interrogeant les variables globales @@cpu_busy, @@idle, et @@io_busy. La durée d’un tick peut être retrouvée avec @@timeticks.

A+. [ David B. ]

*: Michael Stonebraker, Operating System Support for Database Management, CACM 24(7), p412-418 (1981).
**: et Microsoft fit de même en dotant SQL Server 7.0 de son propre scheduler coopératif (UMS), toujours bien présent en version 2008 sous une autre dénomination (SQLOS).

Continuez votre lecture sur le blog :

• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]
• Voucher certification SQL Server 70-432 offert ! (David BAFFALEUF) [SQL Server]
• Scruter les journaux d’évènements Windows avec LogParser (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]

WARNING
Although Linux includes support for rawio, it is now a deprecated interface. If your application performs device access using this interface, Red Hat encourages you to modify your application to open the block device with the O_DIRECT flag. The rawio interface will exist for the life of Red Hat Enterprise Linux 5, but is a candi-
date for removal from future releases.

Le bénéfice du raw device n’est pas nouveau, que ce soit pour Adaptive Server ou Oracle, le fait d’écrire directement sur la partition brute a deux avantages majeurs pour les SGBD:
1 – Ca va plus vite.
2 – Ca garantit que ce que l’on écrit va bien sur le disque et non dans un buffer en mémoire. En effet, le système de base de données gère lui-même la bufferisation de ses pages de données et d’indexes, et ne doit pas se reposer sur le système pour ça.

A partir du moment où le raw device cesse d’être supporté, on va devoir écrire dans un fichier, et qui dit écriture dans un fichier sous UNIX/Linux dit écriture bufferisée. C’est là où le critère 2 n’est plus garanti.

Il reste alors deux solutions qui vont nous permettre de garantir celà: DIRECTIO ou DSYNC. Ce sont en fait des arguments qui vont être passés à la primitive d’ouverture du fichier, le plus souvent open(), sous la forme de flags: O_DIRECT, O_DSYNC ou O_ASYNC.

A travers Adaptive Server, ces arguments seront manipulés lors de la création de devices avec la commande disk init:

disk init name='PERFSTATS_data01', physname='/sybase_data/ASE1502/userdb/PERFSTATS_data01.dat',
size=512000,
directio=true

ou

disk init name='PERFSTATS_data01', physname='/sybase_data/ASE1502/userdb/PERFSTATS_data01.dat',
size=512000,
dsync=true

On ne peut pas utiliser à la fois directio=true et dsync=true pour le même device, les options sont mutuellement exclusives.

DIRECTIO:
Lorsque directio est à true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DIRECT:

open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_SYNC|O_DIRECT|O_LARGEFILE) = 17

Lorsque la primitive d’écriture est invoquée (write(), aiowrite()), l’écriture va directement sur le disque. Donc sémantiquement équivalent à ce que donne une écriture sur un raw device, à la fois en termes de performances et de garantie.

DSYNC:
Lorsque dsync est à true, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_DSYNC:

open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_DSYNC|O_LARGEFILE) = 17

Lorsque dsync est à false, le fichier PERFSTATS_data01.dat sera ouvert avec le flag O_ASYNC:

open("/sybase_log/ASE1502/userdb/PERFSTATS_data01.dat", O_RDWR|O_ASYNC|O_LARGEFILE) = 17

Lorsque la primitive d’écriture est invoquée, l’écriture sera bufferisée mais en fonction de la valeur passée à disk init (true ou false), certains éléments vont être synchronisés sur disque avant que aiowrite() ne revienne au programme appelant.
- dsync=true: alors le flag O_DSYNC est passé à open(). Ce flag garantit que write() reste en attente tant que les données n’ont pas été synchronisées sur disque.
- dsync=false: alors le flag O_ASYNC est passé à open(). Ce flag indique que write() rend la main une fois l’écriture bufferisée mais AVANT la synchronisation sur disque, ce qui ne garantit pas notre critère 2.

On recommandera toujours de mettre dsync=true pour les devices de données et de journaux pour avoir la garantie d’écriture stabilisée, et dsync=false pour les devices tempdb pour favoriser la perf.

- Avantages / Inconvénients pour le DSYNC:
Avantages: c’est complètement supporté par les file system.
Inconvénients: C’est moins performant en écriture.

- Avantages / Inconvénients pour le DIRECTIO:
Avantages: c’est comme du raw device, sauf que c’est dans un fichier. C’est même plus efficace en lecture.
Inconvénients: il faut que le filesystem le supporte (c’est le cas pour ext3), et d’après Linus l’implémentation de directio au niveau du kernel est épouvantable. Le problème c’est que ce qu’il indique comme contournement à destination des développeurs ASE (Wim Ten Have et Dave Wein en tête) n’est pas vraiment applicable.

Pas de doute, le DIRECTIO reste la meilleure option. Ce sera sûrement réécrit un jour, mais pour l’instant on n’a pas trouvé mieux.

Un dernier mot sur le dsync=true sur les noyaux 2.6+, l’écriture asynchrone se transforme en écriture synchrone et les perfs chutent (( . Il faut vraiment utiliser directio sur les noyaux récents. Ce sera peut être le sujet d’un prochain post sur ASE.

A+ [ David B. ]

Continuez votre lecture sur le blog :

• Journées SQL Server 12/13 décembre (suite) (David BAFFALEUF) [SQL Server]
• Oracle, les Rpms plus de souci avec YUM (Thierry GASCARD) [Oracle]
• Création d’un Dataguard physique (Guillaume DEFENDINI) [Oracle]
• Bench avec NetApp / Datacore / ESX (David BAFFALEUF) [SQL Server]
• Consistence des écritures avec SATA (David BAFFALEUF) [Operating SystemSQL Server]