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
Version imprimable
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
Bonjour,
Non car dans la majorité des cas voir tous les cas une réécriture de code s'impose entre les 2 moteurs.
++
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 :
qui à priori est disponible sous Oracle et qui permet de copier la structure + données + Index + Clé etc.Code:CREATE TABLE TABLE2 AS SELECT * FROM TABLE1;
Sur SQL-Server nous pouvons utiliser
qui à priori est disponible sous SQL-Server et qui permet de copier structure + données mais pas les clés + IndexCode:SELECT * INTO NouvelleTable FROM TableACopier
> Comment faire pour récupérer les Clés + Index.
Cordialement,
BIMAN
100 millions d'enregistrements ne poseront de problème à aucun des deux SGBD.Citation:
Envoyé par BIMAN
Ne copie que la table et les données.Citation:
Envoyé par BIMAN
Rien au niveau des index, clefs, déclencheurs et privilèges.
C'est donc très semblable au SELECT * INTO que vous évoquez.
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.Citation:
- 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 ?
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.Citation:
les fonctionnalités de Oracle sont plus poussées que sur Sql Server. Quelques fonctionnalités nous interesse comme :
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.
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 ?Citation:
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.
++
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
Clic droit sur la table > Générer un script de la table en tant que > CREATE TO.
Modifiez le nom des objets.
Code:
2
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 ;)
@++ ;)
La plupart des ETL/ELT disponibles sur le marche permettent de travailler avec des sources heterogenes et peuvent donc ici vous aider a resoudre votre probleme de transfert de donnees d'un environnement a un autre.
BTW, si Oracle est le SGBD impose comme vous le dites, faut il encore a ce moment la se poser les questions de differences de fonctionnalites entre les 2 SGBD ? Je presume que cette analyse a deja ete faite en amount.
Merci à vous pour vos réponses claires.
La solution ETL est envisagée (et a été étudiée) avec comme gros avantage de solutionner le passage Sql server vers Oracle.
Nous cherchons à proposer un autre scénario
- Faire un DUMP des bases Sql server tous les soirs vers une autre base SQL Server. Nous souhaitons également créer sur cette base de sauvegarde quelques tables pécifiques (alimentées elles aussi tous les soirs).
- Ces tables pécifiques seraient créées par un script sql (exécuté une fois) et alimentées tous les soirs par un autre script sql.Ce script sql d'alimentation réunierait dans un fichier tous les INSERT des différentes tables.
Question : comment constituer ce fichier d'alimentation des tables ? (un fichier peut il contenir l'ensemble des INSERT à faire ?), quel type de fichier doit il être créé ? (Certainement un fichier ".sql" ?) Et comment faire pour que Sql Server le lise et l'exécute tous les soirs à une heure précise ?
Je ne comprends plus, vous êtes bien contraint de migrer en ORACLE non?Citation:
- Faire un DUMP des bases Sql server tous les soirs vers une autre base SQL Server. Nous souhaitons également créer sur cette base de sauvegarde quelques tables pécifiques (alimentées elles aussi tous les soirs).
- Ces tables pécifiques seraient créées par un script sql (exécuté une fois) et alimentées tous les soirs par un autre script sql.Ce script sql d'alimentation réunierait dans un fichier tous les INSERT des différentes tables.
Question : comment constituer ce fichier d'alimentation des tables ? (un fichier peut il contenir l'ensemble des INSERT à faire ?), quel type de fichier doit il être créé ? (Certainement un fichier ".sql" ?) Et comment faire pour que Sql Server le lise et l'exécute tous les soirs à une heure précise ?
Tache planifiée, tache de maintenance de l'Agent SQL...Citation:
Et comment faire pour que Sql Server le lise et l'exécute tous les soirs à une heure précise
Si nous voulons rester dans un certain cadre avec une certaine organisation, nous sommes obligé de choisir Oracle comme SGBD pour la copie de base.
Par contre nous pouvons toujours proposer (ça ne coute rien) d'autres alternatives comme de d'utiliser Sql Server.
Question :
L'agent Sql Server est il présent en version Standard (2008) ou faut il avoir la version entreprise de Sql server ?
Ce fichier sql (contenant les INSERT) peut il être stocké dans un répertoire quelconque sur le réseau ?
Oui il est présent de baseCitation:
L'agent Sql Server est il présent en version Standard (2008) ou faut il avoir la version entreprise de Sql server ?
Citation:
Envoyé par BIMAN
Dans ce cas, optez pour l'option de faire des dumps de data en utilisant BCP et de les charger de la meme maniere.
Cela vous permet d'avoir des fichiers de data sans devoir surcharges ceux-ci avec d'autres informations.
De plus, ces RAW data peuvent etre utilise par differents systemes.
Quel est le but de cette copie de base ?
++
Citation:
Envoyé par mikedavem
Copie de base pour sauvegarde + alléger la base de production utilisée pour faire des reports.
J'ai une dernière question:
Dans le scénario d'une copie de base SQL Server vers Oracle , nous pouvons effecrtivement passer par des fichiers plats.
Est ce que d'après vous cette solution est viable ? pouvons nous avoir des fichiers plats de plus de 2/3 millions d'enregistrements ? Quel est le délai d'intégration de tel fichier sous Oracle ?
Les fichiers plats en tant que moyen d'échange entre deux sociétés, ça fonctionne bien et ça permet une grande traçabilité, maintenant en interne vous allez construire des étapes supplémentaires pour pas grand'chose.
Liez vos deux serveurs Oracle et Microsoft par un linked server ou un DBLink, et faites transiter vos données par ce biais.
Citation:
Envoyé par Waldar
C'est un fonctionnement intéressant.
Dans le cas de figure (base Sql server vers Oracle), je suppose que le "DbLink" est créé depuis Oracle vers Sql Server. Par contre est ce qu'un Db Link est fiable ? pouvons nous l'utiliser avec n'importe quel version de SGBD ? (
Exemple en source : 1 base Oracle (versionxxxx) récupére certaines tables d'1 base Sql server 2005 et 1 base Sql server 2008 ? une supervision est elle nécessaire ?
Dans ce cas si vous restez sur une solution Full SQL Server vous pouvez tout à fait adopter des solutions de type log shipping ou mirroring asysnchrone qui vous permettent d'avoir une copie de vos données sur un autre serveur + possibilités de reporting sur ce même serveur afin d'alléger la charge sur votre productionCitation:
Copie de base pour sauvegarde + alléger la base de production utilisée pour faire des reports.
++
Si on opte pour une solution Full Sql Server : je pense que nous avons assez d'éléments pour faire quelque chose de bien.Citation:
Envoyé par mikedavem
Si on opte pour des solution avec SGBD hétérogènes et plus précisement pour l'emploi d'un ETL (informatica, talend etc.), ma question est la suivante :
Imaginons qu'une table récupérée et envoyée vers un autre SGBD grâce à un ETL évolue (ajouts de nouvelles colonnes).
l'ETL peut il (tout seul) détectée que la structure a évolué et envoyer les nouvelles colonnes automatiquement ?
Pour l'avoir fait avec SSIS entre un AS400 et SQL Server je peux dire que c'est possible mais il faut le prévoir dans la conception du processus d'import des données car ce n'est pas automatique.
++