Social Buttons

LightBlog

Breaking

LightBlog

lundi 25 janvier 2016

dr

[82]Thanks Jan How can I resolve this issue then ? ...... Tso P Jan 25,
[84]Hi Tso There is no silver bullet. Without knowi...... Jan

Subject: dr database server
Os info: RHEL5
Oracle info: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0
- Production
Message: Hi Guys
I have DR server that is high on load average. i can't even start
sqlplus on that server.
Is it safe if I kill the ora_arc background processes?
Please help!!!
Thanks in advance...


Subject: Re: dr database server
Message: Hi Tso
The ARC processes are the archiver processes. Killing them will cause
them to be restarted. Any work they did up to that point will be lost
and redone.
If your system is ACTUALLY suffering from high load of the archiver
this might be a bug (archiver stuck somewhere) in which case this might
even help. But those are two huge "might".
But the archivers might not be the real problem and you seeing them
just a symptom. In this case killing them will basically hurt you,
because any work done will be lost and has to be repeated, in effect
causing more load.
Regards,
Jan


Subject: Re: dr database server
Message: Thanks Jan
How can I resolve this issue then ?


Subject: Re: dr database server
Message: Hello Tso,
are there other things that your Oracle database running on the server?
Maybe they can be stopped (eve if this is only temporarily).
Assuming that the DB is "eating all the resources": can you see some
processes consuming more resources? If you can isolate some client
processes ( ... (LOCAL=NO) ...), you might try to kill some and then it
might be possible for you to connect with sqlplus.
As this is a "DR server", have you tried to switch the DB from its
standard server to the DR server? Maybe the DR server is undersized
(CPU, RAM) compared to the standard server?
Have a look in "udump" (user dump), "bdump" (alert log) and "adump" for
some recent files that might contain some useful info.
If everyhting fails, you can still kill the database by killing the
pmon process... (and maybe restart the DB with other init parameters)
Best regards,
Bruno Vroman.


Subject: Re: dr database server
Message: Hi Tso
There is no silver bullet. Without knowing your system, seeing what it
currently does, seeing the timeline of it's behaviour, and lot's of
other details, I cannot tell you how to fix this issue.
That said: Can anyone still work on that system or did it in effect
come to a standstill?
If some people can still work: try to login remotely. Try several
times. Make the application guys shut down all non-essential
applicationservers/clients. Try to see if there are jobs running. STOP
backup-processes and disable the backup-schedules (make sure to later
reactivate the schedules again).
Try to get all non-essential load of the system. Then try to figure out
what was (or possibly still is) causing the unusual high load.
Try looking at the alertlog if there is any hint for a malfunction
there.
After all of this: If nothing helped and the system seems to have come
to a standstill (and only if you are REALLY sure it has and after
informing all involved application owners and if your are at least
"really sure" that you have a valid and somewhat recent backup): Try to
crash the instance and restart it. All ongoing sessions will be killed
and rolled back. This rollback could take a very long time if there was
some huge transaction running.
Regards,
Jan




Visible links

Hidden links:

Aucun commentaire:

Enregistrer un commentaire

Nombre total de pages vues

Adbox