Creating a Database to Use for Reporting

We are looking to create a reporting database using the same oracle home as my test database to take some of the traffic from our production database. We have the Sungardhe Banner system and I don't want the job submission or forms piece, just use the current data to pull information, which I plane to refesh every night. Can I create a database that are equal to our production and clone the dbf file to the new database? or please give me the solution of what I should do to make this work.

Rman is a very complex topic however the method I used to learn was as
follows
I purchased the book by Robert Freeman and Matthew Hart and I purchased a
laptop
I used version 9 when I started and I had 3 instances on the laptop

since version 9 is more easier to work with I suggest that you do the same
technique
Since I was doing this on my spare time....and no deadline it took me 4
months
But now I am confident and I know my way around Rman

You could start with version 10 and Rman Book by Mathew Hart and Freeman
for 10g also
but hey...do this on a test machine and soon you will be an expert on RMAN
too....

Rather than duplicating the production database, I would be inclined to
create a new instance and create materialized views (snapshots) against the
production tables. Configure your refresh interval as desired, and it will
happen automatically from then on.

Hi Helen, Steve here, I understand what you're looking for - here are some observations:

- I don't see the logic in having your reporting/copied database on the same Oracle home, presumably the same server - this will simply take resources away from your production database.

The copied database has to be on a different server than your production database.

- there are several ways to copy a database:
-- shut down production, make cold backup via OS copy- then use the cold backup to copy the files.
-- Use rman to clone the database
-- shut down production, make a cold backup via NAS snapshot - which is very quick. then, use the NAS snapshot to either:
--- copy the NAS snapshot files via OS copy, or;
--- use NAS cloning to make yourself a copy of production

You'll notice that in all cases you need to shutdown the database to make a cold backup - excepting maybe RMAN (which I'm not that familiar with because I don't use it).

if you want to pursue one of these methods I can probably help you further with the renaming of the data files, etc. it's pretty simple once you get the hang of it.

there is another more expensive way - have a read only physical standby using active data guard - but that is an additional cost option, not included in this standard or enterprise editions ( physical standby is, but not active data guard).

I use RMAN regularly to make a copy of my database.
This is done for test purposes. We have one production database and 3 test
databases for various stages of testing and development.

There are a number of steps involved.
Let me explain how I have done it. Note - My method is not the only
technique - there are other methods also to handle the same thing.

Our Production database is in Log Archive mode and hence we can take a Rman
Backup while the database is working.
The files from the Rman backup are copied to the test server
and I do this at least once a week - I run a process to clone the
Production database to my test system.

Since I have 3 databases on the test....I choose which one I need to be
cloned and run the process accordingly.

Of course if you choose the Cold Backup route you have to shut down the
production database to make a copy of the Production database data files
and other files also.

This is a very common phrase heard in the Computer World...
If you mess with your production system there is a very big chance of
causing a big problem and you can lose your job and never work in the
Computer World again....and I know someone who did exactly this.

He was asked to freeze the database. No more changes to the data and
shut down the database and
decided to make all files READ ONLY
He was not an Oracle DBA and chose to do this and needless to say the
system did not come up at all.
and he lost his job shortly !!!

Please be care full and attempt only these things on a test system first !!!

Look into replication. You can have near real time duplication and you can set up your tables with different indexes designed to maximise performance for pulling reports. Reporting tends to work with ranges of data where production is on individual transactions. You don't want to slow down your production system with indexes that are not needed for getting the transactions into the database but you really want indexes and/or partitioning to speed up pulling ranges of data for a report.