[9i] Migration Mysql

Bonjour,

Je m'y connais un peu en administration mysql mais Oracle j'avoue que j'y comprends pas grand chose alors si quelqu'un peut m'aider voila mon problème:

j'ai un logiciel qui tourne actuellement sur mysql 4.1 avec plein de bases de données différentes mais qui contiennent toutes les mêmes noms de tables (en fait chaque base est la base d'un site client et il y a un seul serveur mysql central qui gère plusieurs sites).
je souhaite migrer ce logiciel sous Oracle 9i , au niveau traduction SQL ca peut aller mais au niveau architecture je m'y perds entre les instances, les bases, les tablespaces, les datafiles etc... 8O

Quelle est la manière la plus efficace en terme de performances sous oracle pour garder l'architecture un serveur unique - plusieurs bases ?
Et si je veux limiter la consommation mémoire sur le serveur oracle avec plusieurs bases comment faire ?

Autre question sur Oracle a-t-on besoin de scripts de réplication ou il existe un mécanisme automatique via un fichier de config ou autre comme sous mysql ?

Merci pour toute aide car je suis un peu paumé ! :?

Bonjour ,
cous pouvez créez votre base avec emca ( graphique ) et faire votre migration via Oracle workbench

En fait ce que j'aimerai savoir c'est comment créer plusieurs bases avec oracle qui contiennent les mêmes noms de tables, faut-il obligatoirement plusieurs instances (gourmand en mémoire) ou cela peut-il être fait différemment pour éonomiser des ressources quitte à perdre un peu en performance ?

Personnellement et de visu, j'utiliserais une seul base de donnée mais plusieurs shema différents pour acceuillir les tables.

Se serai le moins gourmand en mémoir et en performance mais les manipulation de données risque d'être difficile.

merci yves un debut de piste ...

et un schéma c'est quoi au juste ? (c'est l'equivalent d'une base au sens mysql mais attachée à un user donné ?)
comment on s'en sert en pratique (schema1.table1 et schema2.table1 ) ?

bon je pense que je m'oriente vers un schema/tablespace/datafile par base mysql dans une instance unique oracle ...


une autre question : comment marche la réplication simple (un maitre , un esclave ) sous oracle 9i ? :?:
je n'ai trouvé que des infos sur les multi maitres avec resolution de conflits mais c'est trop compliqué pour moi tout ça ! :(

On peux voir un schema comme un conteneur d'objects (tables, indexes etc), ceci materialize par la creation d'un utilisateur. La commande CREATE USER corresponds a la creation de ce schema.

Concernant la replication, google A96567-01 pour Oracle9i, A67791-01 pour Oracle8i.

En exemple simple d'utilisation:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

DROP MATERIALIZED VIEW dept_snp / DROP TABLE dept / CREATE TABLE dept (id INTEGER ,n INTEGER) / ALTER TABLE dept ADD (CONSTRAINT dept_pk PRIMARY KEY (id) ) /   INSERT INTO dept VALUES (1,10) / CREATE MATERIALIZED VIEW dept_snp AS SELECT * FROM dept / SELECT * FROM dept_snp /

---

Apres une longue absence, me revoila pour toujours une migration mysql 4.1 vers oracle 9i.

De nouvelle difficultés sont venues s'ajouter :

Sous mysql j'ai maintenant une base globale (avec des données communes) et N bases annexes toutes identiques (mêmes noms de tables mais pas le même contenu).
Maintenant un utilisateur doit toujours avoir accès à la base globale et à une ou plusieurs bases annexes.

Comment faire en sorte sous oracle 9i qu'avec une seule connexion l'utilisateur ait accès à la base globale et à une ou plusieurs bases annexes ?
La création de synonymes me permet-elle de résoudre ce problème ?

Si quelqu'un peut m'orienter un peu ou mieux me donner un exemple de script assez complet (multi bases , gestion des roles et droits utilisateurs ...), ça m'enleverai une grosse epine du pied ... ;)

J'ai oublié un petit détail :

comment peut on traduire la syntaxe mysql du 'IF' (intégré à un select par exemple) ou 'IFNULL' en oracle ?

Merci

Nvl :)

IF = CASE WHEN .... THEN .... WHEN ... THEN... ELSE .... END

IFFNULL = NVL

