ESt-ce que la vérification de page de la base de données Temps doit être en mode "None" plutôt qu'en mode "Checksum" pour de meilleure performance ?
D'avance, merci.
Version imprimable
ESt-ce que la vérification de page de la base de données Temps doit être en mode "None" plutôt qu'en mode "Checksum" pour de meilleure performance ?
D'avance, merci.
C'est une bonne idée, car les données de tempdb ne sont pas réellement transactionnelle.
Cependant, ayez un processus de vérification régulière d'intégrité physique des pages de tempdb, ou bien stoppez le service SQL Server ce qui recréé la base tempdb (à éviter, car pertes des stats "live").
A +
Je ne sais pas si cela est une si bonne idée.
Prenons le cas où un chargement est effectué dans une table temporaire. Si la vérification de page n'est pas effectuée et si une corruption se produit sur une page, SQL Server n'a aucun moyen de savoir si celle-ci est corrompue et la page peut potentiellement être réinjecté dans la base de données utilisateur sans aucun problème.
++
Par expérience tu sais bien que le moteur de stockage de MS SQL Server n'a pas de bug connus... Ce qui signifie qu'en cas de problème de page, cela sera vu au niveau du contrôleur avant même que SQL le calcule.
Pire encore, ce peut être le contrôleur qui est bugué, et dans ce cas, ni l'OS ni SQL Server ne le verra !
A +
Non bien sûr .. je ne parle pas du moteur SQL mais plutôt du stockage lui même. Effectivement le contrôleur pourra en principe le voir et on verra apparaître dans le journal des événements Windows une erreur de type IO mais cela n'empêchera pas SQL Server de propager cette page au travers des bases utilisateurs. Avec un peu de chance SQL Server pourrra détecter ce type d'erreur avec le message et empêcher cette propagation :
Citation:
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected ...)
Après effectivement il faudra choisir entre performance et sécurité ... bien que l'activation de CHECKSUM en principe ne soit plus vraiment un problème avec le nombre de CPU actuellement disponibles sur les serveurs (Je crois qu'on reste à < 2% de charge CPU en overhead).