Discussion :

[BIMAN]

Bonjour,

Est il possible de faire un DUMP de plusieurs bases SQL SERVER (2005 & 2008) vers des bases Oracle ? (sans que ça pose problème).

Cordialement,
BIMAN

[mikedavem]

Bonjour,

Non car dans la majorité des cas voir tous les cas une réécriture de code s'impose entre les 2 moteurs.

++

[BIMAN]

Merci Mikedavem pour votre réponse rapide.

Donc j'ai un serieux problème : les applications sont sous SQL-Server et nous souhaitons faire un DUMP vers les bases Oracle (SGBD imposé).

D'ou mon interrogation de sortir de ces principes en décidant de faire un DUMP de SQL-Server vers une autre base SQL-Server.


Par contre, On me dit que :

- Oracle est plus solide que SQL-Server : nous sommes sur des bases de quelques 20 millions d'enregistrements par an (purge touts les 5 ans) donc bases de 100 millions d'enregistrement (avant purge) - Est ce que SQL-Server supporte (sans problèmes) ces volumes ?

- les fonctionnalités de Oracle sont plus poussées que sur SQL-Server. Quelques fonctionnalités nous interesse comme :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE TABLE2 AS SELECT * FROM TABLE1;

qui à priori est disponible sous Oracle et qui permet de copier la structure + données + Index + Clé etc.

Sur SQL-Server nous pouvons utiliser

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT *  INTO NouvelleTable FROM TableACopier

qui à priori est disponible sous SQL-Server et qui permet de copier structure + données mais pas les clés + Index
> Comment faire pour récupérer les Clés + Index.

Cordialement,
BIMAN

[Waldar]

- Oracle est plus solide que Sql Server : nous sommes sur des bases de quelques 20 millions d'enregistrements par an (purge touts les 5 ans) donc bases de 100 millions d'enregistrement (avant purge) - Est ce que Sql Server supporte (sans problèmes) ces volumes ?

100 millions d'enregistrements ne poseront de problème à aucun des deux SGBD.

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE TABLE TABLE2 AS SELECT * FROM TABLE1;

Ne copie que la table et les données.
Rien au niveau des index, clefs, déclencheurs et privilèges.
C'est donc très semblable au SELECT * INTO que vous évoquez.

[BIMAN]

Ok. Merci WALDAR.

J'ai une dernière question mais je ne sais pas si c'est possible

Sur Sql Server comment puis je copier une table vers une autre avec toutes les caractéristiques (Structure + Données + Clés + Index + Droits ) de cette table sans spécifier unitairement les champs à sélectionner et ceux constituant la clé.

(en faisant un CREATE NewTABLE SELECT * WHERE y = 1 FROM TABLE_SOURCE)

Cordialement,
BIMAN

[Waldar]

Clic droit sur la table > Générer un script de la table en tant que > CREATE TO.
Modifiez le nom des objets.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
INSERT INTO Table2
SELECT * FROM Table

[elsuket]

Bonjour,

Pour générer le script d'une table sans ses données, voici une procédure que j'ai publié ici.

Vous pouvez aussi générer le script d'une liste (ou toutes) les tables de votre base de données, avec leurs contraintes, triggers et indexes à l'aide du générateurs de script de SQL Server Management Studio, comme je l'ai montré ici.

Le problème bien sûr, c'est qu'il vous faudra repasser ensuite pour modifier les instructions.

Une autre solution peut être de générer un fichier plat de la ou les tables à migrer puis de l'intégrer avec un utilitaire d'Oracle.

Enfin comme Mikedavem, j'administre pour un client une base de données de plus de 3TB qui supporte une charge uniquement OLTP (entre 3000 et 5000 utilisateurs aux heures de pointe), hébergée sur un serveur que je trouve pour le moins ridicule en termes de configuration hardware.

La plus grosse table contient presque 500 millions de ligne, pour 133GB de donnés. Comme on est dans le domaine hospitalier, on garde toute les données.
Le client a pas l'air de vraiment se plaindre

@++

[mikedavem]

- Oracle est plus solide que Sql Server : nous sommes sur des bases de quelques 20 millions d'enregistrements par an (purge touts les 5 ans) donc bases de 100 millions d'enregistrement (avant purge) - Est ce que Sql Server supporte (sans problèmes) ces volumes ?

Bon le but ici n'est pas de faire un débat supplémentaire entre oracle et SQL Server mais la différence qu'il existait avant entre Oracle et SQL Server n'est plus vraiment valable maintenant. Ici vous parlez de volume en lignes de données mais il faudrait avoir le volume en Go voir To de vos données. Sachez que SQL Server peut travailler avec des volumétries de l'ordre du Téra sans problème. J'ai moi même administré une base faisant environ 2 To.

les fonctionnalités de Oracle sont plus poussées que sur Sql Server. Quelques fonctionnalités nous interesse comme :

Une des mes connaissances proches (qui se reconnaitra) m'a fourni dernièrement un comparatif effectué par le groupe Crimson Consulting qui compare la dernière version de SQL Server avec les autres SGBD du marché et cela confirme bien qu'en terme de fonctionnalités SQL Server n'a plus rien à envier à ses concurrents.

CREATE TABLE TABLE2 AS SELECT * FROM TABLE1 ;
qui à priori est disponible sous Oracle et qui permet de copier la structure + données + Index + Clé etc.

Sur Sql server nous pouvons utiliser
SELECT * INTO NouvelleTable FROM TableACopier
qui à priori est disponible Sous Sql server et qui permet de copier structure + données mais pas les clés + Index
> Comment faire pour récupérer les Clés + Index.

Effectivement mais avec SQL Server vous pouvez tout à fait générer le script du schéma des objets de vos bases + utiliser les outils livrés avec SQL Server pour la partie données qui me semblent qd même plus propre. Pourquoi je dis cela ? Dans votre script oracle (je vous crois sur parole je ne connais pas Oracle) vous récupérez effectivement l'ensemble des éléments de votre schéma mais que se passe t'il si vous avez à faire à une clé étrangère qui référence une table qui n'existe pas ?

++