Par contre, étant donné qu'il n'y a pas cette notion de multi-base dans oracle (oracle a 1 étage de moins....) , il va faloir que tu transforme chacune de tes anciennes bases en schéma oracle (ou user), puis tu pourra jouer en donnant des droits d'un schéma vers d'autres.

Petit bémol, si tu as dans une de tes base mysql plusieur fois le meme nom de table sous un user différent... tu es mal.... :?

Et si l'application n'a besoin que de travailler sur un seul schéma Oracle (=base MySQL) à la fois, on devrait pouvoir remplacer (sans avoir à modifier le code SQL pour préfixer les tables Oracle par le nom du schéma):

Code:

---

1 2	use <database MySQL>

---

par

Code:

---

1 2	ALTER SESSION SET CURRENT_SCHEMA=<schéma Oracle>

---

Si l'application a besoin de travailler sur plusieurs schémas à la fois dans la même requête, il faut replacer le nom de la base MySQL par le nom du schéma Oracle.

L'utilisation des synonymmes publiques semble difficile à mettre en oeuvre à moins de privilégier le schéma concerné par rapport à tous les autres ?

S'il y a des procédures stockées, il faut probablement utiliser la clause AUTHID CURRENT_USER sinon la procédure stockée Oracle référence en dur le schéma du propriétaire de la procédure pour les objets qui ne sont pas préfixés par le nom du schéma...

merci pour nvl et le reste :D

pour les bases effectivement j'ai les memes noms de tables dans toutes les bases sauf une ...

et j'avais deja commencé à creer un schéma par base mysql.

les problemes de collisions peuvent etre resolu en mettant chaque schema dans un tablespace different je crois ?

apres le problème c'est comment bien definir les droits, roles et synonymes pour que :

- tous les users ait accès aux tables du schema partagé
- chaque user doit en plus avoir accès à ses propres tables (dans son schéma) et à certains autres schemas qui ont les memes noms de tables 8O


[
Comme en plus un tas de requetes ont deja été ecrites sans prefixer les tables avec un nom de base (ou de schema ici) , ya-t-il un equivalent du 'USE basename' de mysql pour faire commuter d'un schema à un autre entre 2 requetes sans ouvrir plusieurs connections simultanées ?

8O ] déjà répondu avant que je finisse de taper , transmission de pensée !! 8-)

Citation:

---

les problemes de collisions peuvent etre resolu en mettant chaque schema dans un tablespace different je crois ?

---

Non. En général, les problèmes de collisions de noms sont résolus en préfixant le nom de l'objet (<objet>) par le nom du schéma (<schéma>) auquel il appartient de la façon suivante:

Code:

---

<schéma>.<objet>

---

Ceci est indépendant de la localisation physique dans un tablespace donné de l'objet en question.

Citation:

---

apres le problème c'est comment bien definir les droits, roles et synonymes pour que :

---

