Discussion :

[Kropernic]

Bonjour,

Ce matin je teste le déploiement de modification faite sur une DB sur le serveur de dev vers le serveur de prod.

Pour cela, je fais :

1. clic droit sur la DB en question
2. déroulement du menu Tasks
3. choix de l'option Generate scripts

Une fois dans l'assistant, je choisis tous les objets que je désire scripter (il y en a un paquet) et dans les options, j'indique je souhaite scripter les données également pour les tables qui en contiennent.

Le script se fait sans souci et le sauve dans un fichier texte.

Je restaure ensuite la DB de prod sur le serveur de dev sous un nom bidon histoire de tester le script d'abord. La restauration s'effectue sans aucun souci.

Je charge donc le script dans SSMS et presse la touche F5 pour l'exécuter et là c'est le drame...

Cannot execute script.
Additional information :
Insufficient memory to continue the execution of the program. (mscorlib)

J'ai d'abord cru que c'était dû au fait que je faisais cela depuis mon laptop (qui n'a que 6 GB de ram) mais même depuis le serveur (avec ses 16 GB de ram), le problème est le même.

Durant la rédaction de ce message, j'ai réalisé que je pouvais demander de ne pas scripter les données pour ensuite relancer le process d'importation des données de bases qui alimentera les tables.

• Sont-ce les données qui causent ce manque de mémoire ??
• Quelle est la bonne manière de faire ce genre de déploiement ??

Merci d'avance à tous.

[Kropernic]

Hello,

Juste pour dire que le problème venait bien du fait d'avoir choisi de scripter les données également.

Je laisse cependant la discussion ouverte afin d'avoir des retours sur les bonnes pratiques à adopter.

[SQLpro]

C'est normal. Pour être transactionnellement cohérent, une fois les objets de la base créé, tout utilisateur peut commencer à travailler dedans. Pour éviter au cours des INSERT qu'un utilisateur supprime un client qui pourrait être utilisé par une facture, SQL Server créé un script avec une gigantesque transaction qui concerne toutes les données de toutes les tables. Par conséquent, toutes les données doivent pouvoir tenir en RAM. Comme je soupçonne que vous avez une RAM plus petite que le volume des données (hors index), alors.... c'est le drame !

Evidemment, ce n'est pas une méthode conseillée.

Faites plutôt la chose suivante :
création des objets de la base en mode mono utilisateur
puis insertion des données via des fichiers BULK en format natif
1) ça ira plus vite
2) vous pourrez régler la taille du batch

A +