SAP Backup/Recovery Planning...

SAP Backup/Recovery Planning

In order to protect your SAP systems, it is recommended that full and transactional backups be created regularly and kept separate from the system hardware, preferably in a remote location.

Full Backups
A full backup contains the entirety of the database at a given point in time. In the event of a hardware failure or data corruption, it is necessary to have a full backup of the database to restore. The main benefit of having a full backup available for restore is obvious: your company does not have to lose critical business data in the event of a failure. It is recommended that a full backup be taken at least once daily.

Transactional Backups
Full backups alone are not sufficient for most businesses. If a failure occurs just before or during a full backup, then data created or altered since the prior backup will be lost. Transactional backups are designed to save the changes made to a database after full backups are taken, that way those changes are protected. If your backups are setup to run daily at 12:00 AM, and you have transactional backups every hour, then if a failure occurs at 11:59 PM, you potentially would only lose 59 minutes worth of productive changes. Depending on your business requirements, transactional backups can be taken as frequently as you need. It is recommended that transactional backups be taken every 15 minutes for a production system.

Multiple Points of Failure
Taking full and transactional backups, however, does not mean that your data is sufficiently protected. If your backups are stored on the same physical device that houses the database, they can be subject to the same hardware failure that can corrupt or destroy the database. If your backups are on the same array as the data, and the array is lost, then you have lost both your live data and your backups, making your data unrecoverable. If your backups are on a different array, but still attached to the same server as the database, a server loss will potentially make your system unrecoverable. This is where the concept of multiple points of failure comes into play. You do not want any single event to be able to make your SAP system unrecoverable. The ideal scenario is for your database backups (both full and transactional) to be written to tape and taken to a secure remote location so that the live data and the backups are less likely to be destroyed in a single event, like a power surge or even acts of nature such as a flood or tornado.

Recovery Planning
No matter how extensive your backup scenario is, it is useless if there is not a recovery plan in place. Your company needs to have a recovery plan in place and periodic recovery tests need to be performed so that documentation is kept updated and the validity of the backup/recovery scenario is verified. It is recommended that recovery scenarios be tested and updated at least once annually.

Hope this helps...

SAP Java ConfigTool...

Since most of you know my experience with Java is very limited, it shouldn't surprise you that I was just recently introduced to the Java ConfigTool for SAP.
A client was having issues with some of the Java process dropping off while SAP was running, so I opened a customer message for them.
The solution was to change the Global Server Config -> Managers-> ClusterManager-> ms.confirmation.timeout parameter inside the ConfigTool.
The ConfigTool can be found here:
usr\sap\\\j2ee\configtool\configtool.bat

Hope this helps.

SAPGUI Logon Screen Message...

You want to display a customer-specific text on the SAPGui logon screen?

Go to Transaction SE61and select the document class General Text (selection using F4 help), and create a text with the name ZLOGIN_SCREEN_INFO in the system language determined with the profile parameter zcsa/system_language. If the text does not exist in the system language, no output is made. Note that there is space on the logon screen for 16 lines for every 45 fixed-font characters or for approximately 60 proportional font characters. Title lines (can be recognized by format keys starting with a 'U') are highlighted in the display. You may also output icons at the beginning of lines by using an icon code (for example, @1D@ for the STOP icon). You can get a list of icon codes from Report RSTXICON. Pay attention to the codes with two '@' symbols displayed by the report. You cannot include text symbols. The function 'include character' cannot be used.
Creating/changing this text requires a changeable system. Therefore, for production systems, SAP recommends maintaining the text in the upstream system and then transporting it. To do this, select a transportable (customer) development class when you create the text and save the active version prior to the export.The transport is done via the transport object R3TR DOCT ZLOGIN_SCREEN_INFO The text can be changed in the original system only (see TADIR entry R3TR DOCT ZLOGIN_SCREEN_INFO). When making a change in a non-original system, a modified text would be generated which cannot be represented sensefully on the initial screen.

Try this example text on for size:

Client 100: Development/Customizing
Client 200: Unit Test
Client 900: Sandbox

@1A@ Warning.
You are about to logon to the Development System for
COMPANY NAME

Unauthorized Access is Prohibited.

If you encounter any problems, please
contact your System Administrator.