On Wed, 10 Mar 2010 06:02:42 -0800, Johne_uk wrote:

It didn't. I'm the fastest typist in the west.



--
http://mgogala.byethost5.com

On Mar 10, 1:08*pm, Mladen Gogala <n... (AT) email (DOT) here.invalid> wrote:
Depends what your definition of is is. I've seen apps that don't tell
the user the db has gone away until they do some more input or tcp
times out and they get a "server connection lost" error. Though the
more common issue is they X out the client because they entered too
broad of a filter or are otherwise impatient, and happily start
another, blissfully unaware they are giving the server a stress-test
workout.

But of course, worse degradation is obscure data corruption over a
period of time. So maybe a crash isn't so bad, at least it's
recoverable. Unless of course you have some weirdo virtualization
that lies to Oracle about having written redo.

Note to John, about this group: http://dbaoracle.net/readme-cdos.htm

Welcome!

jg
--
@home.com is bogus.
A snarky answer I managed to forbear on forums:
I agree, your DBA needs to be arrested immediately before cardiac
damage ensues.

Please confirm that both instances are running from the same
ORACLE_HOME.
If the are not then the issue is version-related, or installation
related.

Assuming that both instances are run from the same ORACLE_HOME:

I see two possibilities:
1. Instance is killed by something external, similar to someone doing
'kill -p <pid of LGWR>"
2. Instance dies

1. Instance is killed by something external

There are two instances on the server, but only one experiences this
problem, correct? Are instances in any way different? For example,
instance A has 3 GB SGA while instance B has 10 GB SGA?
If they are different then try to make them identical, make sure that
all init.ora parameters are the same (with obvious exceptions - things
like control_files, background_dump_dest). If possible try to achieve
it by REDUCING values, not increasing them. Once this is done we
could expect two outcomes:
- The crashes will stop. It is possible that "something" was killing
instance as it was too big. Once it is made smaller it will no longer
get killed.
- The crashes will affect both instances. This indicates that killing
wasn't based on size.

2. Instance dies

Oracle uses following facilities provided by OS:
- CPU
- memory
- disk
- IPC facilities (shared memory and semaphores on Solaris)

CPU is unlikely to disappear, IPC facilities are allocated at startup,
so most likely the issue is either
memory-related or disk-related. As this is LGWR disk issue seems more
likely.
Do you have dedicated filesystems for each instance? Or filesystems
are shared?
What filesystems you are using: UFS, ZFS, Veritas? Do you use
something fancy like
ODM (Oracle Disk Manager)?

Finally: do you use any fancy Solaris 10 stuff like zones/containers?

- - - - - - - - -

I had a similar issue on Tru64 several years ago, very frustrating.
The database had nightly cold backup. Once-twice per month the
instance would start in corrupted state - it was possible to connect
to it but not run any SQL. Oracle Support pointed to a bug where
instance gets corrupted on startup if something tries to connect to it
in the brief moment between 'startup' command and 'Oracle instance
started' message (just a second or two). It had to be SYSDBA
connection, and it was happening at 6am. What could possibly do that?
Eventually it was traced to UNIX script provided by DEC. It took
several months to locate.

On Mar 10, 7:07*am, Johne_uk <edg... (AT) tiscali (DOT) co.uk> wrote:
You need to ask for a better analyst, and that isn't being facetious.
The ability to predict the quality of the analyst you can get at
Oracle support is about as reliable as their support site.

Seriously, ask for the SR to be escalated/duty managed.

On 10 Mar, 13:07, Johne_uk <edg... (AT) tiscali (DOT) co.uk> wrote:
For example for the better analysis i ask, the LGWR process it's
always the same for the same instance or is it ramdom?
because otherwise could be a hundred of variables for OS for DB.