Skip to Main Content

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Tesla.

Asked: November 21, 2016 - 5:37 pm UTC

Last updated: November 23, 2016 - 5:09 am UTC

Version: 12.1.0.2

Viewed 1000+ times

You Asked

I have a primary database and a standby database. On daily basis, during night, we stop the replication between primary and standby and using a storage technology I create a clone of that standby database which I open as an standalone database in read write mode where reporting runs every morning and day.

What happens is that a particular job runs once I open the database in r/w mode and the job is only select query which takes random timings everyday for completion and it takes longer time than the required time window within which it should ideally get complete.

I did look at the job which runs which does full table scan and stuff which I can tune and make it right by creating indexes and query tuning but sadly that database gets dropped every night and a new clone gets created where in the first report runs slow so query optimization doesnt come into picture here.

Later in the day, the speed of the reporting increases as the caching increases and frequently queried data gets cached but during the first reporting run, the job is massively delayed. Do I have any other option here? Increasing the database resources - would it do the trick?

Any help would be appreciated!

and Connor said...

Firstly - perform a trace to see *where* the time is being lost. It could be CPU, it could be I/O, it could be something else.

For the sake of this discussion, we'll assume you are I/O bound.

Some technologies you could explore would be:

- full database caching
- large table caching

so that you are priming the cache as soon as possible. Your first query may still be slow, but at least, even full table scans will prime the cache.

And of course, parallel execution might be a workaround here, ie, burn more resources to get better throughput.

Similarly, if the reports running off the standby are critical *and* indexes assist, then you could create the indexes as invisible on production, so they are not used there, but set 'optimizer_use_invisible_indexes' to true on the standby.

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Why?

Johan Snyman, November 22, 2016 - 8:57 am UTC

Why do you create a clone of the standby database in the first place? You could just start the standby itself in read-only mode for reporting purposes?
Chris Saxon
November 22, 2016 - 11:04 am UTC

If you want to open your standby read-only for reporting you need a license for Active Data Guard. Perhaps the OP hasn't purchased this...

Licensing...

Johan Snyman, November 22, 2016 - 11:31 am UTC

Good point, however, they'll probably incur a licensing cost for the clone database as well. Some other reasons I've come across for not doing this is that they may want to store large result sets in a table, which would not be possible when opened in read only mode, but that can also be overcome by creating a db link to the standby, which would allow the results to be stored in a local table, although the query is still run on the standby.
Connor McDonald
November 23, 2016 - 5:09 am UTC

Perhaps an option for the OP here is

- open the standby as snapshot standby each morning (ie, read write)
- do the reporting, add indexes if needed etc etc
- close the standby, revery to physical standby

More to Explore

Performance

Get all the information about database performance in the Database Performance guide.