Message-ID: <F001.005419FE.20030202182842@fatcity.com>
Date: Sun, 02 Feb 2003 18:28:42 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
Sender: root@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: Hemant K Chitale <hkchital@singnet.com.sg>
Subject: DBSNMP connecting ? -- was RE: The lightbulb goes on -
Organization: Fat City Network Services, San Diego, California
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Content-Transfer-Encoding: 7bit


It could be DBSNMP connecting to the database because of the Intelligent Agent.
Why did I call it un-Intelligent ?
$O_H/rdbms/admin/catdbsnmp.sql grants the DBA role to "DBSNMP".  The DBA
role includes the RESTRICTED SESSION privilege.
You should be doing a SHUTDOWN IMMEDIATE.

Me ?   What do I do ?
   a.  Do NOT run the Intelligent Agent [onmost of of my servers -- I have 
configured
the databases in the OMS manually instead of using the "Discover Node" 
connecting
to the Intelligent Agent,  I do not run any Events or Jobs through OMS/IA 
but all
my monitoring scripts through CRON and, therefore, do not need the IA]
   b. Revoke DBA from DBSNMP.  I grant SELECT ANY TABLE if I want to use the
SQL Analyzer to Explain Plan an SQL through OEM connecting to the database
as DBSNMP   and SELECT ANY DICTIONARY [or CATALOG, what was it ?] to
use the Performance Monitor likewise.

There's a couple of alerts on Metalink about catdbsnmp.sql automatically 
resetting
the DBSNMP password and granting it DBA privilege whenever being called 
from catalog.sql
or catpatch.sql [I change the password and modify the privileges each time 
I create or
upgrade a database].

Hemant

At 07:34 AM 31-01-03 -0800, you wrote:
>Ok, so I changed my cold backup script lastnight so it does this;
>
>connect internal/amianidiot
>shutdown abort
>startup restrict
>shutdown normal
>exit
>
>It then does the abort and the startup and then the shutdown normal but 
>then I get this and my database hangs;
>
>Shutting down instance (normal)
>License high water mark = 10
>Fri Jan 31 03:05:35 2003
>SHUTDOWN: waiting for logins to complete.
>
>So now I was totally ready to go postal, but then rational thinking 
>prevailed so I RTFMed.  I then come across this in the FM;
>
>Typically, all users with the CREATE SESSION system privilege can connect 
>to an open database. Opening a database in restricted mode allows database 
>access only to users with both the CREATE SESSION and RESTRICTED SESSION 
>system privilege; only database administrators should have the RESTRICTED 
>SESSION system privilege
>
>So my question is, should all users be created with the system privilege 
>of CREATE SESSION and only I get the RESTRICTED SESSION in addition?  Am I 
>reading this correctly that for the STARTUP RESTRICT to work all users 
>need to have the CREATE SESSION privilege?  We have some third party 
>replication software that is trying to make a connection to Oracle every 5 
>seconds and I think this was the culprit.  It DID NOT have the CREATE 
>SESSION but it does now so I am curious as to if the database will 
>shutdown tonight.  Did I actually learn something??
>
>Thanks,
>
>Dave(iamanidiot)  :o)
>
>-----Original Message-----
>Sent: Thursday, January 30, 2003 7:15 AM
>To: Multiple recipients of list ORACLE-L
>
>
>
>I'll echo that sentiment.
>
>'shutdown abort', 'startup restrict' was a regular part of my
>shutdown scripts beginning in 1994 with 7.0.16, as
>'shutdown immediate' wasn't all that reliable, even in situations
>where it should have worked.
>
>Jared
>
>On Wednesday 29 January 2003 15:53, John Kanagaraj wrote:
> > Rao,
> >
> > And where did you read that 'shutdown abort' is not recommended? This is
> > another myth that has been busted a while ago. A shutdown abort followed by
> > a startup restrict and a normal shutdown is the way to go when dealing with
> > rogue sessions that open a connection and never shutdown. In such cases, a
> > shutdown immediate will _never_ return (certainly not within your 5 to 10
> > minutes). I have been using this method for more than 8 years now -
> > starting at 7.0.16 fyi. The trick in this case is to script it into the rc
> > commands.
> >
> > John Kanagaraj
> > Oracle Applications DBA
> > DBSoft Inc
> > (W): 408-970-7002
> >
> > I don't know what the future holds for me, but I do know who holds my
> > future!
> >
> > ** The opinions and statements above are entirely my own and not those of
> > my employer or clients **
> >
> >
> > -----Original Message-----
> > Sent: Wednesday, January 29, 2003 11:49 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Paula,
> >
> > Shutdown abort is not recommended as the file checkpointing is not done
> > during shutdown abort.  If you need to perform shutdown abort, then, it is
> > preferred to bring up the db with startup restrict (so that the users
> > wouldn't connect) and then, cleanly shutdown the db and bring it up again.
> >
> > Tell to your sys admins. that shutdown immediate would take some time
> > (about 5 to 10 minutes) depending on the activity on your db.  They would
> > have to wait for that much time before calling a DBA during system boots.
> >
> > Rao
> >
> > -----Original Message-----
> > Sent: Wednesday, January 29, 2003 11:30 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> >
> > System Administrator says he doesn't trust that the rc commands will stop
> > if the database doesn't want to shutdown and even if it does would want to
> > shutdown with scripts beforehand so that a DBA could connect and resolve
> > the issue.  Other DBA says this is all wrong and rc commands should include
> > shutdown immediate of database.  In the past I had setup 2 processes in the
> > system scripts for the sys admin - shutdown immediate - wait .... shutdown
> > abort - on a read-only DSS system which of course allows some room for this
> > type of activity.  I kind of would want to know if a database was going to
> > be shutdown with an abort esp. in OLTP system and do it myself.
> >
> >
> >
> > - any ideas
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>--
>Author: Jared Still
>   INET: jkstill@cybcon.com
>
>Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
>San Diego, California        -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from).  You may
>also send the HELP command for other information (like subscribing).
>
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>--
>Author: Farnsworth, Dave
>   INET: DFarnsworth@Ashleyfurniture.com
>
>Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
>San Diego, California        -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from).  You may
>also send the HELP command for other information (like subscribing).

Hemant K Chitale
My web site page is :  http://hkchital.tripod.com


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Hemant K Chitale
  INET: hkchital@singnet.com.sg

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru@fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).