Lorsque vous passez du tableau A au tableau B, les données d'index sont-elles également commutées?


8

J'ai actuellement une table assez grande (5-7 millions de lignes). Cette table est reconstruite régulièrement par une procédure qui construit les données dans une table intermédiaire, puis bascule les données dans la table de production à l'aide de l' ALTER TABLE .. SWITCH TO ..instruction.

Exemple:

BEGIN TRAN;

-- Rebuild indexes
ALTER INDEX IX_NC_GroupEvent_staging_GroupName on [dbo].[GroupEvent_staging]
   REBUILD;

ALTER INDEX IX_NC_GroupEvent_staging_Created ON [dbo].[GroupEvent_staging]
   REBUILD;

-- Empty production table
TRUNCATE TABLE [dbo].[GroupEvent];

-- Switch data from staging-table into production table
ALTER TABLE [dbo].[GroupEvent_staging] SWITCH TO [dbo].[GroupEvent]

COMMIT;

Lorsque cette opération est effectuée, l'état actuel des index (ou des données d'index si vous le souhaitez) est-il également modifié? Je pose la question pour 2 raisons:

1) Afin d'exécuter une SWITCH TOinstruction, une condition est que la table source et la table cible doivent contenir des index identiques. Cela m'amène à croire que les données d'index pourraient également être changées, mais je ne sais pas comment le vérifier.
2) Le principal avantage de la construction de la table de cette manière est d'éviter d'effectuer un travail excessif sur la table de production pendant son utilisation. Naturellement, cela me rendrait très heureux si je pouvais reconstruire des index sur la table de transfert et faire basculer les index reconstruits vers les index de production avec la table.

Réponses:


6

les données d'index sont-elles également commutées?

Oui. Ce serait bizarre si ce n'était pas le cas, car les requêtes retourneraient les mauvais résultats ou nous devions reconstruire manuellement les index après la commutation.

Je ne sais pas comment vérifier cela

Une façon serait d'essayer

CREATE TABLE [dbo].[GroupEvent]
  (
     GroupName VARCHAR(100) INDEX IX_NC_GroupEvent_staging_GroupName,
     Created   DATETIME INDEX IX_NC_GroupEvent_staging_Created 
  );

CREATE TABLE [dbo].[GroupEvent_staging]
  (
     GroupName VARCHAR(100) INDEX IX_NC_GroupEvent_staging_GroupName,
     Created   DATETIME INDEX IX_NC_GroupEvent_staging_Created 
  );

INSERT INTO [dbo].[GroupEvent_staging]
VALUES      ('Group1',GETDATE()),
            ('Group2',GETDATE());

ALTER INDEX IX_NC_GroupEvent_staging_GroupName ON [dbo].[GroupEvent_staging] REBUILD;

ALTER INDEX IX_NC_GroupEvent_staging_Created ON [dbo].[GroupEvent_staging] REBUILD;

SELECT index_id,
       allocated_page_file_id,
       allocated_page_page_id
FROM   sys.dm_db_database_page_allocations(DB_ID(), OBJECT_ID('[dbo].[GroupEvent_staging]'), NULL, NULL, 'DETAILED')
WHERE  is_allocated = 1; 

-- Empty production table
TRUNCATE TABLE [dbo].[GroupEvent];

-- Switch data from staging-table into production table
ALTER TABLE [dbo].[GroupEvent_staging] SWITCH TO [dbo].[GroupEvent];

SELECT index_id,
       allocated_page_file_id,
       allocated_page_page_id
FROM   sys.dm_db_database_page_allocations(DB_ID(), OBJECT_ID('[dbo].[GroupEvent]'), NULL, NULL, 'DETAILED')
WHERE  is_allocated = 1; 

SELECT GroupName
FROM   [dbo].[GroupEvent];

DROP TABLE [dbo].[GroupEvent], [dbo].[GroupEvent_staging]; 

Le seul objet auquel on a accédé dans le processus de renvoi des deux lignes était l'index indiquant que les données devaient avoir été commutées.

entrez la description de l'image ici

Ce qui précède compare également le résultat de sys.dm_db_database_page_allocationspour GroupEvent_Stagingavant le commutateur avec une requête similaire pour GroupEventaprès le commutateur pour voir que les pages restent les mêmes pour le segment de mémoire lui-même (index_id = 0) et les deux index non clusterisés (ID 2 et 3). Cela montre que le commutateur était des métadonnées uniquement avec la propriété des pages allouées transférées.

entrez la description de l'image ici


Merci non seulement d'avoir répondu à la question, mais aussi d'expliquer comment vous en êtes arrivé à la conclusion. Génial!
krystah
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.