-
Thanks for all the post. The primary reason for not using an actual connection is simplicity and maintenance. we will have to update the password file whenever the password changes. Also, our policy is to discourage storing password info on a file.
Thanks again,
Leo
leonard905
leonard905@yahoo.com
-
well I dont see why my approach would even need some proper user and password
-
Originally posted by pando
well I dont see why my approach would even need some proper user and password
the check on the invalid user may need to be embedded in a background job so that the test can time out in a predictable manner if the database is in an archival hang. The invalid user will not work as far as detecting restricted session mode either because the password is checked before the restricted session privilege.
funky...
"I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."
"Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"
-
well in a proper monitored database we dont only have a job to check if database is up, we have processes which check if filesystem is full, we have a job to check alert log every 5 minutes to check for errors, we have job which checks number of sessions every 30 minutes, jobs which checks on memory usage etc etc etc
if your database hangs and you dont know about it then well... very well monitored
also instead of grep ORA-01017 you can grep for ORA- and treat them according to the codes you want to treat just use case instead of if
the way I am suggesting has been working since years
Last edited by pando; 09-10-2003 at 03:36 AM.
-
Still this point is not addressed
"The invalid user will not work as far as detecting restricted session mode either because the password is checked before the restricted session privilege. "
funky...
"I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."
"Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"
-
As I said you can grep ORA- and treat them using case and let me ask who would open database in restricted mode? DBA right? And who's that? In my case is me and who wrote the monitoring script. Even we are in restricted mode, very rare (and you said database shutdowns abnormally is very rare, not sure if you have worked as Production DBA) You can have lots of options to treat this issue (but as I said it's very rare during daytime you would open database in restricted mode)
Last edited by pando; 09-10-2003 at 07:04 AM.
-
Originally posted by pando
As I said you can grep ORA- and treat them using case
I dunnoo how will you be able to differentiate/interpret between same ORA- errs using CASE or whatever, when you use Junk/Non existent user trying to connect to DB in restrict mode & in OPEN mode(restrict disabled).
Ok here's simple eg
Code:
TEST:SYS> conn junk/junk
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
TEST:SYS> conn / as sysdba
Connected.
TEST:SYS> alter system enable restricted session;
System altered.
TEST:SYS> conn junk/junk
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
TEST:SYS> conn test/test
ERROR:
ORA-01035: ORACLE only available to users with RESTRICTED SESSION privilege
Ok, as you said this is rare case senario, so your method holds good in any other situation.
Abhay.
Last edited by abhaysk; 09-10-2003 at 07:35 AM.
funky...
"I Dont Want To Follow A Path, I would Rather Go Where There Is No Path And Leave A Trail."
"Ego is the worst thing many have, try to overcome it & you will be the best, if not good, person on this earth"
-
I make a pardon, grep would not work in that case.
The script is not perfect but it has been working for years with no problems.
-
ps -ef | grep oracle
or
ps -ef | grep lgw*
-
that doesnt mean you connect to the database ta all, or that it is even running in a normal way - read the rest of the thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|