Thanks Dennis,
Yeah, I know how to do the work without the tool, using sqlplus. That's not the
problem. Management won't even allow us to use OEM for maintenance tasks, only
sapdba. My hands are tied, at least for the moment.
Russ
-----Original Message-----
Sent: Wednesday, August 21, 2002 11:39 AM
To: Multiple recipients of list ORACLE-L
Russ - A couple of ideas for you.
1. Check directly in Oracle before you perform a task with the tool. And
check afterward to verify what the tool did. This will make you a better
DBA. And in a future job interview, you'll have a more interesting
conversation than just saying "duh the only way I know to work with Oracle
is to use this tool."
2. Make a list of incidents where the tool messed things up or didn't use
the best method. Management is often impressed with detailed, documented
facts. It can also open a dialogue with the SAP tool developers. Often those
people want good feedback since they are developers, not production DBAs
(years ago I held that job at a different ERP vendor).
3. Keep in mind that you face the same issues in using any tool, even if
it is Oracle's OEM, which management at some sites mandate their DBAs use.
Sometimes more efficient, but you are one degree removed from Oracle.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Wednesday, August 21, 2002 8:03 AM
To: Multiple recipients of list ORACLE-L
I fully agree. Unfortunately management insists on it.
Russ
-----Original Message-----
Sent: Tuesday, August 20, 2002 9:13 PM
To: Multiple recipients of list ORACLE-L
Dick,
There is absolutely *nothing* that SAPDBA does that a reasonably
knowledgeable DBA can't do from his of her favorite toolset.
( vi, Perl and sqlplus for me :)
SAP types have it drummed into their heads that the only proper
way to do anything DBA work is via SAPDBA.
I refuse to use it, and it just drives the SAP consultants crazy.
There are many cases where a good DBA can do a much better
job than SAPDBA. The tablespace reorganization is a good
example. Trying to 'drop tablespace including contents' with
3500 tables is not a terribly bright way of going about it.
Jared
[EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
08/20/2002 02:43 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc:
Subject: Re:drop tablespace including contents
Russ,
Your high usage of RBS was due to the updates being done to the system
data
dictionary. Since you were dropping a tablespace and contents the DDL
statements for the individual objects (tables and indexes) needs to be
done
first, but I've a funny idea from practice that Oracle does not do an
implicit
commit in this case but instead holds on till the end. This makes
dropping a
tablespace with the "including contents" caviot very nasty. Thank GOD we
never
implemented SAP over here. I've heard nothing but bad about SAP and
sapdba.
Dick Goulet
____________________Reply Separator____________________
Author: "Brooks; Russ" <[EMAIL PROTECTED]>
Date: 8/20/2002 11:13 AM
Hi,
This past weekend we experienced a problem on a production database, and I
would
like to try to determine what went wrong, how to avoid it in the future,
and any
better ways of dealing with it should it be encountered again.
After moving some large objects out of tablespace to spread I/O, we wanted
to
reorganize the old tablespace to remove some fragmentation. The tool we
were
using, sapdba, does not readily permit you to drop the individual tables
between
the export and the drop tablespace including contents. Since the
tablespace had
over 3500 tables the drop tablespace was expected to take a long time. We
also
defined a large rollback segment for use this weekend, although with only
maxextents of 100. When Oracle tried to allocate the 101 extent in the
RBS,
error messages were issued and things came to a grinding halt. sar
indicated
disk I/O to the new RBS, but not to any of the datafiles. We waited
several
hours, but the situation did not appear to change.
Shutdown immediate did not work. We could alter the datafiles back online,
but
not the tablespace. Since it was production, the decision was made to
restore to
a recent backup.
1. Was the rollback activity due solely to storing and restoring DDL for
the
tables and indices?
2. Once the RBS was unable to extend, was the drop tablespace including
contents
dead? We tried to alter maxextents on the RBS, but did not get a response
from
the system. Was that the appropriate reaction to this problem.
3. A join of v$session and v$sql did not indicate any active SQL. How
should we
have monitored the progress of what we assume was rollback activity? Any
way
to estimate how much or how long the rollback would take?
4. If the database were shutdown during the rollback I assume the rollback
would
recommence when Oracle came back up. Would it start where it left off or
start
from scratch. It was my impression that it is marking the header blocks
as it
goes, but I would like to check.
Thanks,
Russ Brooks
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV>Hi, <BR>This past weekend we experienced a problem on a production
database, and I would like to try to determine what went wrong, how to
avoid it
in the future, and any better ways of dealing with it should it be
encountered
again. <BR>After moving some large objects out of tablespace to spread
I/O, we
wanted to reorganize the old tablespace to remove some fragmentation. The
tool
we were using, sapdba, does not readily permit you to drop the individual
tables
between the export and the drop tablespace including contents. Since the
tablespace had over 3500 tables the drop tablespace was expected to take a
long
time. We also defined a large rollback segment for use this weekend,
although
with only maxextents of 100. When Oracle tried to allocate the 101 extent
in the
RBS, error messages were issued and things came to a grinding halt. sar
indicated disk I/O to the new RBS, but not to any of the datafiles. We
waited
several hours, but the situation did not appear to change. <BR>Shutdown
immediate did not work. We could alter the datafiles back online, but not
the
tablespace. Since it was production, the decision was made to restore to a
recent backup. <BR>1. Was the rollback activity due solely to storing and
restoring DDL for the tables and indices? <BR>2. Once the RBS was unable
to
extend, was the drop tablespace including contents dead? We tried to alter
maxextents on the RBS, but did not get a response from the system. Was
that the
appropriate reaction to this problem. <BR>3. A join of v$session and v$sql
did
not indicate any active SQL. How should we have monitored the progress of
what
we assume was rollback activity? <SPAN
class=926510418-20082002> Any
way to estimate how much or how long the rollback would take?</SPAN></DIV>
<DIV><SPAN class=926510418-20082002></SPAN><SPAN
class=926510418-20082002></SPAN>4<SPAN class=926510418-20082002>. If the
database were shutdown during the rollback I assume the rollback would
recommence when Oracle came back up. Would it start where it left
off or
start from scratch. It was my impression that it is marking the
header
blocks as it goes, but I would like to check.</SPAN><BR><BR>Thanks,
<BR>Russ
Brooks </DIV></BODY></HTML>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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.com
--
Author: Brooks, Russ
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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.com
--
Author: Brooks, Russ
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (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).
