Passage de smallint vers int

bonjour a tous

je dois procéder a changer le type de données d'une très grande table de smallint vers int ,et ce ci après avoir atteint la value max du smallint 32767

En passant par une Opération de type

Code:

---

Alter Table alter column

---

, cette opération continue sans avoir un fin et finalement je viens de

découvrir une saturation du partition suite a une autogrowth LOG

j'ai essayer de mettre la base en mode simple , bulk-logged mais finalement j'ai eu la même résultat saturation partition

Pour INFO J'ai 38 GO comme espace libre et la taille du table est 50GO

Quelle serait la solution qui me permet de changer le type du ce colonne sans avoir eu une saturation partition

Augmenter la taille de votre disque et la taille du journal de transaction est l'unique solution.

En effet, SQL Server à besoin de journaliser toutes les données de la table pour qu'en cas de problème il puisse revenir à l'état antérieur. Cela s’appelle la gestion des transactions.
Que vous soyez en mode SIMPLE ou FULL de récupération, ne change rien à la quantité de données qui doit être journalisée pour satisfaire la finalisation de la requête.

A +

Bonjour,

Alternativement, vous pouvez créer une table qui a précisément la même structure, à l'exception de la colonne qui doit changer de type de données.
Ensuite, vous copiez les lignes de l'ancienne table vers la nouvelle par lots, par exemple, de 100000 lignes.

Une fois toutes les lignes déplacées, vous supprimez l'ancienne table, et renommez la nouvelle par le nom de l'ancienne.
Si votre application utilise des vues, c'est encore plus simple : il suffit de changer la définition de la vue pour qu'elle spécifie la nouvelle table.

En procédant par lots de lignes, si vous êtes en mode de récupération :

• SIMPLE, le fichier du journal des transactions atteindra une certaine taille puis devrait ne plus en changer ensuite
• FULL ou BULK_LOGGED, si vous prenez des sauvegardes fréquentes du fichier du journal des transactions, cela devrait produire le même effet

L'idéal est de réaliser un tel déplacement lorsque la charge que subit la base de données est la plus basse.

@++ ;)

Attention pour la solution préconisée par Nicolas, il faut impérativement que personne ne travaille sur la base pendant toute la manoeuvre, sans quoi vous risquez de perdre des données !

A +