SQL Server comment contourner le remplissage du journal des transactions lors de la mise à jour d'une colonne vers un int

J'ai une table SQL Server 2005 appelée BRITTNEY_SPEARS_MARRIAGESet elle contient les colonnes suivantes:

MarrigeId tinyint, 
HusbandName varchar(500),
MarrigeLength int

Maintenant j'ai une autre table BRITTNEY_SPEARS_MARRIAGE_STORIES

StoryId int, 
MarriageId tinyint, 
StoryText nvarchar(max)

Le problème est que nous voulons mettre à jour la MarrigeIdcolonne vers un à intpartir d'un tinyint. Nous pensons simplement que Brittney va avoir beaucoup de mariages avant que tout soit dit et fait.

Maintenant, la BRITTNEY_SPEARS_MARRIAGE_STORIEStable contient 18 millions de lignes (hé la fille a des problèmes) donc quand nous allons faire la mise à jour, le journal des transactions se remplit et notre boîte SQL Server meurt.

Comment contourner cela?

Est-il possible de dire "Hey SQL Server, je vais mettre à jour cette colonne et l'agrandir. Faites-moi confiance sur ce SQL Server. Veuillez ne pas remplir le journal des transactions pendant que vous essayez de tout valider?"

Il n'y a aucun moyen de dire à SQL Server de ne pas utiliser le journal des transactions.

Ce que vous pouvez faire est de définir le modèle de récupération de la base de données sur SIMPLE, ce qui écrasera les anciennes entrées de journal si de l'espace est nécessaire. Cependant, vous ne devez pas le faire sur votre serveur de production, car vous ne pourrez pas effectuer certains types de restaurations, telles que les restaurations ponctuelles.

Alternativement, vous pouvez définir un fichier journal des transactions plus volumineux - en règle générale, je m'assurerais que A) votre journal des transactions dispose d' au moins 1,5 fois plus d'espace libre que la taille de votre table ou B) que votre journal des transactions peut se développer automatiquement sur un lecteur disposant d' au moins environ de cette quantité d'espace disque libre.

Vous pouvez libérer de l'espace du journal des transactions en sauvegardant le journal. Si vous ne vous souciez pas du contenu du journal, jetez le fichier. Un raccourci pour cela est BACKUP LOG <Your Database Name> TO DISK = 'NUL:'. Encore une fois, ne faites pas cela sur un serveur de production à moins d'être absolument sûr d'en comprendre les implications.

Une autre chose à laquelle vous devez faire attention (bien que cela ne soit pas tout à fait pertinent à votre question) est de vous assurer que la table que vous développez a un index cluster défini dessus. Si ce n'est pas le cas, la table peut entraîner une très grande quantité de fragmentation de segment de mémoire et devenir potentiellement inutilement volumineuse lors d'un changement comme celui-ci.

• Déposez toutes les clés étrangères
• Créer de nouvelles tables avec intau lieu detinyint
• Déplacez les lignes par lot de 1000 (insérez-les dans le nouveau tableau, supprimez-les de l'ancien)
• Laissez tomber les anciennes tables
• Renommez les nouvelles tables aux anciens noms en utilisant sp_rename
• Recréez les clés étrangères

pS Si votre journal des transactions est volumineux ... vérifiez votre modèle de récupération. Si votre modèle de récupération ne l'est pas simple, combien de temps s'est-il écoulé depuis la dernière sauvegarde du journal?