Je doute que les synonymes vous aident beacoup dans votre cas car d'après les règles de résolution suivantes, le synonyme n'est utilisé que s'il n'y a pas une table de même nom dans le schéma courant (dans http://download-uk.oracle.com/docs/c...0/adg03sch.htm)

Citation:

---

Rules for Name Resolution in SQL Statements
An object name takes the following form:

[schema.]name[@database]


Some examples include:

Emp_tab
Scott.Emp_tab
Scott.Emp_tab@Personnel


A session is established when a user logs onto a database. Object names are resolved relative to the current user session. The username of the current user is the default schema. The database to which the user has directly logged-on is the default database.

Oracle has separate namespaces for different classes of objects. All objects in the same namespace must have distinct names, but two objects in different namespaces can have the same name. Tables, views, snapshots, sequences, synonyms, procedures, functions, and packages are in a single namespace. Triggers, indexes, and clusters each have their own individual namespace. For example, there can be a table, trigger, and index all named SCOTT.EMP_TAB.

Based on the context of an object name, Oracle searches the appropriate namespace when resolving the name to an object. For example, in the following statement:

DROP CLUSTER Test


Oracle looks up TEST in the cluster namespace.

Rather than supplying an object name directly, you can also refer to an object using a synonym. A private synonym name has the same syntax as an ordinary object name. A public synonym is implicitly in the PUBLIC schema, but users cannot explicitly qualify a synonym with the schema PUBLIC.

Synonyms can only be used to reference objects in the same namespace as tables. Due to the possibility of synonyms, the following rules are used to resolve a name in a context that requires an object in the table namespace:

Look up the name in the table namespace.
1.If the name resolves to an object that is not a synonym, then no further work is necessary.
2. If the name resolves to a private synonym, then replace the name with the definition of the synonym and return to step 1.
3. If the name was originally qualified with a schema, then return an error; otherwise, check if the name is a public synonym.
4. If the name is not a public synonym, return an error; otherwise, then replace the name with the definition of the public synonym and return to step 1.

---

Pour la gestion des droits et des rôles, voir aussi http://oracle.developpez.com/guide/a...ion/adminrole/

Au fait, il existe un outils de migration:

http://download-uk.oracle.com/docs/c...a97249/toc.htm

Mais attention il faut regarder la doc à titre indicatif, je l'ai fait pour sybase (qui ressemble beaucoup à mysql dans sont architecture) et j'ai constaté qu'il y avait pas mal de bugs et de choix douteux dans cet outil. En particulier il fait une correspondance TABLESPACE <-> BASE qui est une vision physique des choses mais qui est trés mauvaise en pratique, le mieux est bien sur la correspondance SCHEMA <-> BASE.

Cependant la doc est interressante.

Bonjour voici un exemple

Bases MySQL :
- BR = Base référence : tout le monde doit y accéder = schema BR
- B1 = Base client n°1 : seul le client 1 doit y accéder + BR = schema B1
- B2 = Base client n°2 : seul le client 1 doit y accéder + BR = schema B2

1°)Création des tablespaces / TBS
(exemple à ne pas faire : 1 tbs par base :aie: c'est juste pour monter les droits sur les TBS)

- TB_BR = Tablespace de la Base référence
- TB_B1 = Tablespace de la Base client n°1
- TB_B2 = Tablespace de la Base client n°2

2°) création des users (schémas)
--base BR

Code:

---

1 2 3 4 5 6

CREATE USER BR IDENTIFIED BY BR DEFAULT TABLESPACE TB_BR TEMPORARY TABLESPACE TEMPO ACCOUNT UNLOCK; GRANT CONNECT TO BR; GRANT RESOURCE TO BR;

---

--Base B1

Code:

---

1 2 3 4 5 6 7

CREATE USER B1 IDENTIFIED BY B1 DEFAULT TABLESPACE TB_B1 TEMPORARY TABLESPACE TEMPO ACCOUNT UNLOCK; GRANT CONNECT TO B1; GRANT RESOURCE TO B1;

---

--Base B2

Code:

---

1 2 3 4 5 6 7

CREATE USER B2 IDENTIFIED BY B2 DEFAULT TABLESPACE TB_B2 TEMPORARY TABLESPACE TEMPO ACCOUNT UNLOCK; GRANT CONNECT TO B2; GRANT RESOURCE TO B2;

---

3°) Affectation des privilèges au TBS
Afin que seul les utilisateurs écrivent dans leur TBS et celui de BR.
Comme cela B1 ne peut pas écrire des donnée dans la base B2

--BR peut écrire sur la base BR seulement'

Code:

---

1 2	REVOKE UNLIMITED TABLESPACE FROM BR; ALTER USER BR QUOTA UNLIMITED ON TB_BR;

---

--B1 peut écrire sur la base BR et B1'

Code:

---

1 2 3

REVOKE UNLIMITED TABLESPACE FROM B1; ALTER USER B1 QUOTA UNLIMITED ON TB_BR; ALTER USER B1 QUOTA UNLIMITED ON TB_B1;

---

--B2 peut écrire sur la base BR et B2'

Code:

---

1 2 3

REVOKE UNLIMITED TABLESPACE FROM B2; ALTER USER B2 QUOTA UNLIMITED ON TB_BR; ALTER USER B2 QUOTA UNLIMITED ON TB_B2;

---

4-a°) création d'une table dans BR qui doit être visible par tous :
--connecté BR

Code:

---

1 2 3 4 5 6 7 8 9 10 11

