|
Home > Archive > Oracle Server > August 2005 > Script for performing clean shutdown before windows shutdown
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Script for performing clean shutdown before windows shutdown
|
|
| Ach C via DBMonster.com 2005-08-15, 11:23 am |
| Hi all,
I need a script to perform a clean oracle shutdown every time that windows
going to shutdown.I need this to be sure that there wont be any instance
recovery every time I startup the oracle(Mostly I fear from header
inconsistency and ...).
Is there any thing that I can deploy for my development sites?
-Your help will be so appreciated
--
Message posted via http://www.webservertalk.com
| |
| sybrandb@yahoo.com 2005-08-15, 11:23 am |
| Windows will a shutdown immediate when shutting down the Oracle
service.
You don't have to do anything.
If you insist on having a script, just calling oradim is sufficient. I
leave it to you as an exercise in reading documentation to find out the
exact syntax.
--
Sybrand Bakker
Senior Oracle DBA
| |
| bdbafh@gmail.com 2005-08-15, 11:23 am |
| Your fears are well founded.
Even with the service configured to perform a shutdown immediate when
the service is stopped, if control is not returned within the "wait to
kill service timeout" the process is terminated in a non-graceful
fashion and crash recovery will be required ... possibly requiring
media recovery to be performed.
best approach is to:
connect / as sysdba
alter system switch logfile;
shutdown abort
startup mount restrict
alter system set job_queue_processes=
0;
alter database open;
shutdown immediate
then stop the operating system service.
you'll also want to alter the value for the registry key
HKLM\SYSTEM\CurrentC
ontrolSet\Control\Wa
itToKillServiceTimeo
ut
the default is 20000 (20 seconds).
I'd recommend setting it to at least 300 seconds.
hth.
-bdbafh
| |
| Andreas Sheriff 2005-08-15, 11:23 am |
| <bdbafh@gmail.com> wrote in message
news:1124119055.886364.226290@g14g2000cwa.googlegroups.com...
> Your fears are well founded.
>
> Even with the service configured to perform a shutdown immediate when
> the service is stopped, if control is not returned within the "wait to
> kill service timeout" the process is terminated in a non-graceful
> fashion and crash recovery will be required ... possibly requiring
> media recovery to be performed.
>
> best approach is to:
>
> connect / as sysdba
> alter system switch logfile;
> shutdown abort
> startup mount restrict
> alter system set job_queue_processes=
0;
> alter database open;
> shutdown immediate
>
> then stop the operating system service.
>
> you'll also want to alter the value for the registry key
> HKLM\SYSTEM\CurrentC
ontrolSet\Control\Wa
itToKillServiceTimeo
ut
> the default is 20000 (20 seconds).
> I'd recommend setting it to at least 300 seconds.
>
> hth.
>
> -bdbafh
>
DO NOT SHUTDOWN ABORT
If you're that fearful, execute a SHUTDOWN IMMEDIATE manually every time you
wish to stop or restart the OS. Don't rely on scripts to do it for you
because scripts can fail.
--
Andreas Sheriff
Oracle 9i Certified Professional
Oracle 10g Certified Professional
Oracle 9i Certified PL/SQL Developer
----
"If you don't eat your meat, you cannot have any pudding.
"How can you have any pudding, if you don't eat your meat?"
DO NOT REPLY TO THIS EMAIL
Reply only to the group.
| |
| Holger Baer 2005-08-15, 11:23 am |
| Andreas Sheriff wrote:
> <bdbafh@gmail.com> wrote in message
> news:1124119055.886364.226290@g14g2000cwa.googlegroups.com...
>
>
>
> DO NOT SHUTDOWN ABORT
>
> If you're that fearful, execute a SHUTDOWN IMMEDIATE manually every time you
> wish to stop or restart the OS. Don't rely on scripts to do it for you
> because scripts can fail.
>
Only that SHUTDOWN IMMEDIATE might wait a long time if, e.g. the Intelligent(?)
Agent is running.... So scripting isn't too bad, provided you know the limitations.
In general shutting down everything that connects to the database (Intelligent Agent,
DBConsole/EnterpriseManager....) should be shutdown first, then the database, and
finally the listener (although the listener can be shutdown upfront to prevent logins).
On a busy database you might still have problems with shutdown immediate, though.
And if you don't trust Oracle to recover from a shutdown abort, don't use Oracle.
Or invest in proper HW, OS and training.
Regards,
Holger
| |
| Andreas Sheriff 2005-08-15, 8:23 pm |
| "Holger Baer" <holger.baer@science-computing.de> wrote in message
news:ddqef3$pfa$1@ne
ws.BelWue.DE...
> Andreas Sheriff wrote:
>
> Only that SHUTDOWN IMMEDIATE might wait a long time if, e.g. the
> Intelligent(?)
> Agent is running.... So scripting isn't too bad, provided you know the
> limitations.
>
> In general shutting down everything that connects to the database
> (Intelligent Agent,
> DBConsole/EnterpriseManager....) should be shutdown first, then the
> database, and
> finally the listener (although the listener can be shutdown upfront to
> prevent logins).
>
> On a busy database you might still have problems with shutdown immediate,
> though.
>
> And if you don't trust Oracle to recover from a shutdown abort, don't use
> Oracle.
> Or invest in proper HW, OS and training.
>
> Regards,
> Holger
SHUTDOWN IMMEDIATE will not wait.
From the 10gR2 SQL PLUS documentation:
(SHUTDOWN) IMMEDIATE
Does not wait for current calls to complete or users to disconnect from the
database.
Further connects are prohibited. The database is closed and dismounted. The
instance is shutdown and no instance recovery is required on the next
database startup.
If you don't believe me, try it. Start several transactions from several
sources, including the agent/console/EM/etc... and you'll see that any
active transaction will be rolled back, no further connections will be
allowed, and the database will shutdown.
SHUTDOWN TRANSACTIONAL will wait, however.
And if IMMEDIATE seems to wait, that's only because the database is busy
finishing activity it needs to shutdown.
--
Andreas
Oracle 9i Certified Professional
Oracle 10g Certified Professional
Oracle 9i Certified PL/SQL Developer
"If you don't eat your meat, you cannot have any pudding.
"How can you have any pudding if you don't eat your meat?!?!"
---
WARNING:
DO NOT REPLY TO THIS EMAIL
Reply to me only on this newsgroup
| |
| bdbafh@gmail.com 2005-08-15, 8:23 pm |
| In 9 years, I have never seen a problem with the use of shutdown abort.
Perhaps you might want to plug the following string into metalink and
see what you get back: "shutdown immediate hang".
In the past, the "Oracle Intelligent Agent" could cause shutdown
immediate to hang. DBMS_JOBs, advanced queueing, etc could also cause a
shutdown immediate to not complete in a reasonable amount of time.
I only use cold backups prior to upgrades/patchsets and regularly rely
upon hot physical backups or rman-created backup sets. IMHO, cold
backups are problematic and typically unnecessary. If I am creating a
cold backup set, I manually shutdown the instance cleanly prior to
creating the backup set.
hth.
-bdbafh
| |
| Ach C via DBMonster.com 2005-08-16, 1:24 pm |
| Thanks for your replies,
Let me say complete story for you: One of our sites had to format its OS
due to a HW problem.Our most recent backup of oracle on that site was about
6 days old and we did not want to loose those days data.Finally I did
resotre database using old remaining oracle files(Similar to what you may do
about cold backups).
We are lucky because I found if the header of datafiles were not in match
(due to a dirty shutdown) we could not restore those files.So it was the
sprite of this thread: How can I made all sites to perform a clean shutdown
before windows shutdown? I know I can't force all those DBAs to do a
"shutdown immediate or normal" every time so the workaround is to do so
automatically.
Hope to be clear enough.
-Regards
--
Message posted via webservertalk.com
http://www.webservertalk.com/Uwe/Fo...oracle/200508/1
| |
| Holger Baer 2005-08-16, 1:24 pm |
| Andreas Sheriff wrote:
> "Holger Baer" <holger.baer@science-computing.de> wrote in message
> news:ddqef3$pfa$1@ne
ws.BelWue.DE...
>
>
>
> SHUTDOWN IMMEDIATE will not wait.
Not my experience. However, I have to admit that setting up a test case
with Intelligent Agent failed, too.
>
> From the 10gR2 SQL PLUS documentation:
> (SHUTDOWN) IMMEDIATE
>
> Does not wait for current calls to complete or users to disconnect from the
> database.
>
> Further connects are prohibited. The database is closed and dismounted. The
> instance is shutdown and no instance recovery is required on the next
> database startup.
>
> If you don't believe me, try it. Start several transactions from several
> sources, including the agent/console/EM/etc... and you'll see that any
> active transaction will be rolled back, no further connections will be
> allowed, and the database will shutdown.
>
> SHUTDOWN TRANSACTIONAL will wait, however.
>
> And if IMMEDIATE seems to wait, that's only because the database is busy
> finishing activity it needs to shutdown.
I'm perfectly aware of the differences between shutdown normal, transactional, immediate,
abort, thank you.
But I've seen Intelligent Agent preventing an idle instance from shutting down
with IMMEDIATE and so you're on the safe side to shutdown local services first
before shutting down the instance.
But any way, my point was that there is no intrinsic harm in using SHUTDOWN ABORT.
So the suggestion of BDBAFH stands.
Regards,
Holger
| |
| Andreas Sheriff 2005-08-16, 1:24 pm |
| "Holger Baer" <holger.baer@science-computing.de> wrote in message
news:ddsdcq$s2r$1@ne
ws.BelWue.DE...
> Andreas Sheriff wrote:
time[color=darkred]
immediate,[color=dar
kred]
use[color=darkred]
>
> Not my experience. However, I have to admit that setting up a test case
> with Intelligent Agent failed, too.
the[color=darkred]
The[color=darkred]
several[color=darkre
d]
>
> I'm perfectly aware of the differences between shutdown normal,
transactional, immediate,
> abort, thank you.
>
> But I've seen Intelligent Agent preventing an idle instance from shutting
down
> with IMMEDIATE and so you're on the safe side to shutdown local services
first
> before shutting down the instance.
>
> But any way, my point was that there is no intrinsic harm in using
SHUTDOWN ABORT.
> So the suggestion of BDBAFH stands.
>
> Regards,
> Holger
SHUTDOWN ABORT is the same thing as executing
kill -s KILL $(ps -Af | gawk '/ora_${ORACLE_SID}/{print $2}')
It KILLs all Oracle instance processes for that SID. You go ahead and keep
using SHUTDOWN ABORT.
There are only two instances in which you should use SHUTDOWN ABORT
1. When the instance is not responding. An alternative would be to use
STARTUP FORCE then SHUTDOWN IMMEDIATE. STARTUP FORCE would call SHUTDOWN
ABORT anyway, then restart the instance. Using SHUTDOWN abort directly or
indirectly may require recovery, or even restore at the next startup.
2. When the instance isn't started at all. In my 9i RAC class we've had to
use SHUTDOWN ABORT after shutting down the instance normally because there
were left over footprints (muteces and or semaphores, I suspect) for the
instance after a normal shutdown.
--
Andreas Sheriff
Oracle 9i Certified Professional
Oracle 10g Certified Professional
Oracle 9i Certified PL/SQL Developer
----
"If you don't eat your meat, you cannot have any pudding.
"How can you have any pudding, if you don't eat your meat?"
DO NOT REPLY TO THIS EMAIL
Reply only to the group.
| |
| fitzjarrell@cox.net 2005-08-26, 8:23 pm |
|
Andreas Sheriff wrote:
> "Holger Baer" <holger.baer@science-computing.de> wrote in message
> news:ddsdcq$s2r$1@ne
ws.BelWue.DE...
> time
> immediate,
> use
> the
> The
> several
> transactional, immediate,
> down
> first
> SHUTDOWN ABORT.
>
> SHUTDOWN ABORT is the same thing as executing
> kill -s KILL $(ps -Af | gawk '/ora_${ORACLE_SID}/{print $2}')
> It KILLs all Oracle instance processes for that SID. You go ahead and keep
> using SHUTDOWN ABORT.
And I will when I deem it necessary. Let's look at the suggested
procedure again:
connect / as sysdba
alter system switch logfile;
shutdown abort
startup mount restrict
alter system set job_queue_processes=
0;
alter database open;
shutdown immediate
I see no issue with what has been posted. A shutdown abort has been
issued to ensure the instance stops. A startup mount restrict is then
executed, followed by an alter dsatabase open, to enable the necessary
recovery after the shutdown abort. The database is finally shutdown
immediate, requiring no recovery on startup.
Had only a simple 'shutdown abort' been suggested I may have tended to
agree with your assessment. However, in this situation your advice is
wrong.
>
> There are only two instances in which you should use SHUTDOWN ABORT
> 1. When the instance is not responding. An alternative would be to use
> STARTUP FORCE then SHUTDOWN IMMEDIATE. STARTUP FORCE would call SHUTDOWN
> ABORT anyway, then restart the instance. Using SHUTDOWN abort directly or
> indirectly may require recovery, or even restore at the next startup.
> 2. When the instance isn't started at all. In my 9i RAC class we've had to
> use SHUTDOWN ABORT after shutting down the instance normally because there
> were left over footprints (muteces and or semaphores, I suspect) for the
> instance after a normal shutdown.
>
Incorrect. This is a case where shutdown abort is useful, especially
as other Oracle services may be running which could interfere with a
plain-vanilla shutdown immediate.
Shutdown abort is no worse than any other shutdown mode, it only defers
recovery until the next startup. Yes, it is a 'brute force' method to
shutdown an instance; sometimes that is necesary to ensure the instance
stops in a timely manner. One cannot wait forever for Oracle to shut
down when a server is in the midst of a reboot.
Again, this is surprising advice from a professed OCP.
> --
>
> Andreas Sheriff
> Oracle 9i Certified Professional
> Oracle 10g Certified Professional
> Oracle 9i Certified PL/SQL Developer
> ----
> "If you don't eat your meat, you cannot have any pudding.
> "How can you have any pudding, if you don't eat your meat?"
>
> DO NOT REPLY TO THIS EMAIL
> Reply only to the group.
David FItzjarrell
| |
| Andreas Sheriff 2005-08-26, 8:23 pm |
| Comments inline.
<fitzjarrell@cox.net> wrote in message
news:1125084808.407326.274810@g44g2000cwa.googlegroups.com...
>
> Andreas Sheriff wrote:
>
> And I will when I deem it necessary. Let's look at the suggested
> procedure again:
>
> connect / as sysdba
> alter system switch logfile;
> shutdown abort
> startup mount restrict
> alter system set job_queue_processes=
0;
> alter database open;
> shutdown immediate
>
> I see no issue with what has been posted. A shutdown abort has been
> issued to ensure the instance stops. A startup mount restrict is then
> executed, followed by an alter dsatabase open, to enable the necessary
> recovery after the shutdown abort. The database is finally shutdown
> immediate, requiring no recovery on startup.
>
> Had only a simple 'shutdown abort' been suggested I may have tended to
> agree with your assessment. However, in this situation your advice is
> wrong.
>
>
>
> Incorrect. This is a case where shutdown abort is useful, especially
> as other Oracle services may be running which could interfere with a
> plain-vanilla shutdown immediate.
>
> Shutdown abort is no worse than any other shutdown mode, it only defers
> recovery until the next startup. Yes, it is a 'brute force' method to
> shutdown an instance; sometimes that is necesary to ensure the instance
> stops in a timely manner. One cannot wait forever for Oracle to shut
> down when a server is in the midst of a reboot.
>
What do you think would happen if Oracle were in the middle of writing to a
block when you issue SHUTDOWN ABORT?
There are some disk systems that would prevent partial writes, but then
again, there are some disk systems that do not prevent partial writes and
leaves files open.
It's never good to have a partial write done to a disk or to kill programs
that have files open. If it were ok to use SHUTDOWN ABORT because it's "no
more worse than any other shutdown mode", then why don't you just hit "the
big red switch" and be done with it?
I'll tell you how you can find out.
Just type lsof on any unix system and you'll see.
Sure, use shutdown abort as a last resort, but only as a last resort, not as
a replacement for your usual shutdown procedure.
> Again, this is surprising advice from a professed OCP.
OCP, 6 years Oracle experience and twelve years programming experience with
all kinds of languages and operating systems.
Again, this is surprising advice form a professed Oracle Professional
without credentials.
>
>
>
> David FItzjarrell
>
--
Andreas
Oracle 9i Certified Professional
Oracle 10g Certified Professional
Oracle 9i Certified PL/SQL Developer
"If you don't eat your meat, you cannot have any pudding.
"How can you have any pudding if you don't eat your meat?!?!"
---
WARNING:
DO NOT REPLY TO THIS EMAIL
Reply to me only on this newsgroup
| |
|
| On Fri, 26 Aug 2005 14:10:08 -0700, Andreas Sheriff interested us by
writing:
> What do you think would happen if Oracle were in the middle of writing to a
> block when you issue SHUTDOWN ABORT?
A transaction is only marked as 'committed' when it's been successfully
written to the redo log. If it's not completed the write the database will
simply rollback the transaction that is incomplete on restart of the
database. (Confirmed in the Administrator's manual, Redo Log chapter.)
And also realize that we do not care whether any datafile blocks have
been written, as that info can always be reproduced by the log file
entries. The exceptions to this may start with the new 10gR2 'COMMIT WRITE
NOWAIT' feature.
An abort is therefore is no biggie from the database's point of view,
however users might get annoyed if they find out everything except the
last write was complete.
So unless it's an issue with the operating system, so far it really
doesn't matter much whether you shutdown abort. What does matter is what
happens immediately after the shutdown abort ...
For example, it does matter whether you take a cold backup of the aborted
database, especially if the database is in NOARCHIVELOG mode. A rule
of thumb is that, as soon as feasible, an aborted database should be
reopened and shutdown 'properly' to ensure the control file and the data
files are properly synchronized.
All that said, I agree with the earlier statement that shutdown abort
should only be used when there is an abnormal situation. It's a last
resort, and even discussed that way in the Administrator's Guide
http://download-west.oracle.com/doc.../start.htm#6398
(This has been discussed many, many times in this list. Check the
archives before 2003 for discussions by Howard Rogers.)
--
Hans Forbrich
Canada-wide Oracle training and consulting
mailto: Fuzzy.GreyBeard_at_gmail.com
*** I no longer assist with top-posted newsgroup queries ***
| |
| fitzjarrell@cox.net 2005-08-27, 9:23 am |
|
Andreas Sheriff wrote:
....snipped...
>
> OCP, 6 years Oracle experience and twelve years programming experience with
> all kinds of languages and operating systems.
>
> Again, this is surprising advice form a professed Oracle Professional
> without credentials.
>
That I choose to NOT wear my 'credentials' on my sleeve is of no
concern to you, nor is it any indication I have none. I, also, am an
Oracle Certified Professional, with over 17 years of professional
Oracle database administration experience. Your questions have been
answered in the documentation and in this newsgroup many times before,
and your rationale has fallen on its face more than once. I stand by
the statements I made; it's sad you can't argue a point with fact
rather than with personal insults.
My comments on your OCP 'credentials' were not made as insults, merely
as commentary on your 'apparent' knowledge of the database system and
your willingness to accept fallacious argument as fact.
I believe an apology is in order.
>
>
> --
> Andreas
> Oracle 9i Certified Professional
> Oracle 10g Certified Professional
> Oracle 9i Certified PL/SQL Developer
>
>
> "If you don't eat your meat, you cannot have any pudding.
> "How can you have any pudding if you don't eat your meat?!?!"
> ---
>
> WARNING:
> DO NOT REPLY TO THIS EMAIL
> Reply to me only on this newsgroup
David Fitzjarrell
| |
| fitzjarrell@cox.net 2005-08-27, 8:23 pm |
| Comments embedded.
Andreas Sheriff wrote:
> Comments inline.
>
> <fitzjarrell@cox.net> wrote in message
> news:1125084808.407326.274810@g44g2000cwa.googlegroups.com...
<..snipped..>[color=darkred]
>
> What do you think would happen if Oracle were in the middle of writing to a
> block when you issue SHUTDOWN ABORT?
>
> There are some disk systems that would prevent partial writes, but then
> again, there are some disk systems that do not prevent partial writes and
> leaves files open.
>
> It's never good to have a partial write done to a disk or to kill programs
> that have files open. If it were ok to use SHUTDOWN ABORT because it's "no
> more worse than any other shutdown mode", then why don't you just hit "the
> big red switch" and be done with it?
> I'll tell you how you can find out.
> Just type lsof on any unix system and you'll see.
>
An interesting comment regarding a utility not available on Solaris:
# lsof
lsof: not found
# man lsof
No manual entry for lsof.
#
One would expect 'root' to have access to such a utility, yet there is
no such program or script on Solaris, nor is there any manual page
describing it. Your 'any unix system' comment, therefore, is in error.
Yes, to the unintiated UNIX is UNIX; those who have worked on various
distributions from numerous vendors know differently. AIX != HPUX !=
Solaris != DGUX != RISCos, to name but a few; any number of releases of
Linux differ from each other in similar ways. It would help
tremendously for you to know your operating systems before issuing
blanket statements such as yours. That a utility/program/script exists
in one release by one vendor in no way makes it a universal component
of all UNIX releases and versions. And, if Solaris is the ONLY
distribution of UNIX not possessing lsof, it is enough to make your
statement invalid.
> Sure, use shutdown abort as a last resort, but only as a last resort, not as
> a replacement for your usual shutdown procedure.
>
I never stated using it as a replacement for the USUAL shutdown
procedure and you will have a difficult time proving I wrote any such
text. Windows servers in need of a reboot create a different situation
than normal, and, as such, may require more 'extreme' measures.
Obviously you've not administered Oracle on a Windows machine.
>
> OCP, 6 years Oracle experience and twelve years programming experience with
> all kinds of languages and operating systems.
>
> Again, this is surprising advice form a professed Oracle Professional
> without credentials.
>
I have already answered this erroneous comment in a prior post. Again,
the fact I do NOT choose to wear my 'credentials' on my sleeve is of no
concern to you, nor does it indicate that I do not possess such
'credentials'. Seventeen years of Oracle database administration
experience, as well as OCP certification, qualifies as 'credentials'.
I am still waiting for your apology for such a flippant and errant
remark.
>
>
> --
> Andreas
> Oracle 9i Certified Professional
> Oracle 10g Certified Professional
> Oracle 9i Certified PL/SQL Developer
>
>
> "If you don't eat your meat, you cannot have any pudding.
> "How can you have any pudding if you don't eat your meat?!?!"
> ---
>
> WARNING:
> DO NOT REPLY TO THIS EMAIL
> Reply to me only on this newsgroup
David Fitzjarrell
| |
| Andreas Sheriff 2005-08-27, 8:23 pm |
|
<fitzjarrell@cox.net> wrote in message
news:1125150168.244616.142800@f14g2000cwb.googlegroups.com...
>
> Andreas Sheriff wrote:
> ...snipped...
with[color=darkred]
>
> That I choose to NOT wear my 'credentials' on my sleeve is of no
> concern to you, nor is it any indication I have none. I, also, am an
> Oracle Certified Professional, with over 17 years of professional
> Oracle database administration experience. Your questions have been
> answered in the documentation and in this newsgroup many times before,
> and your rationale has fallen on its face more than once. I stand by
> the statements I made; it's sad you can't argue a point with fact
> rather than with personal insults.
>
> My comments on your OCP 'credentials' were not made as insults, merely
> as commentary on your 'apparent' knowledge of the database system and
> your willingness to accept fallacious argument as fact.
>
> I believe an apology is in order.
>
>
>
>
>
> David Fitzjarrell
>
David,
I apologize for attacking your 17 year history as a DBA and your
accomplished certification.
My reaction was a knee-jerk response from your statement stating "again,
this is surprising advice from a professed OCP." Your choice of words
skewed the meaning of your expression and led me to believe that you were
insulting and attacking my successful efforts at gaining OCP certification
and the further advancement of my knowledge in Oracle.
I do respect and admire your 17 year history as a DBA and welcome any advice
that you have to share. However, you must agree that you are human, and
being human you are capable of mistakes. And executing a mistake for 17
years does not make it correct. The following is a true story giving an
example that a mistake can be replicated for many years without being
caught.
One of my classes during my college years was "Compiler Construction for the
C Language." The professor was very accomplished in his carrer and quite
advanced in his knowledge. Everything he had said and shown the students
about compiler construction was useful and correct, until he blatantly
stated "the complier needs to separate tokens from identifiers. The way it
does this is by naming the token with an illegal identifier name. The
illegal name it constructs uses an underscore to start the name of the token
because a C identifier cannot begin with an underscore." I stopped writing
and looked up in amazement. I was pretty sure I didn't hear this, but then
he stated it again, and again, and again. At the end of the class I sought
him alone to correct him on his mistake, so that the other students wouldn't
be misled into thinking that a C identifier couldn't begin with an
underscore. At first he was resistant to what I had to say, thinking that I
was arrogant and confrontational. Then, after he went home, and returned to
class the following week, having researched the rules for naming identifiers
in the K&R book he came to the conclusion that his statement about
identifiers are illegal when begun with an understore was inaccurate. He
corrected the class and acknowledged my correction. After the class, I
again met him alone and explained that I was not trying to be arrogant nor
confrontational. I was simply trying to correct him on an error that would
mislead the students and students to come. His respons was,
"I can't believe I was teaching it wrong for all these years..."
David, again I apologize for attacking your 17 year history as a DBA and
your accomplished certification. I shold have taken a lesson in
phenomenology in stating my case that the SHUTDOWN ABORT command should only
be used in exceptional circumstances and stated only the facts instead of
having a knee-jerk reaction.
The fact being that SHUTDOWN ABORT, as witten in the Oracle manual, should
only be used for exceptional instances and not for a normal shutdown
procedure. The OP may have had problemns with normal shutdown on computer
restart. Perhaps he should research why the agents, etc, prevented a normal
shutdown, correct the anomalies, and be able to use a normal shutdown on
computer restart. Imprementing the aforementiond script brought up in
previous posts for shutting down an instance on computer restart seems like
a kludge, and that a better solution might be to research why a normal
shutdown cannot be performed.
--
Andreas Sheriff
Oracle 9i Certified Professional
Oracle 10g Certified Professional
Oracle 9i Certified PL/SQL Developer
----
"If you don't eat your meat, you cannot have any pudding.
"How can you have any pudding, if you don't eat your meat?"
DO NOT REPLY TO THIS EMAIL
Reply only to the group.
|
|
|
|
|