10 SAP Administration Best Practices and Tidbits

Embed Size (px)

DESCRIPTION

10 SAP Administration Best Practices

Citation preview

10 SAP Administration Best Practices and Tidbits

10 SAP Administration Best Practices and Tidbits

Kehinde Eseyin(Systems Support Manager)posted2/17/2009 | Comments(0)

The SAP system is a complex system and by implication its administration can be challenging especially in large deployments. In this post, I present a number of best practices and tidbits that are invaluable to SAP system administrators and which goes a long way to simplify SAP system administrative tasks irrespective of the complexity or size of the implementation.

1. Documentation: Proper documentation simplifies administrative tasks. How to achieve a task should be well documented. This should include the various steps to be taken and the correct sequence. There is always a tendency to forget a very important step when performing routine administrative task. Think about overwriting a file without making a backup and you now need to restore back to a point before the overwriting. No matter how minute a task is, it is important to have it documented. By so doing, it can be picked up by any trained personnel when you are unavailable and the task can be done with little or no hassle.

2. Professional/Peer Networking: As an SAP administrator, you need to belong to fora where technical SAP issues are discussed. It broadens your technical horizon and expands your skill sets. Through such fora, you can make friends with whom you can discuss challenges on the job with and probably get solutions without necessarily re-inventing the wheels. This is because such individuals might have experienced such issues before. Attending SAP technical summits and conferences such as SAPTECHED is also helpful. SAP Users Group (*SUG) exist in some localization; it is beneficial to belong to such groups.

3. Safeguard the SAP System: The SAP system, been an enterprise system houses the company wide data in most cases, hence the need to properly safeguard the system. Direct access to the database should be highly prohibited and necessary controls must be in place to guide against this. Network security must be very effective. Remote connection to the SAP system must also be well controlled and access granted only when the need arises. Administration of the SAP system must be centralized. Suffice to say that the SAP administration team must be abreast of any work on the SAP system at any point in time.

4. Checklists: Because the administrative tasks that need to be performed on the SAP system are enormous, it is best to have a checklist of these activities. The checklist guides you at ensuring that all defined activities are performed and any observation can be noted and addressed in due course. By this, you are unlikely to forget any activity by omission. You can develop checklists for daily, weekly, monthly, quarterly and annual administrative tasks.

5. Maintenance: The SAP environment is characterized by different application which includes operating system, database system and enterprise system and third party application. These applications are continuously improved and enhanced via upgrades, patches, service packs and hot fixes. It is best for SAP administrator to apply these enhancements when they are released. Furthermore, the SAP system runs on high end infrastructures such as servers and network equipments. These facilities needs to be maintained based on defined schedule. Performing the preventive maintenance of these equipment as at when due is key to ensuring that service is not disrupted as result of equipments break down.

6. Disaster Recovery Plan: The disaster recovery plan is a set of activities that will be carried out to restore service in the event of a disaster of any kind which can mean physical inaccessibility to the server room which is the primary site. A disaster recovery plan must be well documented and all users must be abreast of what to do in case of a disaster. The plan must be tested at defined intervals to ensure that the plan is still relevant to the business case that justifies its existence.

7. Incident Management: When user encounters problems with the system, experience has shown that the system administrators are the first point of call. In an SAP environment, an incident management system should exist to monitor user complaints and problem resolution or status at any point in time. This complaint might be as mild as resetting users password. With an incident management system in place, service calls can be well managed and progress monitored.

8. SAP System Isolation: Despite the fact that SAP system is an enterprise application that is supposed to integrate all business units of an organization, companies still have one reason or the other to run non SAP systems. In some cases, these non SAP systems are integrated with the SAP system. However, it is best to isolate the SAP system from non SAP system. The SAP application should be installed on a separate server different from other applications. This simplifies administration and makes troubleshooting less difficult. Even the network infrastructure should be isolated if possible. The SAP system can exist in a separate VLAN different from other systems.

9. Controlled Modification: The SAP administrator should not just make changes to the SAP system without fully understanding the implication of such action. This also applies to making changes to system parameter settings. There should be proper justification for making changes to the system state.

10. Knowledge Database: It is good practice to keep a database of known issues and solutions. Because the challenges of administering the SAP system are multi facet, it is very possible to forget how a problem was resolved when it occurred. A knowledge database exists to serve as a reference data center when a familiar problem re-occurs. Furthermore, the knowledge database should be centrally managed. It enhances collaboration especially as it relates to issues and corresponding solution documentation.

