PL/SQL objects, procedures, function, trigger,etc.
No, A db and B db are not the same branch.

snowball wrote on Mon, 19 September 2011 11:52

PL/SQL objects, procedures, function, trigger,etc.
No, A db and B db are not the same branch.

That answers my first question but not the other two.

>In short, the original schemas in DB B can not be changed according to this merging, the conflict schemas, in DB A should be adjusted.
Forgive me, but what exactly does "adjusted" mean with regards to SQL & schemas?

How will you or I or anyone recognize when correct solution has been posted?

You need to get the developers to manually sort out all the procedures/functions sql etc. Then you can import the data.
There is no generic way to do this.

Well, yes and no... you can store the relevant information in tables , import the tables into the new DB (i.e. source code, names, tables but not information et all) and write a package to check this info against objects in the new DB and rename if be, and then automatically update your tables with the new name ( and re-process a package or procedure if the renaming means it has to be re-done due to a change in a related package)... but its a hell of a lot of work, and unless you have thousands upon thousands of objects or have to do this on a regular basis, you're better off by doing it manually and then importing the data.

However, if done well then this system would be generic, in that you can grab a schema and export it via seperate tables, import tables and then compare. We use a similar system to roll out patches, but we only compare tables and keys, we simply overwrite all the packages, triggers and synonyms. There will be copious use of DBMS_SQL however, so you'd better know how to handle that, and having a good knowledge of all the relevant views also helps.

Can you export the schema from DB A and just import it into a separate schema on B? or do they actually have to be "merged"?

Data Pump.

Regards
Michel

Baranor wrote on Tue, 20 September 2011 20:20

Well, yes and no... you can store the relevant information in tables , import the tables into the new DB (i.e. source code, names, tables but not information et all) and write a package to check this info against objects in the new DB and rename if be, and then automatically update your tables with the new name ( and re-process a package or procedure if the renaming means it has to be re-done due to a change in a related package)... but its a hell of a lot of work, and unless you have thousands upon thousands of objects or have to do this on a regular basis, you're better off by doing it manually and then importing the data.

However, if done well then this system would be generic, in that you can grab a schema and export it via seperate tables, import tables and then compare. We use a similar system to roll out patches, but we only compare tables and keys, we simply overwrite all the packages, triggers and synonyms. There will be copious use of DBMS_SQL however, so you'd better know how to handle that, and having a good knowledge of all the relevant views also helps.

It seems that a little bit complicate for me. But, it's a still look like a convient solution.
Thanks.

Michel Cadot wrote on Mon, 19 September 2011 13:08

Data Pump.

Regards
Michel

snowball wrote on Tue, 20 September 2011 21:14

Baranor wrote on Tue, 20 September 2011 20:20

Well, yes and no... you can store the relevant information in tables , import the tables into the new DB (i.e. source code, names, tables but not information et all) and write a package to check this info against objects in the new DB and rename if be, and then automatically update your tables with the new name ( and re-process a package or procedure if the renaming means it has to be re-done due to a change in a related package)... but its a hell of a lot of work, and unless you have thousands upon thousands of objects or have to do this on a regular basis, you're better off by doing it manually and then importing the data.

However, if done well then this system would be generic, in that you can grab a schema and export it via seperate tables, import tables and then compare. We use a similar system to roll out patches, but we only compare tables and keys, we simply overwrite all the packages, triggers and synonyms. There will be copious use of DBMS_SQL however, so you'd better know how to handle that, and having a good knowledge of all the relevant views also helps.

It seems that a little bit complicate for me. But, it's a still look like a convient solution.
Thanks.

Basically what you do is copy most of Oracle's Data Dictionary into seperate tables and then write code to compare and update. But it depends on your requirements, like I said... its not worth it for a one-off. I work for a company where constant patching and expanding of the software is normal, and then you need a better delivery system that does the job every time.