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).