Oracle Database Discussions

I'm a bit lost here.

People create standby databases when they consider their data to have value.

You are working in a Jurassic version of the product that is apparently so unimportant that no one has applied a patch to it in a decade.

What is it about the entries in the log that is causing you concern? You have a standby ... not Data Guard.

Hi,

What is the last archive log file at the location mentioned.

Regards

Hi anurag,

last applied log in archive destination is arch_1_1701119.arc . but suppose if i apply arch_1_1701120.arc arch_1_1701121.arc then also it is asking for next log
arch_1_1701122.arc which is not available in archive destination in standby server
my concern is ora-279 is any issue in future.

Thanks and Regards

Prakash

dear Daniel A. Morgan,

thx for your reply.

My concern is : is ORA-279 is default behaviour or can we rectify that error (by applying patch as you mentioned)

Regards

prakash

It's the expected behaviour, Oracle records in the redo logs the next SCN and time of that change. For a standby you will always be recovering until you decide to open the standby (or cancel the recovery), so there will always be a next log even if it hasn't been either archived or shipped yet. Your challenge when monitoring this is to determine if the 279 is because you've reached the end of all the archived redo, or you've stopped shipping logs prematurely.

Niall Litchfield
http://www.orawin.info/

Hi Niall Litchfield,

thanks for your reply.

Regards

Praaksh
juniour oracle dba

When I had a similar standby database implementation, I had another background
script monitoring the alert log. If the last occurrence of recovery messages
(eg ORA-279 and others) was "too far in the past", the monitoring script would send
me an alert.
On the primary database, also ensure that you switch logfiles (eg through a job)
with a specific time frequency -- eg every 15minutes or 30minutes.
Then, the standby database might be pulling archivelogs every 1hour or every 2hours
and applying them with the RECOVER DATABASE command.

The monitoring script would then alert me if the last ORA-279 and recovery messages
were, say, more than 2hours old because that would mean that either the primary
isn't generating archivelogs or the recover session isn't running OR that there is
a missing archivelog.

damorgan,
He is running 8.1.7.0. "DataGuard" scripts were initially available for 9i and then
backported (and available as a seperate download) for 8i. Many 8i implementations
did not and do not use DataGuard.
Even if it is "Jurassic" {which it certainly is NOT}, they obviously do have a good
reason for setting up a standby -- they DO have data of value. So, maybe they have
not upgraded to 9i or 10g. There could be a dozen reasons
1. Server HW/OS doesn't support 9i/10g, not budgetting for Server upgrade
2. Application using Forms 2.x or 4.5 and not tested on 9i / 10g (4.5 not certified
on 9i)
3. Low end client PCs working perfectly with Character-mode forms, not powerful
enought to run Jinitiator and Forms 6i / 9i

Just because someone hasn't upgraded to 10g doesn't mean that they are at fault
when you do NOT know the reason why they have not upgraded.
Surely, they do know that 8i is desupported. Don't you think that their management
has undertaken due diligence / cost-benefit analysis in considering whether they
should upgrade to 10g ?
Maybe they have another project implementing 10g in parallel and will be able
to shutdown this environment soon. Maybe they don't need to do so.

Do understand that people are intelligent enough to make their own decisions
considering their particular circumstances and don't go shooting off with your
assumption that anyone not running 10g is a dinosaur.

Hi hemanth,

Thx for your reply.

our frontend application is portal6.5 and we thought of upgrade frontend as well as oracle server within few months. upgradation or changes to the current envirnoment is left to management (where they need to see lot of factors before they go for upgradation).

coming to ora-279 can i ignore the error

Yes, you can ignore the ORA-279s. Treat them as "messages" rather then "errors".

You need to ensure that all archivelogs are being applied by the recovery process.

dear hemanth,

ok thx and i see to that all archivelogs are being applied by the recovery process.


Regards

Prakash