Analyse de cryptage SQL 2008

Question

Nous avons récemment mis à niveau un serveur de base de données de SQL 2005 vers SQL 2008 64 bits. L'utilisation du processeur tourne souvent à 100% sur les quatre processeurs maintenant (cela ne s'est jamais produit sur le serveur SQL 2005). Quand je lance sp_lock, je vois un certain nombre de processus en attente sur une ressource appelée [ENCRYPTION_SCAN]. Je n'utilise aucune fonctionnalité de cryptage SQL 2008. Est-ce que quelqu'un sait pourquoi j'aurais des tâches en attente sur cette ressource? Il semble que chaque fois que j'ai quatre processus en attente sur cette ressource, le processeur atteint 100% sur les quatre processeurs.

Answer 1

Le chiffrement de données transparent (TDE) assure le chiffrement et le décryptage E/S en temps réel des fichiers de données et de journaux.

http://msdn.microsoft.com/en-us/library/bb934049.aspx

Avez-vous ce permis?

Mise à jour:

Pouvez-vous dire ce que les opérations sont bloqués? par exemple, des insertions, des suppressions, des mises à jour, des analyses d'index, etc.

TDE est le seul scénario dans lequel j'ai déjà vu une référence à un "scannage de cryptage". Une recherche rapide valide uniquement ceci:

... Le serveur démarre un thread d'arrière-plan (appelé scan ou scan de cryptage) .... Pendant l'exécution du DDL, un verrou de mise à jour est effectué sur la base de données. L'analyse de chiffrement, qui s'exécute de manière asynchrone sur le DDL, prend un verrou partagé. Toutes les opérations normales qui ne sont pas en conflit avec ces verrous peuvent continuer. Les opérations exclues incluent la modification de la structure de fichier et le détachement de la base de données.

msdn

Cela rend le son comme le « scan de chiffrement » en cours que vous voyez implique que le cryptage est activé et désactivé à plusieurs reprises sur la base de données, ou la clé est en train de changer, parce que ces retards devraient seulement être vu lorsque l'état de chiffrement change. Soit cela ou vous avez une très grande base de données, et quand il finit par se terminer le problème va tout simplement disparaître.

Essayez la requête suivante:

SELECT DB_NAME(e.database_id) AS DatabaseName, 
      e.database_id, 
      e.encryption_state, 
    CASE e.encryption_state 
       WHEN 0 THEN 'No key present - encryption unavailable' 
       WHEN 1 THEN 'Unencrypted' 
       WHEN 2 THEN 'Encryption in progress' 
       WHEN 3 THEN 'Encrypted' 
       WHEN 4 THEN 'Key change in progress' 
       WHEN 5 THEN 'Decryption in progress' 
    END AS encryption_state_desc, 
      c.name, 
      e.percent_complete 
    FROM sys.dm_database_encryption_keys AS e 
    LEFT JOIN master.sys.certificates AS c 
    ON e.encryptor_thumbprint = c.thumbprint 

Answer 2

J'ai été voir cette même culture question dans quelques endroits différents. Il n'a pas été prouvé définitivement, mais il semble que les opérations BULK INSERT ou SORT de longue durée contiennent un verrou ENCRYPTION_SCAN de manière pessimiste afin d'empêcher le démarrage d'une analyse de cryptage au milieu de l'opération. Recherchez un blog de CSS à ce sujet dans un proche avenir, je vais y revenir ici quand/si elle sort.