Insert From Select espace disque tempdb

Bonjour à tous,

Je dois créer une copie d'une table à partir d'une requète. La table est assez volumineuse. Je suis parti sur une requête de type :

insert into newTable SELECT from oldTable

Mais au bout de 28h de script sqlServer me dit que je n'ai pas suffisament d'espace disque sur primary. J'aurai aimé ne pas perdre 28h de mon temps lol.

Est ce qu'il y a un moyen de savoir avant de lancer le script si celle-ci est réalisable sachant que je n'ai pas accès au serveur BDD ? Quel est l'impact d'une telle requete sur tempdb et le journal de transaction ?

Est ce qu'une requête de type SELECT INTO newTable from oldTable peut ameliorer les choses ?

Dans tous les cas le résultat sera le même.... La copie d'une table dans une autre est une transaction d'insertion. il faut donc pouvoir disposer d'un peu plus de 2 fois les données d'origine :

• Une première fois pour alimenter le journal de transaction
• une seconde fois pour alimenter la table finale.

Vous pouvez avoir une idée de la volumétrie de la table de départ en utilisant la procédure stockée système sp_spacused.

Si vous voulez être plus rapide, il existe des réglages particulier a entreprendre... mais dans plus de détail (par exemple la description de la structure de la table et la description du stockage des bases, il est difficile de vous répondre

A +

Une solution alternative, c'est de passer par une série de transactions en recopiant qu'une partie des données à chaque fois.
=> Si vous êtes en mode recovery simple (et non full, attention !) ça permettra d'utiliser moins de place
=> Attention aussi si des transactions concurrentes peuvent modifier la table durant la copie... car du coup avec cette méthode on risque de copier des données inconsistantes... ou alors il faut locker explicitement toute la table durant toute la transaction !

Citation:

---

Envoyé par StringBuilder

...
=> Attention aussi si des transactions concurrentes peuvent modifier la table durant la copie... car du coup avec cette méthode on risque de copier des données inconsistantes... ou alors il faut locker explicitement toute la table durant toute la transaction !

---

Ce qui dans ce cas ne résous pas le problème car la transaction portera sur l'intégralité de la copie depuis le début....

A +