Série de posts "A SQL Server DBA myth a day" de Paul S. Randal
Je suis retombé aujourd'hui sur un des posts de cette série que Paul S. Randal a publiée durant le mois d'avril 2010, et je me suis dit que ça serait pas mal de vous en faire part, au cas où vous ne l'auriez pas vue.
SQL Server ne constitue pas ma principale zone d'intervention / de compétence mais comme il est une brique majeure de l'écosystème dans lequel je travaille, je tente d'avoir un minimum de veille dessus.
Et justement cette série de posts est assez intéressante dans le sens qu'elle donne des informations qu'on peut garder en tête pour creuser plus tard si le besoin se présente, lorsqu'on a un doute sur un de ces fameux mythes (des liens pour approfondir sont en général donnés dans le post).
En plus j'aime bien la façon d'écrire de Paul : le début du post sur le shrink des fichiers de données m'a beaucoup amusé :-)
J'ai mis en avant (en gras) les entrées dont la connaissance me parait importante du point de vue du développeur, et non pas que du point de vue du DBA.
- in-flight transactions continue after a failover
- DBCC CHECKDB causes blocking
- instant file initialization can be controlled from within SQL Server
- DDL triggers are INSTEAD OF triggers
- AWE must be enabled on 64-bit servers
- three null bitmap myths
- multiple mirrors and log shipping load delays
- unicorns, rainbows, and online index operations
- data file shrink does not affect performance
- database mirroring detects failures immediately
- database mirroring failover is instantaneous
- tempdb should always have one data file per processor core
- you cannot run DMVs when in the 80 compat mode
- clearing the log zeroes out log records
- checkpoint only writes pages from committed transactions
- corruptions and repairs
- page checksums
- FILESTREAM storage, garbage collection, and more
- TRUNCATE TABLE is non-logged
- restarting a log backup chain requires a full database backup
- corruption can be fixed by restarting SQL Server
- resource governor allows IO governing
- lock escalation
Personnellement, j'étais victime de ce mythe jusqu'à il y a peu.
En fait j'ai découvert la vérité en prenant la peine de lire la documentation un peu avant le post de Paul. Lock Escalation (Database Engine) : "The Database Engine does not escalate row or key-range locks to page locks, but escalates them directly to table locks."
Il me semblait logique que le moteur passe par des niveau intermédiaires avant d'arriver au lock de table, mais non. Toujours vérifier ses hypothèses, toujours ! - twenty six restore myths
- fill factor
- nested transactions are real
Au passage, j'avais écris à ce sujet il y a quelques temps : SQL Server : à propos des transactions “imbriquées”
La conclusion de Paul est bien plus radicale que la mienne. - use BACKUP WITH CHECKSUM to replace DBCC CHECKDB
- BULK_LOGGED recovery model
- fixing heap fragmentation
- backup myths
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
