Est-il correct de passer d'une récupération complète à une récupération simple dans Sql Server
J'ai une ancienne base de données - une adhésion/un rôle utilisateur qui a été configuré automatiquement par une application ASP.Net il y a 2 ans:
La version Sql Server en cours d'exécution est la suivante: Sql Server 10.5.1617
Le fichier journal de la base de données des utilisateurs est énorme (le fichier ldf est environ 400 fois la taille du fichier mdf).
Le modèle de récupération est actuellement défini sur "Complet". Je comprends ce que c'est - et je n'ai pas besoin d'une restauration ponctuelle.
Si j'ai simplement changé le modèle de récupération en "Simple" depuis Sql Server Management Studio:
... et cliqué sur OK pour enregistrer les modifications - est-ce que je risquerais ma base de données actuelle de quelque façon que ce soit? Ou Sql Server convient-il d'apporter des modifications comme celle-ci aux bases de données actives? Et le fichier journal se rétrécirait-il automatiquement?
Merci pour vos conseils,
Marque
Je le ferais lorsque la base de données est en faible activité (fin de journée, nuit, premier matin). Je ne recommanderais JAMAIS d'apporter des modifications comme celle-ci à la base de données en direct au milieu des heures de travail. Probablement une bonne idée de changer la base de données en lecture seule ou de vous assurer qu'aucun utilisateur/application ne la frappe.
-Exécutez une sauvegarde complète de la base de données/fichier journal en question, tout en étant en mode de récupération complète. Cela vous donnera un point de départ au cas où quelque chose se boucherait et vous pouvez simplement le restaurer.
-Passez à la récupération SIMPLE, je n'aime pas utiliser l'interface graphique, je l'écrirais.
Voici un excellent article de MSDN sur les éléments à prendre en compte lors du changement de votre modèle de sauvegarde: http://technet.Microsoft.com/en-us/library/ms190203 (v = sql.105) .aspx
Lorsque vous passez à la récupération simple, le journal est tronqué lorsqu'un CHECKPOINT se produit (en tant que tâche d'arrière-plan - automatique ou exécutant manuellement un CHECKPOINT) sur la base de données.
Cela signifie simplement que la partie du journal sera réutilisée par le serveur SQL au lieu de s'agrandir pour conserver un enregistrement de toutes les transactions (tout comme la récupération complète jusqu'à ce que vous preniez la sauvegarde du journal).
Cela ne signifie pas que vous récupérerez de l'espace disque.
Pour récupérer de l'espace disque, vous devez réduire le fichier journal.
FAIRE c'est dans un temps moins/calme quand il y a une activité utilisateur minimale
use master
go
--- first take a FULL backup
backup database db_name to disk = 'D:\backups\db_name_FULL.bak' with stats =10, compression, init
go
use db_name
go
---- manually issue a checkpoint
checkpoint
go
checkpoint -- run twice so the log file wraps around
go
----- now shrink the log file to reclaim disk space
dbcc shrinkfile(db_name_LOG,xxMB) -- xxMB is the size that you want.
go
** Assurez-vous de ne pas dimensionner le fichier journal trop petit car il devra éventuellement grossir. Son serveur SQL coûte très cher pour déclencher des événements AUTO-GROWTH.
Vous pouvez certainement changer une base de données en SIMPLE modèle de récupération. Le "risque" est que vous pourriez avoir besoin de restaurations ponctuelles, mais vous avez dit que ce n'était pas une exigence.
Le fichier journal énorme est probablement dû au fait que le journal des transactions n'est pas sauvegardé.
Si vous passez en mode SIMPLE, vous devrez réduire le fichier. Comme ça:
USE DatabaseName;
CHECKPOINT;
DBCC SHRINKFILE(LogFileName, size of log);
Répétez si nécessaire pour obtenir une taille raisonnable du fichier.
Pensez alors si vous voulez vraiment un modèle de récupération COMPLET. Si tel est le cas, configurez des sauvegardes de journal régulières et le fichier journal restera sous contrôle. Faites une nouvelle sauvegarde COMPLÈTE, puis les sauvegardes LOG devraient fonctionner correctement.
Vous pouvez changer cela à tout moment de complet à simple. Après avoir effectué la modification, exécutez manuellement le point de contrôle pour les bases de données, vous pouvez alors commencer à réduire le journal des transactions.
Cela nécessite un court verrou sur la base de données pendant la modification ou tant que vous n'avez pas une tonne d'utilisateurs sur le système, c'est bien de le faire à tout moment. Sinon, attendez après les heures.
N'oubliez pas de le supprimer de vos travaux de sauvegarde de journal pour arrêter les échecs de travaux.