Re: OPS DBA work (was dumb question)

[Bjørn Engsig]

Title: Message

You're right John - my comments were clearly more of a general nature than specific followup to your statements.

The cool thing is that I expect to get lots of nice business to do if/when people start following Larry's vision:  Many nodes of cheap hardware with Linux and RAC on top:-)

Rgds, Bjørn.

Hallas John wrote:

Bjorn,

I don't have any issues with what you say - in fact it really agrees mostly with what I stated. You have added 2 important factors though, better application knowledge and use of raw file systems.

I use Compaq Tru64 so that does not require raw files systems but other o/s certainly do.

 

I think you were a bit unfair to suggest that  I meant you only needed to check a few init.ora parameters out  ( 'it is far more than knowing the GC_ parameters' ). I am fully aware of the need to look at freelists and freelist groups  -  I encompassed that in my statement

' Management and tuning of internode communication. Specifically reducing the level of pinging  - use of GC% init.ora variables '

 

Anyway I don't think we are that far away from each other

 

Regards

 

John

 

 

 

 -----Original Message-----
From: Bjørn Engsig [mailto:[EMAIL PROTECTED]]
Sent: 05 February 20021 2:25
To: Multiple recipients of list ORACLE-L
Subject: Re: OPS DBA work (was dumb question)

With the caveat, that I am a consultant and not actually a DBA, I would argue very strongly, that the OPS DBA needs quite some extra understanding, knowledge and experience compared to one managing a single instance Oracle.  In particular:

- Performance problems, primarily due to poor application design/development, that are seen in single instance are likely to be one to two orders of magnitude worse in OPS.  Hence, the DBA needs a much better application understanding.

- There are Oracle features (e.g. free list groups) that must be used with OPS and which rarely are needed single instance.

- Recovery scenarios are more complex

- You must use raw devices (except on platforms with inhertance from Digital Corp), which can add complexity

- A frequent requirement of OPS systems is better uptimes than for single instance, which is a very non-trivial task.  The whole stack is far more complex, and even though the possibility to have two or more independent nodes sound really great in theory, the practical assurance, that they are in fact completely independent is difficult.  And if they aren't independent, they are likely to have worse uptimes than the single instance!

 - And I probably forgot something, so it is far more than knowing the GC_ parameters, which, BTW, by itself isn't that simple!

- Also, BTW, note that except for a few things, RAC doesn't make your life easier than OPS!

Thanks, Bjørn.

Shreeni wrote:

 

Hi John,

 

Thx for the input. I really appreciate it. I was just kind of stumped when I was asked not once but several times and places, to point out the diff between an OPS DBA and a "regular" DBA that I am.

 

Thanks again

 

Shreeni

Shreenivasa Rao
e-Z ing Technologies, Inc..
41-43 Beekman Street, 3rd Floor
New York, NY 10038.
Tel: (212)233-9861 xt.241
Fax: (212)233-9862
Cell:(917)861-4966
lsama@e-zingtech.com
***********************************
******Your IT Solutions Provider********
*** *** http://www.e-zingtech.com   *******
Under Bill s.1618 Title III passed by the 105th U.S. Congress this mail can
not be considered spam as long as we include contact information and a remove link for removal from our mailing list. To be removed from our mailing list reply with remove in the subject heading and your email address in the body. Include complete address and/or domain to be removed.
--------------------------------------------

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Hallas John
Sent: Monday, February 04, 2002 4:05 AM
To: Multiple recipients of list ORACLE-L
Subject: OPS DBA work (was dumb question)

Shreeni,

 

The mangement of a OPS system does not require any extra skills or facilities. Areas that are different or need more attention from a standalone instance include the following :

 

Management and tuning of internode communication. Specifically reducing the level of pinging  - use of GC% init.ora variables

Requirement for different start up scripts (exclusive and shared modes)

Some additional work when duplicating databases using RMAN

Perhaps more involvement with application and sys admin teams to determine load balancing factors

 

I am sure there are others (probably ones I should be doing that I am not)

 

The simplest thing to remember about OPS is that there is only 1 set of datafiles and therefore tables, despite the number of instances that may be using those datafiles. This point is occasionally made to those whob elieve that we have a fully resilient set up.

 

HTH

 

John

-----Original Message-----
From: Shreeni [ mailto:[EMAIL PROTECTED] ]
Sent: 04 February 2002 00:40
To: Multiple recipients of list ORACLE-L
Subject: Dumb question

Hi List,

 

To ask a dumb question, is there any special way to run exp/imp on Oracle Parallel server on Solaris ?? Is parallel server DBA different than a "regular" DBA ?? :)

 

TIA

 

Shreeni

Shreenivasa Rao
e- Z ing Technologies, Inc..
41-43 Beekman Street, 3rd Floor
New York, NY 10038.
Tel: (212)233-9861 xt.241
Fax: (212)233-9862
Cell:(917)861-4966
lsama@e-zingtech.com
***********************************
******Your IT Solutions Provider********
*** *** http://www.e-zingtech.com   *******
Under Bill s.1618 Title III passed by the 105th U.S. Congress this mail can
not be considered spam as long as we include contact information and a remove link for removal from our mailing list. To be removed from our mailing list reply with remove in the subject heading and your email address in the body. Include complete address and/or domain to be removed.
--------------------------------------------

 



=========================================================
This electronic message contains information from the mmO2 plc Group
which may be privileged or confidential. The information is intended to be
for the use of the individual(s) or entity named above. If you are not the
intended recipient be aware that any disclosure, copying, distribution or
use of the contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone or email
(to the numbers or address above) immediately.
=========================================================




=========================================================
This electronic message contains information from the mmO2 plc Group
which may be privileged or confidential. The information is intended to be
for the use of the individual(s) or entity named above. If you are not the
intended recipient be aware that any disclosure, copying, distribution or
use of the contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone or email
(to the numbers or address above) immediately.
=========================================================