In several of the companies I have worked for, I noticed that corporate reporting is off loaded from the production database and done mainly on a clone database which needs to be kept up to date daily by various means, be it a logical standby, Recovery Manager (RMAN) duplication, streams, or other such methods.
Any of these cloning scenarios require duplication of the data plus the need to perform other type of maintenance to keep the copy synchronized.
Once Oracle version 11g came along, it was the first time we could use a standby database open read-only 24/7 without having to shutdown and restart managed recovery to catch up with the primary database.
Unfortunately, the caveat of using a standby database for reporting is that many of the reporting tools require an updatable catalog or repository and/or need to create tables to record query results.
Therefore, the challenge becomes how to deploy a database for reporting purposes that does not require a copy of the data and allows the reporting tool to maintain its catalog or repository and be able to create/drop tables or other objects.
Solution: Build a zero data reporting database.
How?
The main requirement is to have a standby database open in read-only mode, preferably with real-time apply enabled.
And here are the steps:
1) Create new database, preferable on the same server as the standby.
2) Create a clone of the application user account (user only, no objects).
3) Create the following objects in this user account:
- A database link to the standby database and connect using the schema owner to be reported on.
- Views for each production table:
CREATE VIEW prod_tab1 AS
SELECT /*+ DRIVING_SITE(prod_tab1) */ *
FROM prod_tab1@stbydb;
4) Create whatever the reporting tool requires (e.g., a tablespace, catalog, etc.).
5) Grant all permissions necessary to the reporting tool user (schema).
Pros:
- Easy to setup
- No data duplication
- Queries execute on standby database
- No need for synchronizing schema
- Data always up to date
- The possibilities are endless...
Cons:
- Reporting database is down when standby is down.
- Perhaps limited resources on the standby (e.g., memory or processor) may hinder the execution of large queries.
- Can't think of others now, but maybe there are...
PS: In my case, the reporting being off-loaded were the daily, weekly and monthly application reports from our production (aka. "mission critical") database, not any analytical stuff.
Our community of experts have been thoroughly vetted for their expertise and industry experience. Experts with Gold status have received one of our highest-level Expert Awards, which recognize experts for their valuable contributions.
db links are a good idea, I did this exact scenario except for the standby piece myself.
and, while I did not have #1 on my list (my production db was still doing some of the work)
I had the additional requirement that I sometimes needed to include data that I could write to, in addition to the reporting tool itself. In those cases, some of the reporting work would be done by my local machine.
I too copied packages locally, but that was mostly for #1, pull data from remote, process it locally within my copies of the packages.
I tried to keep the code copies to a minimum though, so as to reduce the amount of duplicate maintenance required.
For the same reason, I didn't always use views locally, instead I simply created the synonym directly to the remote object. That way I had fewer local structures to make sure I kept in synch.
I agree, synonyms instead of views would be the best, but sometimes when joining two remote tables it was generating too much sqlnet traffic. This went away by creating the views with the "driving_site" hint.
Comments (7)
Author
Commented:Commented:
and, while I did not have #1 on my list (my production db was still doing some of the work)
I had the additional requirement that I sometimes needed to include data that I could write to, in addition to the reporting tool itself. In those cases, some of the reporting work would be done by my local machine.
I too copied packages locally, but that was mostly for #1, pull data from remote, process it locally within my copies of the packages.
I tried to keep the code copies to a minimum though, so as to reduce the amount of duplicate maintenance required.
For the same reason, I didn't always use views locally, instead I simply created the synonym directly to the remote object. That way I had fewer local structures to make sure I kept in synch.
Author
Commented:Commented:
Commented:
View More