Un de mes amis m'a dit aujourd'hui qu'au lieu de faire rebondir SQL Server, je pouvais simplement détacher puis rattacher une base de données et cette action effacerait les pages et les plans de la base de données donnée du cache. Je suis en désaccord et je fournis ma preuve ci-dessous. Si vous n'êtes pas d'accord avec moi ou avez une meilleure réfutation, fournissez-la par tous les moyens.
J'utilise AdventureWorks2012 sur cette version de SQL Server:
SELECT @@ VERSION; Microsoft SQL Server 2012 - 11.0.2100.60 (X64) Developer Edition (64 bits) sur Windows NT 6.1 (Build 7601: Service Pack 1)
Après avoir chargé la base de données, j'exécute la requête suivante:
Tout d'abord, exécutez le script d'engraissement AW de Jonathan K trouvé ici:
---------------------------
- Étape 1: Bpool Stuff?
---------------------------
USE [AdventureWorks2012];
ALLER
SÉLECTIONNER
OBJECT_NAME (p.object_id) AS [ObjectName]
, p.object_id
, p.index_id
, COUNT (*) / 128 AS [taille du tampon (Mo)]
, COUNT (*) AS [buffer_count]
DE
sys.allocation_units AS a
INNER JOIN sys.dm_os_buffer_descriptors AS b
ON a.allocation_unit_id = b.allocation_unit_id
INNER JOIN sys.partitions AS p
ON a.container_id = p.hobt_id
OÙ
b.database_id = DB_ID ()
ET p.object_id> 100
PAR GROUPE
p.object_id
, p.index_id
COMMANDÉ PAR
buffer_count DESC;
Le résultat est affiché ici:
Détachez et rattachez la base de données, puis réexécutez la requête.
---------------------------
- Étape 2: détacher / attacher
---------------------------
- Détacher
UTILISER [maître]
ALLER
EXEC master.dbo.sp_detach_db @dbname = N'AdventureWorks2012 '
ALLER
-- Attacher
UTILISER [maître];
ALLER
CRÉER UNE BASE DE DONNÉES [AdventureWorks2012] ON
(
FILENAME = N'C: \ sql server \ files \ AdventureWorks2012_Data.mdf '
)
,
(
FILENAME = N'C: \ sql server \ files \ AdventureWorks2012_Log.ldf '
)
POUR FIXER;
ALLER
Qu'y a-t-il dans le pool maintenant?
---------------------------
- Étape 3: Bpool Stuff?
---------------------------
USE [AdventureWorks2012];
ALLER
SÉLECTIONNER
OBJECT_NAME (p.object_id) AS [ObjectName]
, p.object_id
, p.index_id
, COUNT (*) / 128 AS [taille du tampon (Mo)]
, COUNT (*) AS [buffer_count]
DE
sys.allocation_units AS a
INNER JOIN sys.dm_os_buffer_descriptors AS b
ON a.allocation_unit_id = b.allocation_unit_id
INNER JOIN sys.partitions AS p
ON a.container_id = p.hobt_id
OÙ
b.database_id = DB_ID ()
ET p.object_id> 100
PAR GROUPE
p.object_id
, p.index_id
COMMANDÉ PAR
buffer_count DESC;
Et le résultat:
Toutes les lectures sont-elles logiques à ce stade?
--------------------------------
- Étape 4: lectures logiques uniquement?
--------------------------------
USE [AdventureWorks2012];
ALLER
ACTIVER STATISTIQUES IO;
SELECT * FROM DatabaseLog;
ALLER
DÉSACTIVER LES STATISTIQUES IO;
/ *
(1597 ligne (s) affectée (s))
Tableau «DatabaseLog». Nombre de balayages 1, lectures logiques 782, lectures physiques 0, lectures anticipées 768, lectures logiques lob 94, lectures physiques lob 4, lectures anticipées lob 24.
* /
Et nous pouvons voir que le pool de tampons n'a pas été totalement emporté par le détachement / attachement. On dirait que mon copain avait tort. Quelqu'un est-il en désaccord ou a-t-il un meilleur argument?
Une autre option consiste à déconnecter puis à mettre en ligne la base de données. Essayons cela.
--------------------------------
- Étape 5: Hors ligne / en ligne?
--------------------------------
ALTER DATABASE [AdventureWorks2012] SET OFFLINE;
ALLER
ALTER DATABASE [AdventureWorks2012] SET ONLINE;
ALLER
---------------------------
- Étape 6: Bpool Stuff?
---------------------------
USE [AdventureWorks2012];
ALLER
SÉLECTIONNER
OBJECT_NAME (p.object_id) AS [ObjectName]
, p.object_id
, p.index_id
, COUNT (*) / 128 AS [taille du tampon (Mo)]
, COUNT (*) AS [buffer_count]
DE
sys.allocation_units AS a
INNER JOIN sys.dm_os_buffer_descriptors AS b
ON a.allocation_unit_id = b.allocation_unit_id
INNER JOIN sys.partitions AS p
ON a.container_id = p.hobt_id
OÙ
b.database_id = DB_ID ()
ET p.object_id> 100
PAR GROUPE
p.object_id
, p.index_id
COMMANDÉ PAR
buffer_count DESC;
Il semble que l'opération hors ligne / en ligne ait beaucoup mieux fonctionné.
