Le journal des transactions a grandi énorme après le plan de maintenance pour reconstruire IDEX
Il y a quelques jours, je testais quelques affaires à l'aide des plans de maintenance dans SQL Server 2008.
J'ai créé un pour reconstruire des indices et prendre une sauvegarde complète chaque semaine. (Je sais, mauvaise chose que j'ai découvert aujourd'hui).
La chose est que le journal de transaction a augmenté beaucoup (environ 80 Go et le dB est de 60 Go), la sauvegarde n'a pas fonctionné. Maintenant, j'ai googler toute la journée pour voir s'il existe un moyen de rétrécir le journal de transaction à la taille qu'elle était auparavant, ce qui était quelque chose comme 200 Mo.
METTRE À JOUR
Ceci est sur notre serveur de production et le plan de maintenance était la suivante:
Index de reconstruction
Sur le succès Sauvegarde complète DB
Sur le succès Supprimer les sauvegardes de plus de deux semaines.
Cela n'a pas fini, il s'est cassé à un moment donné, je suppose que cela a pris beaucoup trop de temps pour reconstruire les index. Donc, la sauvegarde n'a pas eu lieu.
Nous sauvegardons également des journaux de transaction toutes les heures.
Est-ce possible? Pourquoi cela arrive-t-il? Je sais que lorsque la reconstruction de la reconstruction crée une copie de l'indice dans le journal de transaction ou quelque chose comme ça, mais est-il possible de se débarrasser de cette copie?
C'est ce que j'ai sur l'historique des tâches, il semble donc que cela ressemble à une raison quelconque, il a échoué lors de la création des index et, étant donné que le plan était sur le succès, la sauvegarde est-elle arrêtée là-bas.
Un message :
Exécuté comme utilisateur: Shocklogic\db1 $. ... Ressais: 2013-08-05 03: 01: 03.43 Source: Rebuild Index EXECUTIVE DE QUERY "Alter Index [pk_activitispergroup] sur [DBO]. [Acti ...".: 12% Terminer les progrès de la fin: 2013- 08-05 03: 01: 03.43 Source: Demande d'exécution de l'index de reconstruction "Utilisez [EventLogic]".: 12% Terminer les progrès de la fin de la progression: 2013-08-05 03: 01: 03.52 Source: Rebuild Index EXECUTATION DE QUERY "Alter Index [Pk_activitiesPerhotelcat] sur [DBO]. [A ... ".: 12% Terminer complète Progress Progress: 2013-08-05 03: 01: 03.52 Source: Rebuild Index EXECUTATION DE QUERY" Utilisez [EventLogic] ".: 12% Fin complète Progress Progress: 2013-08-05 03: 01: 03.69 Source: Rebuild Index Task Executing Query "Alter Index [pk_activitisPerhotelcat_old] sur [Dbo ...".: 12% Terminer la fin progression progressive: 2013-08-05 03 : 01: 03.69 Source: Reconstruction de la requête de la tâche d'index de reconstruction "Utilisez [EventLogic]".: 12% Terminer les progrès de la fin de la marche Progrès: 2013-08-05 03: 01: 08.61 Source: Rebuild Index EXECUTATION DE QUERY "Alter Index [_DTAINDEX_ACTIVISPERPERSON_10_292 .. . ".: 13% complet en D Progress Progress: 2013-08-05 03: 01: 08.61 Source: Rebuild Index Exécuter la requête "Utilisez [EventLogic]".: 13% Terminer les progrès de la fin Progrès: 2013-08-05 03: 01: 12.85 Source: Index de reconstruction Demande d'exécution de tâches "Alter Index [_DTA_IDEX_ACTIVISPERPERPERSON_10_292 ...".: 13% Terminer les progrès de la fin Progrès: 2013-08-05 03: 01: 12.85 Source: Rebuild Index Tâche Exécution de requête "Utilisez [EventLogic]".: 13% complète fin Progrès progressif: 2013-08-05 03: 01: 20.44 Source: Rebuild Index EXECUTIVE DE QUERY "ALTER INDEX [IX_ACTIVISÉPERPERPERSON] sur [DBO] [ACT ...".: 13% Terminer les progrès de la fin: 2013-08- 05 03: 01: 20.44 Source: Rebuild Index Tâche Exécution de la requête "Utilisez [EventLogic]".: 13% Terminer les progrès de l'avancement des progrès: 2013-08-05 03: 01: 57.55 Source: Rebuild Index EXECUTATION DE QUERY "ALTER INDEX [PK_ACTIVISOPERPERPERSON ] Sur [DBO]. [ACT ... ".: 13% Terminer les progrès de la fin Progrès: 2013-08-05 03: 01: 57.55 Source: Rebuild Index Tâche Exécution de requête" Utilisez [EventLogic] ".: 14% complète fin Progrès progressif: 201 3-08-05 03: 01: 57.58 Source: Rebuild Index Tâche Exécution de la requête "Alter Index [pk_activitgroupinputTypes] sur [DBO] ....".: 14% Terminer les progrès de la fin de progression: 2013-08-05 03:01: 57.58 Source: Rebuild Index Tâche Exécutant la requête "Utilisez [EventLogic]".: 14% Terminer les progrès de la progression complète Progress: 2013-08-05 03: 01: 57.65 Source: Rebuild Index Tâche EXECUTATION DE QUERY "ALTER INDEX [PK_ACTIVITYPYPESTYPES] ON [DGO] . [Acti ... ".: 14% Terminer les progrès de la fin Progrès: 2013-08-05 03: 01: 57.66 Source: Rebuild Index Tâche Exécution de la requête" Utilisez [EventLogic] ".: 14% Terminer la fin progression progressive: 2013- 08-05 03: 01: 57.66 Source: Rebuild Index Tâche Exécuter la requête "Alter index [pk_activityptyptéforgroups] sur [DB ...".: 14% Terminer les progrès de la fin de la progression: 2013-08-05 03: 01: 57.66 Source: Reconstruire Index Tâche Exécuter la requête "Utilisez [EventLogic]".: 14% Terminer les progrès de la progression de la fin: 2013-08-05 03: 01: 57.74 Source: Rebuild Index Tâche EXECUTATION DE QUERY "ALTER INDEX [PK_ACTIVITYIUTTYPES] sur [DBO]. [ACTI. .. ".: 15% complet de fin de fin complète p ROGRESS: 2013-08-05 03: 01: 57.74 Source: Demande d'exécution de l'index de reconstruction "Utilisez [EventLogic]".: 15% Terminer fin de progression progression: 2013-08-05 03: 01: 57.77 Source: Exécution de la tâche d'index de reconstruction Query "alter index [pk _activité _ b7bcf0184055f19f] sur [D ...".: 15% Terminer les progrès de la fin Progrès: 2013-08-05 03: 01: 57.77 Source: Rebuild Index Tâche Exécuter la requête " Utilisez [EventLogic] ".: 15% Terminer les progrès des progrès: 2013-08-05 03: 01: 57.88 Source: Rebuild Index EXECUTIVE DE QUERY" ALTER INDEX [PK_ADDRESSFIRMATIONSCREENFIAMLAN ... ".: 15% Terminer les progrès de la fin: 2013 -08-05 03: 01: 57.88 Source: Index de reconstruction ... L'exécution de l'emballage faite ... L'étape a échoué.
La reconstruction d'un index a besoin d'un espace suffisant pour créer le nouvel index. Une règle de base simplifiée semble être que vous avez besoin d'environ 120% de l'espace utilisé par l'indice d'origine. Cela peut être dans la base de données ou dans TEMPDB, selon que Sort_IN_TEMPDB est ON ou OFF.
Si possible, avez de trier_in_tempdb = sur une réduction de la journalisation effectuée.
Si vous reconstruisez tous les index entre les sauvegardes du journal, toutes les journaux de réindexage de tous les index seront dans le fichier journal. Par conséquent, une réorganisation majeure doit avoir les ressources appropriées de l'espace disque, de l'espace de journal, etc. (Par exemple, vous pouvez essayer de réorganiser une table à la fois et de faire une sauvegarde de journal après chaque.)
Pour les besoins d'espace index: http://msdn.microsoft.com/en-us/library/ms191183 (v = SQL.110) .aspx Pour les journaux de transaction: http: // msdn.microsoft.com/en-us/library/ms184246.aspx
Vous pouvez essayer de passer à un modèle de récupération minimalement enregistré tel que simple ou groupk_logged. Toutefois, pour une base de données de production, vous devez peser les effets secondaires négatifs et déterminer ce qui est le mieux. (Un changement simple pour la réorganisation de la base de données devrait probablement être suivi en changeant à plein et en faisant une sauvegarde complète.)
Un fichier journal peut être rétréci, mais seulement après la libération des pages de commande élevée par une sauvegarde de journal. (Ceci est généralement un cycle de journal de sauvegarde, DBCC Shrinkfile, puis vérifiez l'espace et réessayez.)
Pour réduire le fichier journal, do non Utilisez DBCC Shrinkdatabase. Utilisez DBCC Shrinkfile (logfilename, Targetsize).
J'ai créé un pour reconstruire des indices et prendre une sauvegarde complète chaque semaine. (Je sais, mauvaise chose que j'ai découvert aujourd'hui).
Correct.
Ces processus doivent être séparés afin qu'ils puissent être exécutés de manière indépendante. Certainement, le processus de sauvegarde devrait procéder, que l'indice reconstruit ou non réussisse ou non. Mais ne vous inquiétez pas d'essayer de résoudre ce problème, car:
Reconstruire complètement les index tout le temps est rarement nécessaire et est généralement assez coûteux. Je recommande d'utiliser un processus plus intelligent qui détermine d'abord si un indice est fragmenté et de combien, puis prend des mesures appropriées. J'utilise et recommandé personnellement scripts de Ola Hallengren Pour ce faire cela.
La chose est que le journal de transaction a augmenté beaucoup (environ 80 Go et le dB est de 60 Go), la sauvegarde n'a pas fonctionné. Maintenant, j'ai googler toute la journée pour voir s'il existe un moyen de rétrécir le journal de transaction à la taille qu'elle était auparavant, ce qui était quelque chose comme 200 Mo.
Basé sur ce que vous m'avez dit dans les commentaires, la sauvegarde qui "échoua" (non exécutée) était la complète Sauvegarde. En supposant que le journal des transactions Les sauvegardes ont réussi tout le long, vous devriez pouvoir utiliser DBCC SHRINKFILE (ou l'interface graphique SSMS, qui est plus facile) de réduire le fichier journal à une taille raisonnable.
Je sais que lorsque la reconstruction de la reconstruction crée une copie de l'indice dans le journal de transaction ou quelque chose comme ça, mais est-il possible de se débarrasser de cette copie?
Vous ne pouvez pas l'empêcher d'être créé en premier lieu, c'est pourquoi faire des reconstitutions tout le temps est si chère et pourquoi je recommande d'utiliser les scripts comme mentionné.
Lorsque le journal de transaction est sauvegardé, l'espace utilisé peut alors être réutilisé, ou libéré à l'O/S dans le cadre d'un SHRINKFILE.
afin de libérer l'espace, vous devez d'abord modifier le modèle de récupération de plein en simple, vous pouvez libérer l'espace tel que vous avez mentionné.Après que vous avez terminé, vous pouvez revenir de simples à pleine de toute façon c'est une solution temporaire. Log va éventuellement pousser à nouveau plus tôt ou tard ..