Migration from one oracle DB to another Oracle DB

Question

Hi ,
We are migration data from one oracle DB to another Oracle DB. Lets take it as DB1 and DB2.
Both are having many tables and many columns. So some tables contains common columns with different data types and same datatype with different datasize.
I am trying to map the columns in both the DB's. Then I will retrieve what are the equal columns and what are columns have difference in data types and datatype lengths.
for Eg : Please find the below tables and the structures.
DB1                                                              DB2
EMP                                                             EMPLOYEE
ENO   VARCHAR2(10)                                  EMP_NO  Number(8)
ENAME  Varchar2(25)                                   EMP_NAME  Varchar2(20)
SAL   NUMBER(8)                                        JOb    VARCHAR2(20)
Description  BLOB/CLOB                              Department   Varcgar2(20)
                                                                   SAL  number(8,3)
                                                                   JOB_DESC  varchar2(30)
I would like to migrate DB1 to DB2
Here I found the differences as follows.
1. There is relation between EMP and EMPLOYEE tables.
2. Datatype is different for EMPNO(DB2) compare to DB1. ( Here in DB1 datatype is Varchar and in DB2 it is Number )
3. in DB1 Ename datatype length is 25 and in DB2 it is 20...
So can any one suggest me any pl/sql automation code how can we map the columns,datatypes,datalengths and other required information.
Can you please suggest me and give your suggestions to write automation code if possible or how can we resolve these type of issues.
Thanks,
Vas 

Answer 1

So can any one suggest me any pl/sql automation code how can we map the columns,datatypes,datalengths and other required information.
No such 'automation code' exists. You need to write your own mapping functions and exception handling processes.
Can you please suggest me and give your suggestions to write automation code if possible or how can we resolve these type of issues.
Finish what you started. The most important step you can take is to create a Functional Requirements document that includes, at a minimum:
1. Mapping of each source table to each target table
2. Lists of possible errors, or dirty data issues, that might be encountered
3. The business rules that should be applied to each of those possible errors
You already made a good start on the mapping for the one table above. And you made a good start of identifying the possible errors:
2. Datatype is different for EMPNO(DB2) compare to DB1. ( Here in DB1 datatype is Varchar and in DB2 it is Number )
Good - it should be easy for everyone in your org to agree that you can't put 'TEXT' data into a NUMBER column so now you need to document that issue:
1. Identify data in DB1.ENO that is not numeric
2. Remove, ignore, fix that data?
What do the business users want to do with text data in that DB1.ENO column that is not numeric? They need to tell you. They may want a report or excel file that contains that 'dirty' data so they can review and/or fix it. They may want to query that data for themselves. They may want to know where that data came from - especially if the data is all supposed to be numeric.
3. in DB1 Ename datatype length is 25 and in DB2 it is 20...
Good - use the same process as above
1. Identify data in DB1.ENAME that is longer than 20.
2. Remove, ignore, fix that data? Truncate it?
Again - it is usually the business users that need to actually determine what should be done. Your job is to identify that 'dirty' data and/or make it available to the business users so they can research it
You don't need to wait for the business users to actually provide all of those answers. You can begin writing pseudo-code that contains steps to deal with those issues - you just can't write the actual code until you have the answers.
You can certainly begin writing queries or procedures that look for 'dirty' data. Just based on the two problems you posted you can write queries to find data that has those two issues.