CREATE TABLE TABLE_BR (champs 1 number(1)) ect.. TABLESPACE TB_BR; --syn. public CREATE PUBLIC SYNONYM TABLE_BR FOR BR.TABLE_BR --droit décès à B1 et B2' GRANT SELECT, UPDATE, DELETE, INSERT ON BR.TABLE_BR TO B1; GRANT SELECT, UPDATE, DELETE, INSERT ON BR.TABLE_BR TO B2; Tu peux aussi si tu es sur que tous tes users doient y acceder GRANT SELECT, UPDATE, DELETE, INSERT, INDEX,ALTER ON BR.TABLE_BR TO PUBLIC;

---

4-b°) création d'une table dans B1 qui doit être visible que par B1 :
--connecté B1

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE TABLE_B1 (champs 1 number(1)) ect.. TABLESPACE TB_B1; --syn. public CREATE PUBLIC B1.TABLE_B1 FOR B1.TABLE_B1 --droit décès à B1 seulement (il les a déjà car c'est le propriétaire, juste pour rappel)' GRANT SELECT, UPDATE, DELETE, INSERT, INDEX,ALTER ON B1.TABLE_B1 TO B1;

---

4-c°) création d'une table dans B2 qui doit être visible que par B2 :
--connecté B2

Code:

---

1 2 3 4 5 6 7

CREATE TABLE TABLE_B2 (champs 1 number(1)) ect.. TABLESPACE TB_B2; --syn. public CREATE PUBLIC B2.TABLE_B2 FOR B2.TABLE_B2 --droit décès à B2 seulement (il les a déjà car c'est le propriétaire, juste pour rappel)' GRANT SELECT, UPDATE, DELETE, INSERT, INDEX,ALTER ON B2.TABLE_B2 TO B2;

---

5°) utilisation des tables
--Connecté avec BR
sur TABLE_BR tu pourras faire ce que tu veux
sur TABLE_B1,TABLE_B2 tu auras l'erreur

Code:

---

1 2 3 4 5

SELECT * FROM TABLE_B1 * ERREUR à la ligne 1 : ORA-00942: Table ou vue inexistante

---

--Connecté avec B1
TABLE_BR tu pourras faire ce que tu veux (select, update, delete, insert)
sur TABLE_B1 tout,
sur TABLE_B2 tu auras l'erreur

Code:

---

1 2 3 4

SELECT * FROM TABLE_B2 * ERREUR à la ligne 1 : ORA-00942: Table ou vue inexistante

---

--Connecté avec B2
TABLE_BR tu pourras faire ce que tu veux (select, update, delete, insert)
sur TABLE_B1 tu auras l'erreur

Code:

---

1 2 3 4 5

SELECT * FROM TABLE_B2 * ERREUR à la ligne 1 : ORA-00942: Table ou vue inexistante sur TABLE_B2 tu auras l'erreur

---

Tout ceci est un exemple d'utilisation des droits TBS, synonymes privés/public ect...

J'ai pris des noms de tables différents pour B1 et B2 pour bien comprendre mais si tu prends le même nom de table, syn. etc.. cela fonctionne, tu pourras même créer un script identique pour chacune de tes tables il sera juste à exécuter sur chauqe user exemple :
--connecté B1 ou B2

Code:

---

1 2 3 4 5 6 7 8

CREATE TABLE TABLE_B (champs 1 number(1)) etc ... TABLESPACE TB_&schema; --syn. public CREATE PUBLIC &schema.TABLE_B FOR &schema.TABLE_B --droit décès, bon il les a toujours' GRANT SELECT, UPDATE, DELETE, INSERT, INDEX,ALTER ON &schema.TABLE_B TO &schema;

---

En espérant que cela va d'aider. WorkBench fait les migrations de données MySQL vers ORACLE.
Ensuite une fois tous tes objects dans tes schémas tu auras "juste" à faire des droits d'accès et les syns.

Nous avons fait tout ceci pour une appli. multi pays en 9i et cela fonctionne tres bien. Il faut juste être très soigné sur les droit/syn. et depuis quel utilisateur tu dois te connecter pour intégroger la base.

Mais pas de problème d'écriture dans autre schéma avec les unlimited TBS

Bon courage :D

Un grand merci à tous pour vos réponses ! :D

Avec tout ça je pense que je vais m'en sortir, juste quelques heures de prise de tête en perspective ;)

Je suis content de voir un forum francophone ou les gens sont prêts à aider les novices dans un domaine, en général l'accueil et plutot "froid" 8-)


A bientot sans doute car je risque d'avoir d'autres problème en cours de migration ;)