Date(mysql) - date(oracle 8i), java.lang.OutOfMemory

Question

PLATFORM AND O/S VERSION: RedHat Linux 7.2, Kernel 2.4.9-21smp, Oracle 8.1.7.4
MIGRATION WORKBENCH VERSION: 9.2.0.1.2 (Windows 2000, ServicePack 2)
THIRD-PARTY DATABASE AND VERSION BEING MIGRATED: MySQL 3.23.41
Hi there,
I urgently need to migrate a mysql (3.23.41) database (7.1 GB) into Oracle 8i (8-1-7-4),
but faced a lot of problems during migration.(capturing went well):
1. ORA-01843: not a valid month
2. java.lang.OutOfMemoryError
For error no. 1:
Here comes a description of a suspicious source table(mysql), which has a 'datetime' (column: 'created')
in it:
mysql> desc analysisprocess;
-----------------------------------------------------------------------------------+
| Field | Type | Null | Key | Default | Extra |
-----------------------------------------------------------------------------------+
| analysisId | int(10) unsigned | | PRI | NULL | auto_increment |
| created | datetime | | | 0000-00-00 00:00:00 | |
| logic_name | varchar(40) | | | | |
| db | varchar(120) | YES | MUL | NULL | |
| db_version | varchar(40) | YES | | NULL | |
| db_file | varchar(120) | YES | | NULL | |
| program | varchar(80) | YES | | NULL | |
| program_version | varchar(40) | YES | | NULL | |
| program_file | varchar(80) | YES | | NULL | |
| parameters | varchar(80) | YES | | NULL | |
| module | varchar(80) | YES | | NULL | |
| module_version | varchar(40) | YES | | NULL | |
| gff_source | varchar(40) | YES | MUL | NULL | |
| gff_feature | varchar(40) | YES | MUL | NULL | |
-----------------------------------------------------------------------------------+
14 rows in set (0.00 sec)
I tried to map the 'date' datatype from mysql into the date datatype in oracle, but always
got the ora-01843 error.- How can I EXACTLY set 'NLS_DATE_FORMAT'/'NLS_DATE_LANGUAGE' to fit?
Or is there any other solution? (NLS_LANGUAGE is being initialized as 'AMERICAN')
For error no. 2:
I tried using Java 1.3.1 (which comes with omwb) and java 1.4.0_02.
RAM(on notebook running OMWB ): 256 MB; javaw -mx1024m.
Virtual Memory on machine running OMWB: 1024 MB.
Unfortunately, there was now success. What else can I do?
Is there any possibility to have a look at the generated sql (inserts etc.)
during migration?
Your help is highly appreciated. Thanks for your effort in advance.
Best Regards,
Dan
P.S.: I also tried to use Oracle 9i with 'date' to 'timestamp' mapping, but also got 'ora-01843'
error and additionaly:
'Failed to create default for Table :HOMO_SAPIENS_CORE_8_30.ANALYSISPROCESS; ORA-00907: missing right parenthesis'

Answer 1

Hi Dan,
For Error 1:
This is unusual behaviour. I will raise a bug against the product to have it investigated further but I have not encountered this before. To workaround
the problem, you can firstly migrate the database schema (without the data) by choosing the 'No' radio button in 'Step 3 of 4: Migrate Table data' in the
Migration Wizard. When the schema has successfully been migrated you can create SQL*Loader scripts for the table(s) you want to
migrate data for by select the table name in the Oracle Model UI in the Migration Workbench and choosing Object-Generate SQL*Loader Scripts from
the menu bar. To find out more about the offline data loading facility in the Migration Workbench please refer to the MySQL plugin reference guide.Note that
in the 'sql_load_script.bat' (which is one of the files generated by the Object-Generate SQL*Loader Scripts menu command, you can set your specific
requirements for NLS_DATE_FORMAT, NLS_TIMESTAMP, NLS_LANGUAGE etc.I think this will get you over the problem you are encountering at the
moment.
For Error 2:
Could you provide me with the error.log file that exists in your OMWB\Log directory please ? This may contain extra information about the cause of this
problem. Your virtual memory size etc. should be more than adequate. Also, is this problem happening at a particular point in the migration that you can
identify - e.g. on a particular table ? If so, perhaps you could provide me with the datails of the column types of this table, the number of rows of data
it contains etc. In the meantime, the solution to error 1 may actually be a workaround fot this problem too.
If you need any additional information on the above points, please don't hesitate to contact me.
Tom.