Reporting against MIMS

[tas1]

Hi

We have quite a large database - e.g. our database is almost 50Gb with indexes and table msf900 has over 14 million rows. We are running 4.3.1.2 with Oracle 8.1.6 on a UNIX HP-UX11 platform. We regularly have in excess of 200 concurrent users. We have up to 30 CorVu connections at a time.

With the above in mind could any of you suggest the best way of providing a reporting environment?

Currently we use CorVu on a standalone server, which has the Production Oracle redo logs applied overnight. We have introduced a number of new indexes but as these must be introduced on production we are reluctant to add more.

Does anyone use CorVu against large databases? How do you go about it? Are data marts the way forward?

Your ideas/suggestions are most welcome.

 

[Calator]

see some sound general advice from Payers in thread 440-98620, it refers to RDL but the ideas are still general enough. Also note the new reporting tool from Business Objects replacing both Corvu and RDL.

 

[chibag]

I suggest you consider creating a reporting instance which takes a daily copy of you production database overnight. Techniques such as mirroring on HP-UX could be worth looking at. This is a 5-10 minute process and will also do your data backups for you. The mirrored copy can then be used for reporting only using Corvu etc. If you consult you HP specialist they should be able to advise on this. I have worked on a site with this setup and would be happy to dig around for you if you pursue this. However there are cost implications but the benefits are great as well.

 

[tas1]

chibag,

This is what we are already doing. It's against this read only copy that we have performance issues using CorVu.

Any help / advice relating to improving prformance?

Thanks

 

[sjwales]

We're using Simple Oracle Replication to replicate our Production Ellipse database (about 110GB total, data and indexes). The master database is Oracle 9.2 on HP-UX 11.11 with the replicated copy running on Windows 2000, also Oracle 9.2.

The Materialized Views are each Fast Refreshed every 30 minutes.

The database as a whole is current to within an hour or two, with the most recent transactional data not always quite in sync within the last 30 minutes (for example, if a PO is received, MSF220 and MSF221 my have replicated a few minutes ago but MSF900 isn't due for replication for another 15 minutes).

It has been working relatively well. We had a few early teething problems, but it's working very well for us now.

stephen.wales@riotinto.com

 

[Calator]

This is really a question to ask in the Corvu forum, unless you wished to look at alternative reporting tools and solutions.
It is likely that you are hitting limitations with Corvu, but most of the time you can improve performance with clever programming, within the limits of any tool. Sorry I cannot help further. This question is much too general in nature. You actually need a very experienced programmer to look at each of your reports and optimise the code or the solution.