Do as much as you can through the SAP GUI and provided SAP Transactions.
Try to make Oracle level changes only when absolutely necessary.
This will ensure that your Oracle and SAP data dictionaries are kept in sync.
Some of the SAP admin programs:
BRBACKUP (backup the database)
BRARCHIVE (backup off-line redo logs)
BRRESTORE (restoring the database and the redo logs)
SAPDBA (database administration. Eg: database startup and shutdown,
space analysis, tablespace extensions, monitoring, reorganization,
database recovery)
Passwords for SYS/CHANGE_ON_INSTALL, SYSTEM/MANAGER, and SAPR3/SAP
should be changed for security reasons.
The easiest way to change them is using the R3INST program.
The only negative consequence when SYSTEM's password is changed is that
sapdba will request a password to perform most actions.
You can use command 'sapdba -sapr3 ' to change the SAPR3 user
password. This also updates the SAPUSER table entry. There is also a command
'sapdba -alter_user /' to change other Oracle user passwords.
SAP/R3 ships complete with all tables needed for all modules. Whether or not
the modules are being used determines whether certain tables will grow or not.
By modules, we mean applications - SD (Sales and Distribution), MM
(Material Management), HR (Human Resources), FI (Financials), etc. All of these
tables are initially created with 16K initial extent, 16K next extent.
The growth of 50GB a month shows that your site is probably using a lot of the
modules (as one would expect with a properly used ERP app) or that there are
many users with a lot of volume for a handful of modules.
Using the SAP transaction DB02, one can watch the growth of extents and
tablespace allocations.
