Discussion :

[mikedavem]

As-tu un lien vers un document qui expliquerait cela éventuellement ?

++

[SQLpro]

En postant j'en ais cherché, mais je n'ai pas retrouvé les papiers originaux.... Pour info ces techniques datent de l'origine de SQL Server (Sybase). Et j'ai pas le temps. je suis en train d'éditer tous les scripts SQL du bouquin et j'en suis qu'au chapuitre 10 !!!

Regarde http://sqlserverio.com
http://www.informit.com/articles/art...46159&seqNum=8
http://www.brentozar.com/sql/sql-ser...est-practices/


A +

[mikedavem]

Qu'on soit bien d'accord je ne dis pas que SQL Server ne puisse pas faire cela et je n'en doutait d'ailleurs pas .. je dis simplement qu'avec l'apparition de stockage modernes SQL Server n'arrive même plus jusqu'au disques physiques. Prenons le programme de validation de fiabilité des I/O de SQL Server qui liste entre autres ce qu'un vendeur de stockage doit respecter en matière d'I/O pour être compliant avec SQL Server et en particulier ceux qui nous concernent ici :

• la garantie d'écriture sur un média durable qui est étroitement liée au protocole WAL
• le support d'utilisation des fonctionnalités Write-Through et FUA.

Même si SQL Server ouvre ses fichiers avec l'option FILE_FLAG_WRITETHROUGH (avec la primitive CreateFile()) cela ne garantie pas qu'il ira écrire directement sur un support "physique" si on le prend au sens strict du terme à savoir les disques eux-mêmes. En effet, les caches de stockage d'entreprises avancés (la plupart des cartes contrôleurs RAID font la même chose) ne désactivent pas leurs caches même avec l'utilisation d'une telle commande. D'ailleurs la documentation Microsoft le stipule clairement ici:

Advanced caching implementations will handle the FILE_FLAG_WRITE_THROUGH request by not disabling the controller cache because they can provide true rewrite capabilities in the event of a system reset, power failure, or other failure point.

I/O transfers without the use of a cache can be significantly longer due to the mechanical time needed to move the drive heads, spin rates, and other limiting factors.

Maintenant si on regarde du côté de certains vendeurs de stockage (j'en prends 2 avec qui j'ai déjà travaillé), voici comment il traite et valide ces 2 points dans le cadre de ce fameux programme de validation de fiabilité I/O pour SQL server :

- Hitachi avec leurs baies de stockage HDS qui valide ce point par un système de cache (write-back) redondé et protégé par batteries
- EMC avec leurs baies EMC Symetric qui valide également ce point par le même type mécanisme.

Tout cela pour dire que l'acquittement se fait la plupart du temps dans les caches intermédiaires des SAN (voir contrôleurs RAID ce qui ne laisse aucune possibilité à SQL Server d'écrire sur les disques par lui même.

Une petite précision également sur le support de Microsoft concernant les environnements virtualisés sous VMware et SQL Server : Le support est bien pris en charge par Microsoft maintenant. Cela signifie que Microsoft pourra donc se coordonner avec l'éditeur de logiciel tiers pour établir un diagnostique avant de demander une dé-virtualisation complète (ce qui peut toutefois arriver je le conçois).

++

[SQLpro]

...En effet, les caches de stockage d'entreprises avancés (la plupart des cartes contrôleurs RAID font la même chose) ne désactivent pas leurs caches même avec l'utilisation d'une telle commande.

Mais note qu'il est souvent intéressant de le faire... En effet et paradoxalement, cela permet parfois d'améliorer les performances. teste le !

A +

[mikedavem]

Tout à fait d'accord avec toi pour l'avoir eu aussi testé dans certaines situations

++