La restauration d'une base de données SQL à partir d'une sauvegarde reconstruit-elle ses index?

10

La restauration d'une base de données SQL à partir d'une sauvegarde reconstruit-elle ses tables et index à partir de zéro? Ou le conserve-t-il dans le même ordre physique interne qu'il était au moment de la sauvegarde?

Nous utilisons SQL 2000 avec la sauvegarde compressée Quest Lightspeed, si cela fait une différence.

sql-server restore

— BradC
source

16

La réponse est non, quel que soit le logiciel de sauvegarde utilisé.

Une sauvegarde est une opération physique, pas une opération logique. Il lit toutes les extensions contenant des pages allouées (c'est-à-dire que même si une seule page d'une extension de 8 pages est allouée, il sauvegarde l'intégralité de 64 Ko), et il le fait dans l'ordre physique.

Une restauration est une opération physique, pas une opération logique. Il établit les étendues à leur place légitime dans les fichiers de données.

La reconstruction d'un index (ou quelque chose du genre) est une opération logique qui doit être journalisée. La sauvegarde et la restauration manipulent directement les fichiers de données, sans passer par le pool de tampons, ce qui explique pourquoi cela ne peut pas être fait. Une autre raison pour laquelle cela ne peut pas être fait est que la sauvegarde et la restauration n'ont aucune compréhension de ce qui est contenu dans les données en cours de sauvegarde.

La principale raison pour laquelle cela ne peut pas être fait, cependant, est que le déplacement des pages pendant une opération de restauration briserait les pointeurs de l'arborescence b. Si la page A pointe vers la page B, mais que la page A est déplacée par le processus de restauration, comment la page B est-elle mise à jour pour pointer vers la page A? S'il est mis à jour immédiatement, il peut être remplacé par le reste du processus de restauration. S'il est mis à jour différé, que se passe-t-il si le processus de restauration a restauré un journal de transactions qui a supprimé la page A ou la page B? Ça ne peut tout simplement pas être fait.

Conclusion - la sauvegarde et la restauration sont des opérations physiques qui ne modifient jamais les données.

J'espère que cela t'aides!

PS Bien qu'il ne réponde pas directement à cette question, consultez l'article que j'ai écrit pour le magazine TechNet de juillet qui explique comment les différentes sauvegardes fonctionnent en interne: Comprendre les sauvegardes SQL Server . Le magazine de septembre présentera le prochain de la série sur la compréhension des restaurations.

— Paul Randal
source

2

J'adore le fait que vous ayez expliqué que l'indexation est une opération logique.

— Jim B

Ah, ça a du sens. La sauvegarde saisit les extensions physiques complètes de 64k, pas les pages de données de 8k.

— BradC

Ça n'a pas de sens. Les opérations de sauvegarde compressent fréquemment les données qu'elles sauvegardent, et c'est le genre de «changement» dont nous parlons: après tout, les index peuvent être recréés à partir des tables, ce sont des données redondantes (à condition que le schéma soit sauvegardé , bien sûr). La vraie raison est la paresse des développeurs de bases de données.

— John

1

@John Que dites-vous est un non-sens? La compression n'est mentionnée nulle part ici - il suffit de reconstruire les index, ce qui n'est en rien la même chose que la compression (qui ne change pas les pages ou leur emplacement dans la base de données pendant une restauration, contrairement à une reconstruction). Recréer des index à partir de zéro lors d'une restauration serait incroyablement lent par rapport à la simple restauration à partir de la sauvegarde. Je pense que vous vous méprenez sur quelque chose ici.

— Paul Randal

La suppression et la reconstruction des index est un type de compression, et la compression peut tout changer, selon le type de compression. La compression avec perte dans le traitement d'image est toujours appelée compression. Tout mécanisme qui représente des informations données dans un espace plus petit est une forme de compression, et la suppression d'index en est un exemple trivial. La lenteur du temps de reconstruction peut en effet être un véritable argument, du moins contre l'implémentation qui en vaut la peine.

— John

6

Une sauvegarde SQL native n'est qu'un vidage page par page des fichiers de sauvegarde, donc la réponse est «non». Une sauvegarde Quest lightspeed utilise probablement une sorte d'algorithme de compression et de compression, mais elle ne "reconstruira" toujours pas les fichiers de données ou les index, ce qui prendrait un temps horriblement long sur une grande base de données.

— Aaron Alton
source

Oui, mais il faut quand même écrire chaque page sur le disque. Pourquoi ne pas les écrire dans un ordre logique, plutôt que dans un ordre fragmenté? (Peut-être s'agit-il davantage d'une question de sauvegarde plutôt que d'une question de restauration : la sauvegarde écrit-elle les pages dans l'ordre physique ou dans l'ordre logique?)

— BradC

en supposant qu'un produit a écrit les données dans l'ordre d'index, dans quel ordre souhaitez-vous que la table soit enregistrée? Disons que j'ai une table avec 3 colonnes product_id, productname et price. Quelle est la bonne colonne sur laquelle trier pour enregistrer les pages dans l'ordre indexé? BTW rien ne vous empêche d'indexer sur la table entière (un index clusterisé) ou chacune des lignes (index composite).

— Jim B

@ Jim B: C'est facile. Les tables seraient enregistrées dans un ordre d'index cluster. Les index non groupés seraient stockés dans l'ordre des clés. Les tas seront conservés dans leur ordre d'origine (non triés). (Aaron et Paul ont mentionné des raisons valables pour lesquelles la sauvegarde / restauration ne fait pas cela. Ne pas être en mesure de déterminer "l'ordre préféré" n'est pas l'une de ces raisons. Sinon, une reconstruction complète de l'index aurait le même problème. )

— BradC

Les données sont sauvegardées dans le même ordre de page physique que celui dans lequel elles sont enregistrées dans les fichiers de base de données. Lorsque les données sont restaurées, elles sont restaurées dans le même ordre de page qu'elles ont été sauvegardées. SQL ne déplace pas les données pour diverses raisons. Notamment, il pourrait y avoir des problèmes avec les transactions de restauration des journaux et les problèmes de chaînage des pages, sans parler des énormes quantités de temps supplémentaire nécessaires pour mélanger les données sur les bases de données multi-TB.

— mrdenny

2

La sauvegarde se fait régulièrement et très souvent (j'espère). Les concepteurs ont donc veillé à ce que la sauvegarde soit aussi rapide que possible. Quelle est l'E / S la plus rapide? Séquentiel. Vous lisez les blocs des disques dans l'ordre physique exact, vous avez les meilleures performances.

Pourquoi diable la base de données devrait-elle effectuer des opérations d'E / S aléatoires lourdes chaque nuit , jetant la tête des disques partout? La différence serait d'environ deux ordres de grandeur. Il n'y a aucun gain possible à cela.

— kubanczyk
source

Je suis d'accord avec votre point de vue global, mais selon la configuration de stockage sous-jacente, les E / S aléatoires peuvent ne pas être de l'ordre de grandeur pires que les E / S séquentielles (un lecteur SAN qui est réparti sur des dizaines de broches, par exemple). En fait, si le fichier de données est fragmenté sur le disque dur, même les E / S "séquentielles" ne sont pas vraiment séquentielles. Mais les points de Paul l'emportent quand même (le problème avec la mise à jour des pointeurs, et que la défragmentation devrait être une opération enregistrée)

— BradC

0

Hmmm. BradC, avez-vous déjà travaillé avec Firebird / Interbase - où l'utilitaire principal de sauvegarde / restauration / API est plus semblable à la "Copier la base de données ..." du SSMS / EM? Si oui, sachez que MS SQL Server n'est PAS comme ça.

Une sauvegarde SQLServer est plus un vidage de base de données qui est restauré "TEL QUEL" - c'est donc plus comme un raccourci en ligne confortable pour une opération "détacher-copier-rattacher à un autre endroit". La base de données restaurée est presque une copie exacte du fichier de base de données d'origine (presque parce que vous pouvez modifier le placement des fichiers de base de données d'une base de données restaurée) ...

— Fabricio Araujo
source