Re: SAP/Oracle

  • From: Jared Still <jkstill@xxxxxxxxx>
  • To: jo_holvoet@xxxxxxxx
  • Date: Fri, 10 Dec 2004 18:20:14 +0000

On Fri, 10 Dec 2004 11:55:31 +0100, jo_holvoet@xxxxxxxx
<jo_holvoet@xxxxxxxx> wrote:
> And get used to the following :
> * SAP will try its darndest to keep you out of the database except through
> their tools (such as sapdba) which introduce interesting new bugs

Just say 'NO'.  These tools are good for what they were designed for:
Allowing SAP Basis Admins to do DBA tasks when they are not really
comfortable with many DBA tasks.

For an experienced DBA they are a large PITA, at least SAPDBA is.

The backup tools aren't bad, though we do not use the recovery tools.

We will be converting to RMAN on our SAP databases and give brbackup
the ole heave ho.

Something else to watch out for are their 'Early Watch' reports.  Those
for the database are designed to help you 'optimize' your database.

Here is a sampling of some 'recommendation' they sent to our SAP team
2 years ago.


Order of Redo Log Files
Using the Oracle views v$log and v$logfiles, we found the name and the
order of the redo log files as listed in the following table. Please
note that the files are ordered by the "sequence number" as found in
v$log. This is because the sequence number indicates the actual order
in which the redo log files are used and NOT the group number.

GROUP#  SEQUENCE#       File Name
7       54177   I:\ORACLE\PRD\ORIGLOGB\LOG\LOG_G07_M02.DBF
7       54177   K:\ORACLE\PRD\ORIGLOGA\LOG\LOG_G07_M01.DBF
5       54178   I:\ORACLE\PRD\ORIGLOGA\LOG\LOG_G05_M01.DBF
5       54178   J:\ORACLE\PRD\ORIGLOGB\LOG\LOG_G05_M02.DBF
6       54179   K:\ORACLE\PRD\ORIGLOGB\LOG\LOG_G06_M02.DBF
6       54179   J:\ORACLE\PRD\ORIGLOGA\LOG\LOG_G06_M01.DBF
To avoid contention, it is recommended to locate the redo log files on
different disks such that two succesive redo log files are NOT located
on the same disk. In this way, there is no competition between the
"write" requests of the logwriter and the "read" requests of the
archive process.

My response to that one - "They should have waited for another log switch".  
Their contention argument?  Yeah, I fixed that.  


Of course there was a recommendation to reorganize the entire database, as there
were 'too many extents' in many of the tables.

SAP is *very* big on re-organizing databases.  There are extensive utilities
from SAP just for reorgs.



The moral is: you must carefully examine any advices SAP offers on 
'improving' database performance.

Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist

Other related posts: