✔ [ORACLE] MySQL-Script für ORACLE anpassen

[Sirakov]

Hi Leute,
ich hab kleines Script:

CREATE TABLE `models` (
  `modelID` bigint(20) NOT NULL default '0',
  `modelURI` varchar(255) NOT NULL default '',
  `baseURI` varchar(255) default '',
  PRIMARY KEY  (`modelID`),
  UNIQUE KEY `m_modURI_idx` (`modelURI`)
);
CREATE TABLE `namespaces` (
  `modelID` bigint(20) NOT NULL default '0',
  `namespace` varchar(255) NOT NULL default '',
  `prefix` varchar(255) NOT NULL default '',
  PRIMARY KEY  (`modelID`,`namespace`),
  KEY `n_mod_idx` (`modelID`)
);
CREATE TABLE `statements` (
  `modelID` bigint(20) NOT NULL default '0',
  `subject` varchar(255) NOT NULL default '',
  `predicate` varchar(255) NOT NULL default '',
  `object` text,
  `l_language` varchar(255) default '',
  `l_datatype` varchar(255) default '',
  `subject_is` char(1) NOT NULL default '',
  `object_is` char(1) NOT NULL default '',
  `id` int(10) unsigned NOT NULL auto_increment,
  PRIMARY KEY `s_id_idx` (`id`),
  KEY `s_mod_idx` (`modelID`),
  KEY `s_sub_pred_idx` (`subject`(200)),
  KEY `s_pred_idx` (`predicate`(200)),
  KEY `s_obj_idx` (`object`(250))
);

Die Tabellen will ich aber in ORACLE haben. Gibt es ein Tool, was MySQL nach ORACLE konvertieren kann?

 

[Nico Graichen]

Hi,

Ja gibt es: Notepad, SciTe, usw

Im erst:
Das sind NUR 3 DDL-Statements, die sollte man doch von Hand per Find'n'Replace anpassen können.

 

[Sirakov]

ich weiss, dies mach ich gerade....war aber ein versuch wert. wenn mehr zum konvertieren gibt, dann wird aber schwieriger (für mich)

 

[Nico Graichen]

Es gibt aber Migrations Tools, die sowas übernehmen können (nicht das Umwandeln von Skripten). In Oracle kannst du dir dann das entsprechende DDL-Statement z.B. für eine Tabelle anschauen.

 

[Sirakov]

Ich wollte mit Oracle Migration Workbench dies machen, leider läuft das Tool bei mir aber nicht

~/Desktop/Oracle Migration Workbench/bin$ sh ./omwb.sh
./omwb.sh: 2: Syntax error: Bad fd number

und hier den Inhalt der omwb.sh:

#!/bin/sh
which java > /dev/null 2>&1
if test "$?" -ne "0"
then
    echo java executable not found, Java 1.4 required.
    exit 1
fi
java -version 2>&1 | grep version | grep 1.4 > /dev/null 2>&1
if test "$?" -ne "0"
then
    echo java version 1.4 not found, Java 1.4 required.
    exit 1
fi
java -ms30m -mx256m -jar ../lib/boot.jar oracle.mtg.migrationUI.MigrationApp &

Weiss nicht, woran es liegt...deswegen versuche ich einfach den Script anzupassen. Ich scheitere bei der Zeile

KEY `n_mod_idx` (`modelID`)

Kann mir jmd sagen, wie ich dies für ORACLE anpassen soll...

 

[Thomas Darimont]

Hallo,

also mit dem Squirrel SQL Client kann man ohne Probleme eine Datenbank von einem DBMS auf ein anderes DBMS migrieren. Dazu gehört auch der Migrationsweg von MySQL zu Oracle.

http://squirrel-sql.sourceforge.net/

Gruß Tom

 

[Exceptionfault]

Man sollte bei den ganzen tollen Migrationstools aber trotzdem wissen was man tut und ein bisschen einschätzen können ob das so gut ist was einem die Tools vorschlagen. Ich wette z.B. würde kein Tool der Welt aus der AUTO_INCREMENT Spalte eine passende Sequence generieren, oder die passenden Foreign Keys anlegen...

So würd ichs machen:

CREATE TABLE MODELS (
  modelID       NUMBER(20,0)    CONSTRAINT NN_MODELS_ID  NOT NULL,
  modelURI      VARCHAR2(255)   CONSTRAINT NN_MODELS_URI NOT NULL,
  baseURI       VARCHAR2(255)
);

ALTER TABLE MODELS ADD
    CONSTRAINT PK_MODELS
    PRIMARY KEY( modelID )
    USING INDEX COMPUTE STATISTICS;

CREATE UNIQUE INDEX m_modURI_idx
    ON MODELS( modelURI );
    
CREATE TABLE namespaces (
  modelID       NUMBER(20,0)    CONSTRAINT NN_NS_ID      NOT NULL,
  namespace     VARCHAR2(255)   CONSTRAINT NN_NS_NS      NOT NULL,
  prefix        VARCHAR2(255)   CONSTRAINT NN_NS_PREFIX  NOT NULL
);

ALTER TABLE namespaces ADD
    CONSTRAINT PK_NAMESPACES
    PRIMARY KEY( modelID, namespace )
    USING INDEX COMPUTE STATISTICS;
    
ALTER TABLE namespaces ADD
    CONSTRAINT FK_NAMESPACES_MODID
    FOREIGN KEY ( modelID )
    REFERENCES MODELS ( modelid )
    ON DELETE CASCADE;    

CREATE TABLE statements (
  modelID       NUMBER(20,0)    CONSTRAINT NN_STMTS_MID  NOT NULL,
  subject       VARCHAR2(255)   CONSTRAINT NN_STMTS_SUBJ NOT NULL,
  predicate     VARCHAR2(255)   CONSTRAINT NN_STMTS_PRED NOT NULL,
  object        VARCHAR2(4000),  -- oder besser: CLOB
  l_language    VARCHAR2(255),
  l_datatype    VARCHAR2(255),
  subject_is    VARCHAR2(1)     CONSTRAINT NN_STMTS_SBJI NOT NULL,
  object_is     VARCHAR2(1)     CONSTRAINT NN_STMTS_OBJI NOT NULL,
  id            NUMBER(10,0)    CONSTRAINT NN_STMTS_ID   NOT NULL 
);

ALTER TABLE STATEMENTS ADD
    CONSTRAINT PK_STATEMENTS
    PRIMARY KEY ( id )
    USING INDEX COMPUTE STATISTICS;
    
ALTER TABLE STATEMENTS ADD
    CONSTRAINT FK_STATEMENTS_MODID
    FOREIGN KEY ( modelID )
    REFERENCES MODELS ( modelid )
    ON DELETE CASCADE;
    
CREATE INDEX IDX_STATEMENTS_MID
    ON STATEMENTS ( modelID );
    
CREATE INDEX IDX_STATEMENTS_SUBJ
    ON STATEMENTS ( subject );

CREATE INDEX IDX_STATEMENTS_PRED
    ON STATEMENTS ( predicate );

CREATE INDEX IDX_STATEMENTS_OBJ
    ON STATEMENTS ( object );
        
CREATE SEQUENCE SEQ_STATEMENTS_ID
    START WITH 1
    INCREMENT BY 1
    MINVALUE 1
    MAXVALUE 9999999999
    NOCACHE
    NOCYCLE;

Aus ästhetischen Gründen ( ) würde ich evtl. die Primary Key Spalte der Tabelle STATEMENTS an erster Stelle schreiben, und alle Spalten mit NOT NULL Constraint vor den Spalten ohne...
Für die "OBJECT" Spalte wäre vielleicht der CLOB Datentyp besser, muss man halt ein bisschen anders ansprechen, als ein normales VARCHAR Feld.
Auch noch zu überlegen ist, ob man die VARCHAR2 Felder mit Byte-, oder Charaktersemantik angibt. Default ist normalerweise Bytesemantik, d.h. die Zahl in Klammer gibt nicht die Anzahl Zeichen an, sondern die Anzahl Byte pro Spalte. Dies ist besonders bei Sonderzeichen interessant, da ein "ä" oder "ß" dann 2 Byte belegt.
Entweder man schreibt dann "VARCHAR2( xxx CHAR)" oder man führt vor dem Anlegen der Tabellen folgendes aus:

alter session set nls_length_semantics = CHAR;