bonjour,
 
je dois dans un executable dupliquer une table sql d'une base a une autre
quel est le meilleur moyen
 
je pensais a une procedure PL/SQL (je suis en oracle) qui parcour tout les enregistrements de la table a copier (avec un databaseLink)
dans un curseur
puis de tout inserer dans la table de reception
 
merci  

je comprends pas
pourquoi faire ca en PL/SQL?
une simple creation de table a partir du select de la table source ne te convient pas?

create table matable as select * from MaTableaCopie@dblink;
 
 
comme ca? oui kler je voyais le trop d'une maniere trop complexe

non en faite les tables seront deja crée, ca va peu etr pas marcher le create table (pour les jointures etc...)
 
je vais peu etre faire ca alors:
INSERT INTO MaTableCopie (var1, var2, ....) SELECT var1, var2, .... FROM MaTable;

INSERT INTO MaTableCopie SELECT * FROM MaTable devrait suffire non

kler merci pour ton aide.  
 

seul souci du create as select, c'est que si la table est trop grosse tu risque un rollback segment. mais sinon, c'est la meilleur solution.
 
autre solution, qui ne risque rien, et bien plus rapide : génération d'un fichier plat au format SQL Loader, puis un coup de SQL Loader et là tu pleures en voyant ta table de 100 000 000 être recopiée en 5 secondes

5 secondes pour 100 millions de lignes, faut pas exagérer
 
D'ailleurs, je me demande ce qui serait le plus rapide entre passer par SQL Loader ou du PL/SQL avec COMMITs régulier, pour copier une grosse table ... à tester.

SQL Loader sans la moindre hésitation.
 
Au départ, j'avais des doutes.
Quand on est passé de 1 heure à moins de 5 minutes pour la réplication des données nécessaires au site web d'un client, le résultat fut assez flagrant pour écarter toute hipothèse d'un problème d'optimisation des lots SQL.  Et pourtant, des données y'en a une tétrachiée. Certes, au départ, les données étaient mises à jour via OLEDB, avec un commit toutes les 10 000 lignes. Mais l'écart de perfs entre un script SQL et une éxécution OLEDB d'un lot de requête ne justifie pas une telle différence (au pire, 2 ou 3 fois plus lent, jamais de la vie plus de 10 )
 
En tout et pour tout, dans l'ordre décroissant de rapidité, on avait :
- Les select qui génèrent les fichiers
- Les transferts FTP (liaison 1Gbps)
- SQL Loader
 
Bon, sur un gros serveur HP sous Solaris, utilisant un SAN. Avec un serveur x86, les perfs seront certainement moindre à cause du goulot d'étranglement du PCI.
 
En fait, avec un SQL Loader, on ne fait que recopier brut de fonderie les données d'un fichier plat (rien de plus rapide à lire) dans les tablespace. Seul un contrôle du type est effectué, les tests d'unicité et d'intégrité n'étant faits qu'à la fin du chargement. Un peu l'équivalent de l'insertion par lot, mais en zappant complètement le moteur SQL. En bref, si ton RAID 50 est capable de bouffer 500 Mo/s (ce qu'on peut obtenir avec une vingtaine de disques réparti sur une chaîne RAID 50), alors les données seront intégrées à cette vitesse (c'est pas les tests de types qui vont réussir à ralentir les CPU actuels). Avec des insertions, même avec des commits bien gérés, à chaque insertion on va générée une chiée d'écriture et de lectures (vérification de la cohérence et des FK, lock des index, insertion des données, mise à jour des index, puis la série d'écritures générées par un COMMIT - lock de a table et des index, recopie des données temporaires dans les fichiers de données, puis unlock des index et tables -). Avec un SQL Loader, la table est de toute façon lockée pendant tout le traîtement, c'est pas rollbackable, et les index ne sont checkés/mis à jour qu'une une seule fois à la fin.
 
C'est un peu même chose qu'entre un "DELETE maTable" et un "TRUNCATE maTable" : le jour et la nuit

Mais pas le meme niveau de securité.

?
 
Ben si, car SQL Loader marche comme suit :
- LOCK de la table.
- Insertion des données dans le table space
- Mise à jour des index et contrôles des FK
- Connection des données inserrées à la table elle-même.
- UNLOCK de la table.
 
Donc si la régénération des index plante, alors les données ne sont jamais liées à la table, et donc c'est comme si on n'avais rien fait.
 
En fait, clairement, mise à part si on a des triggers, y'a aucune différence de comportement par rapport à des INSERT, mise à part que c'est incomparablement plus rapide.

non je parle du DELETE et du TRUNCATE. L'un log et l'autre non.

ah ok
 
me SQL Loader non plus ne log pas d'ailleurs. Le seul truc, comme le TRUNCATE, c'est qu'en cas de plantage pour données incohérentes, le contenu de la table n'est pas altéré