SAP Backup Cycle in an Oracle Database Environment

Kehinde Eseyin(Systems Support Manager)posted2/18/2009 | Comments(0)

Just like in other systems, it is important to have a backup strategy in place. The SAP environment is not an exception. Backup as it were helps to guide against data loss. When developing a backup strategy, it is important to keep it as simple as possible. A number of parameters are considered when developing a backup strategy. These include the size of the database, backup media, frequency of backup, number of copies of backup, backup policy and backup cycle among others.

In this post, Id be taking a closer look at backup cycle in the context of the SAP system. Emphasis will be on the connection of backup cycle with SAP recommended backup methods and strategies in an Oracle environment.

The Backup cycle can be defined as the window within which you can keep backup on tape. During this period, the tape is not overwritten. Suffice to say that the backup cycle defines the tape retention period. Until the retention period elapses, these tapes cannot be reused. The recommended backup cycle in an SAP system is 28 days.

Performing a complete online and offline backup is very pertinent. A complete backup backs up all data in the database. It is recommended that you carry out a complete offline backup once in a backup cycle. A direct relationship exists between the length of the backup cycle and the frequency of complete database backup. Typically, a large number of complete database backup tapes must be available and useable at any point in time in order to guide against data loss especially when the last database backup is not useable.

Tape pool provides capabilities to manage tape allocation based on backup policies, backup types, backup strategies and backup tools among others. The concept of tape pool is essential in the management of backup cycle. At any point in time, sufficient tapes must be available in each tape pool in order to cater for the entire backup cycle. This is because the backup tape for each pool cannot be reused until the retention period is over, hence the need to have sufficient number of tapes in a pool.

Following a full backup, it is possible to backup only data blocks that have changed since the last full backup, this is called incremental backup. An obvious feature of incremental backup is that there is reduction in the amount of data to be backed up, however, all data blocks are read. The downside of an incremental backup is that it is not useable if the associated full backup is no longer available or has been overwritten. When using incremental backup, it is recommended to perform at least one full backup per week and four full backup per backup cycle.

In a situation where you use tape stations with hardware compression and you want RMAN to consider a compression rate when creating save sets with appropriate sizes to match the tape size, you need to carry out a preparation run. Also, a preparation run is performed when a RMAN based backup is intended to form save sets with more than one member. File assignment to save sets cannot be managed manually; it can only be changed by carrying out a new preparation run. It is recommended to perform a preparation run once per backup cycle.

When using BRBACKUP, it is possible to calculate the space needed to store compressed files on tape using appropriate compression rates. You need to use an accurate compression rate of the database files before the backup tool can determine the quantity of data to be stored on one tape after compression. Furthermore, it guarantees that the specified tape size is not exceeded and ensures that there is proper distribution of files across the tapes. Compression rates should be updated at least once per backup cycle.

In order to recover from failure completely and when using BR*Tools for backup operations, it might be necessary to have a comprehensive backup of all files, both SAP and non SAP files at any point in time. Although, in most environments, these file are backed up at operating system level, it is good idea to back them up at least once per backup cycle. The affected files include but not limited to operating system, SAP executable, SAP interface, SAP archiving and Oracle software directories.

Overview of SAP Administration Tools in an Oracle Database Environment

Kehinde Eseyin(Systems Support Manager)posted2/18/2009 | Comments(0)

Oracle is one of the preferred databases on which the SAP system sits. SAP has some standard programs to simplify database administration. These include BRBACKUP, BRARCHIVE, BRRESTORE, BRRECOVER, BRSPACE, BRCONNECT, BRGUI and BRTOOLS.

BRBACKUP is used to perform the backup of data files, control files and online redo log files.

BRARCHIVE is used to perform the backup of offline redo log files.

BRRESTORE is used to perform the restoration of files backed up by BRBACKUP and BRARCHIVE. These includes data files, control files, online redo log files and offline redo log files.

BRRECOVER is used to perform database restore and recovery.

BRSPACE is used to manage instances, space and reorganization.

BRCONNECT is used to perform certain administrative tasks such as updating statistics, changing passwords and performing database checks.

BRGUI is a GUI environment for BRTOOLS.

BRTOOLS is an interactive interface that displays menu from which BR*TOOLS programs are called.

In subsequent posting, I intend to explicitly discuss these individual tools.