Migrating a 2 TB database from 9 i to 10 G Rac ASM

 we   have an oracle database in oracle 9i  sizing up to nearly 2 Terra Bytes in OLTP environment.  we would like to implement Oracle 10g RAC with Storage as ASM  on  a SAN raid 5 and 10.

a) What is the best method to migrate this database to Oracle 10g RAC with minimum
     down time.

b) Can you please also tell me the avg time taken to migrate a 2 TB Size database to 10
    RAC

c) How are the  administratative  tasks  different  with 2 TB database and small databases
     below 200 GB

d) What should be the method for backups. Does RMAN support such big database or  do we need to go for third party tools .if yes which ones

e) What are the problems that we usually encounter in such big databases

Thanks
happylife1234Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mrjoltcolaCommented:
These are a lot of questions. It is recommended to ask one question per thread. I will answer your RMAN / backup & recovery ones


>>a) What is the best method to migrate this database to Oracle 10g RAC with minimum
     down time.


The way to migrate from a standard database to an ASM and/or RAC database, you will use RMAN. That is the only way to backup ASM databases (except when using a SAN mirroring feature such as EMC Timefinder BCVs)

http://www.oracle.com/technology/pub/articles/chan_sing2rac_install.html


>>d) What should be the method for backups. Does RMAN support such big database or  do we need to go for third party tools .if yes which ones


For very large backups, you can do rolling backups with RMAN. Daily you would backup a different set of tablespaces or datafiles. In the event of a recovery, you would end up applying more archive log to the older backups. You will need to keep archivelog to cover the oldest datafile backups to ensure complete recovery.

For large multi terabyte databases, often we do not use plain RMAN backupsets at all, instead we use BCV / Mirror snapshots. This a feature provided by SANs (EMC, NetApp). You put the tablespaces in hot backup mode then snapshot a mirror of the whole filesystem. With this method you can take multi-terabyte backups in minutes.

This is really a very large question and I advise to consult a professional to really help you make your decision.

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mrjoltcolaCommented:
This is the approach we have taken with some large databases that have 24x7 SLA.

I have only done it with EMC but other SAN technologies have similar features.

http://www.emcstorageinfo.com/2007/08/emc-bcv-operation-on-host-running.html

The assumption is that when building your SAN, for database footprint N, you build in N x the number of BCVs you need. So for a recent telecom customer, they had 3 BCVs. The primary database was 2TB, so we had an 8TB EMC SAN. We used three BCVs in rotation in combination with a tape system.
0
schwertnerCommented:
The main question is how to migrate from 9i to 10g.
Export/Import is not good for this DB size.
Possibly you have to try to use the Migration Assistant.
Before this you have to make a full backup of the DB
and this is also a huge problem.

Anather approach (if your DB comprises more then one application)
is to migrate partially - application by application.

RAC,ASM and SAN need experience and knowledge and as suggested by Mrjoltcola professionals with good experience will be the best advisors.
0
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

happylife1234Author Commented:
Hi Mrjoltcola,

Can you please also tell me the avg time taken to migrate a 2 TB Size database to 10    RAC ASM  with procedure  mentioned by you ie from standered database to ASM. What will be the down time  for this method is the database is 2 TB .Does ASM support moving from lower versions to 10G .Can the Mirror snapshots provided by SANs (EMC, NetApp) be used for an upgrade ie from 9 i to 10g ASM.

Thanks
0
mrjoltcolaCommented:
>>Can you please also tell me the avg time taken to migrate a 2 TB Size database to 10

There is no average time. What you are doing is a rare thing for any DBA. I have not done such in a few years and at the time it was on older Sun hardware, not newer, faster CPUs.

Here is my advice (and as schwertner said, RAC/ASM/SAN requires experience, not just a try and see approach...)

Anytime you consider such a major step such as this you should test in a development environment first. For these critical cases, I setup a complete replica of the environment. In your case, I recommend you setup a smaller 9i database with some data from an export. 20GB or so. Then do a migration to 10g RAC. Do this all prior to ever trying it in production. Find out what fails and what works and document every step. Measure the time taken for the 20G migration. Extrapolate that to 2TB using a simple formula.

Follow those same steps in production. Make sure to always have a backup to fallback on. Also make sure to have active Oracle support.

If you do the RMAN copy, you will setup a brand new10g RAC instance while your 9i is still running, then you can take backups and restore realtime to the RAC instance, and recover it to open it. This will ensure no downtime at all, and also ensure you don't lose your 9i database.

To do this requires enough space, preferably a separate SAN. Do you have enough SAN or budget for added space? 2TB nowadays is pretty cheap. I advise this full copy method vs doing an incremental move to ASM as that would be much more complex.


>>Can the Mirror snapshots provided by SANs (EMC, NetApp) be used for an upgrade ie from 9 i to 10g ASM.

Yes, but this requires mounting on a 2nd server and doing the upgrade directly. In either case, moving from standard filesystem to ASM absolutely requires RMAN to do the datafile copy.

0
happylife1234Author Commented:
Hi

Thanks for the information and your  advice  on experience RAC/ASM/SAN .I did get a chance to work on these  though I am not an expert in this field. The database  I worked was about only 200 gb in size but now  I need to work on migrating   2 TB database from 9 i to 10 ASM RAC. I used export and imports and datapump for migrating databases which were relatively small in size .This being 2 Tb data  I  did not have the correct approach for the migration
0
mrjoltcolaCommented:
I would simplify the problem by dividing it into 2 problems.

1) Upgrade to 10g
2) Migrate to ASM/RAC

It is possible to do a rolling migration to ASM datafile at a time.
0
happylife1234Author Commented:
What are the problems that we usually encounter in such big databases and  How are the  administratative  tasks  different  with 2 TB from that of small databases  below 200 GB .



0
schwertnerCommented:
If you succeed to isolate applications on the DB you can migrate using the export (Pump do not work in 9i).
Also think about 11g. If you do not want to earn the money again in some years (joking of course!)
0
mrjoltcolaCommented:
@schwertner: >>If you do not want to earn the money again in some years (joking of course!)

Laugh.


@happylife1234: >>What are the problems that we usually encounter in such big databases and  How are the  administratative  tasks  different

Problems are bigger. Meaning tables are too big for export, or either the maintenance takes longer than is convenient. You need to look at using partitions to ease maintenance on huge tables, so you can maintain individual partition segments at a time.

Backup and recovery is also a problem. For huge databases you might not have enough room for many full backups and RMAN may take too long. That is why I suggest a SAN technology. At least use the RMAN incremental backups with Block Change Tracking (BCT) which requires Enterprise.

As you see, huge databases require a different approach. With small database, when you have problems, often you can just export, re-create a DB and import. With huge datawarehouses, this is not an option. You must carefully maintain the DB as a vital living organism that must not die. :)
0
mrjoltcolaCommented:
I recommend all suggestions by myself and schwertner as valid answers in the discussion.

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.