Yes, I want to backup strategy for this.
i mean by "collect", centralization
i mean by "level", layer
The rules of the data layer is divided into three layers hierarchical level contains the first level and the second turn, contains a third level in the tree
I'm afraid simply replacing the word "collect" with "centralization" and "level" with "layer" imparts no additional information or understanding.
Please describe what you mean.
Seems like , and it's just a guess , that you want to manage multiple databases being managed as "one" . If yes, you don't have this option available till the version 12c. But since you are not telling us precisely what you are looking for, it's hard to suggest anything. Tell us in detail what you want and then only we shall be able to answer.
As Aman stated the best way to centralize databases would be to do it if you had Oracle version 12c.
For other versions and if you already had success using export/import, perhaps you could better use datapump or trasportable tablespaces or rman depending on the specific version(s) of the OS and Oracle of each database.
Your strategy should be to move them by layers, first all layer 1 then all layer 2 and finally layer3.
Before you talk of the database you need to look at the design. What really is the design ? For example, Is it data that is aggregated / disaggregated at different "levels" ? Or do the levels / layers indicate navigation paths (e.g. joins) for queries ? You need to look at the schemas in the databases and identify dependencies / links.
Hemant K Chitale
You write a question like a poem, starting with Thanks
If I guess is it something like your question :
You have total 100 databases, 69 databases at the third level, application and users uses the data of these dbs, do some kind of processing and then puts the data to 30 databases at second level; again, application and users uses the data of these 30 dbs, do some kind of processing and then transfers the data to 1 databases at first level right ?
If yes, then calling the same data as a different "level" don't make sense, it just waste of resource, nothing more than it. Take an example :
I have a table in which new employee info get inserted like name, address, phone, join_date, age, gender and salary etc. After completing one year, employee gets increment in his salary and now his salary incremented by suppose 100$. Now, if I says this table is "second level" is it technically right ? What does it mean by second level ? Why should I put the table in another "second level" database ? Can't I do the same select and DMLs on the table at "second level" ? If second level, it need some more and joined columns with other tables, then views are there for you. If still it don't works, it means there is flaw in data design, it requires normalization, a complete and thorough study of business data, flow etc. A single table or database can be used perfectly at any level, if it is talking the business data in proper sense, normalized manner.
I just wish to echo what Ed, Aman and Hemant said. Simply tell us what is application, how the application uses database. and what is 4 digit Oracle version. All we don't know nothing about what you knows and what you are looking for.
As we said before, there is no such option in oracle database until 12c to compile/consolidate multiple databases into a single large database . So if that's what your intention is by saying "compile databases in one place" , as long as you are not on 12c and don't use the new multitenant concept, the answer is, its not possible.
So, cutting through all your of your organization-specific terminology (which we cannot be expected to understand), it looks like the problem reduces to collecting data (not databases) from multiple databases and putting it into one single (aha! "Central") database.
Part of the problem will be application-specefic. Is the structure of the application schema(s) identical across all regional databases? Will the data in the central database need to be identifiable as to which regional database it came from?
Part of the problem is more general, though still application related. How current does the central database need to be? eg, how often does it need to be refreshed from the regional databases?
If I understand the problem, you want different databases, a lot, to be merged into 1.
You can, if each single non-system schema is copied into the new database, which a name that is unique inside that new one database.
You may be entering hell, if lots of duplicates exist and if lots of code uses any of those, since that code may need to be rewritten.
There's no database version issue with that action, but the chance is high it'll not be easy if you want 1 database. Not knowing for us what is in all of those databases.