When working on a standby database recently, I went to DG Broker to check the status and received this:
DGMGRL> show configuration
Configuration - resp_ress_config
Protection Mode: MaxPerformance
resp - Primary database
ress - Physical standby database
Error: ORA-16766: Redo Apply is stopped
Hmm…my standby is not applying redo. When I attempted to start managed recovery, I got the following in the standby alert log:
This is my 100th post to this blog!!!
I’ve been working on tuning our network configuration between our primary and standby databases. This entry shows the steps I took.
The latest/greatest version of Oracle’s free SQL Developer has now been released. Previously, version 4.0 was in Early Adopter release, which I think is just a fancy way of saying “beta”.
If you want to see new features or tips and tricks, then go to That Jeff Smith’s blog. He is the product manager for this product and writes about lots of new things in the product. I visit his blog regularly.
Earlier today, I was answering a question where someone proposed as a possible solution the idea of flushing the Shared Pool to solve a problem with one SQL statement. I find this to be bad advice. As I stated in my reply, why kill all end user’s performance to solve one guy’s problem? My answer was that if we needed to remove that SQL statement from the Shared Pool, let’s flush the cursor. This ability has been around since Oracle 10g. And Oracle employee blogged the details here: