企业的系统架构正在变迁。以前是一个个单独的小系统，之后当业务变得复杂的时候，企业引入了越来越多的解决方案，为了避免解决方案之间成为信息孤岛，各种作为proxy和集成器的中间件应运而生，系统似乎不是分布式的，都不好意思跟人打招呼。而当企业的信息系统变得更加复杂的时候，似乎应该回归到一个中央访问点的时候了。

从SAP对DB的MCOD（Multiple Components in One Database）的DB layout的支持，到近期三星电子的全球性single instance实施的上线——从此三星将运行世界上最大的单一实例的ERP系统。

也许，底层软件和硬件的支持应该继续分布式，继续云下去，可是构架在此之上的业务软件，应该越不分布越好。否则，系统的维护将慢慢变得不可能。

---------

MCOD at a Glance

Note 651812 - FAQ: BR*TOOLS and SAPDBA

1. What are BR*TOOLS and SAPDBA?

BR*TOOLS and SAPDBA are utility programs for Oracle administration that are developed by SAP. BR*TOOLS are increasingly replacing SAPDBA functions.

2. What BR*TOOLS are available and what do these do?

• BRBACKUP: Database backup

• BRARCHIVE: Backup of offline redo logs

• BRRESTORE: Restoration (restore) of backups (see Note 605062)

• BRRECOVER: Restore/recovery (Notes 602497, 605062)

• BRSPACE: Reorganizations (see Notes 647697 and 541538)

• BRCONNECT: Various administration tasks (see Note 403704) such as creation of statistics (see Note 588668) or database checks

• BRGUI: Graphical user interface for the BR*TOOLS (Note 611493)

• BRTOOLS: Text-based user interface for the BR*TOOLS

3. Where can I find information about Support Packages, installation and compatibility?

Refer to SAP Note 12741.

4. Which releases of the BR*TOOLS and SAPDBA should be used?

We strongly recommend that you only use Version 6.10 or higher. Only these versions are updated on a regular basis.

5. What do I do if one of the BR*TOOLS or SAPDBA results in an error?

If you cannot find a solution in the SAP notes, you should check whether a current patch for the tool still returns the same error. If so, create a customer message under the component BC-DB-ORA-DBA.

6. How can I find out which release and patch level belong to an installed tool?

Call the tool with the " -V" option (for example, "brconnect -V "). The result includes the following lines with release and patch level:

kernel release <release>
patch level <patchlevel>

7. Which operating system and database users should be used with BR*TOOLS and SAPDBA?

• Operating system users:

• • WINDOWS:

With a manual call, <sid>adm should be used for all tools. If you start from DB13, sapservice<sid> is automatically used.

• • UNIX:

All tools can be started as ora<sid>. The tools that can be called from DB13 (BRBACKUP, BRARCHIVE, BRCONNECT) can alternatively be started as <sid>adm.

• Database user:

• • BR*TOOLS:

The OPS$ user is recommended as the database user ("-u /"), because it does not require a password. Alternatively, you can also use the SYSTEM user (including the password).

One exception is the BRCONNECT function " -f chpass", which can only be used with SYSTEM.

Caution: As of BRCONNECT 6. 40 Support Package 25, you can also work with the OPS$ user ("-u /"). As a prerequisite, BRCONNECT must have been started as the OS users <sid>adm or ora<sid>, which allows the "CONNECT / AS SYSDBA" (because it belongs to the "dba" group).

• • SAPDBA (menu function):

You can only use SYSTEM as the database user.

8. Where do I find the parameter files for the BR*TOOLS and SAPDBA?

The following parameter files exist:

• BR*TOOLS: $ORACLE_HOME/dbs/init<sid>.sap

• SAPDBA: $ORACLE_HOME/dbs/init<sid>.dba

9. Where do I find the log files of the BR*TOOLS and SAPDBA?

Depending on the tool you are using, the log files are located in the following directories ($SAPDATA_HOME = /oracle/<sid>):

• $SAPDATA_HOME/sapbackup: BRBACKUP, BRRESTORE, BRRECOVER

• $SAPDATA_HOME/saparch: BRARCHIVE

• $SAPDATA_HOME/sapcheck: BRCONNECT

• $SAPDATA_HOME/sapreorg: BRSPACE
  
  If you want to use a directory other than the standard directories, you must set the SAPBACKUP, SAPARCH, SAPCHECK or SAPREORG environment variables.
  
  Depending on the action you have executed, SAPDBA log files are also stored in one of these directories.

10. How can I delete old log files of the BR*TOOLS and SAPDBA?

You can delete obsolete log files with the BRCONNECT parameter "-f cleanup". By default, logs that are older than 30 days are deleted. If you want to configure a different time interval, you can use a number of cleanup_* parameters. Refer to the BRCONNECT documentation for further details.

11. How do I recognize errors and warnings in the BR*TOOLS log?

The entries in the log files of the BR*TOOLS start with an abbreviation BR[0-9][0-9][0-9][IWE], that is, with the string "BR", followed by three numbers and one of the letters I, W or E (for example, BR051I or BR310E). The final letter indicates whether the entry represents an information message (I), a warning message (W) or an error message (E).

12. How I can adjust the functions of "brconnect -f next"?

"brconnect -f next" checks whether the NEXT size of objects must be adjusted and performs the adjustment if required. In certain cases, it may be advisable to adjust the standard function (for example, to avoid unnecessarily large NEXT sizes or to exclude certain tables from a check).

An upper limit can be defined for the NEXT size (set by BRCONNECT) with the parameter next_max_size in init<sid>.sap. For example, "next_max_size = 1G" limits the maximum NEXT size to 1 gigabyte.

You can use the parameter next_exclude to specify objects that are to be excluded from the check (for example, next_exclude = SAPR3.T000).

See the BRCONNECT documentation for more configuration options.

13. Why does "brconnect -f check" not record a TABLESPACE_FULL even though a tablespace has already exceeded the threshold value?

With AUTOEXTEND files, BRCONNECT also calculates the space that may be available in the file system. A TABLESPACE_FULL warning is only issued with AUTOEXTEND files if the total of the freespace available in the tablespace and within the framework of AUTOEXTEND exceeds the threshold value.

14. Can I use BRBACKUP even if the database can no longer be started?

In some cases (before you import a restore, for example), it may be advisable to save the current status of the database as a precaution, even if you can no longer open the database properly in the current status. Since it is only possible to use BRBACKUP if the database can be opened, you cannot run a backup with this tool. In this case, you must use other tools for a backup or execute a simple file system backup.

15. What do the return codes of the BR*TOOLS mean?

• Return Code 0: Successful execution

• Return Code 1: Execution with warning(s)

• Return Code 2: Termination in the initialization phase

• Return Code 3: Error in the initialization phase

• Return Code 4: Termination in the execution phase

• Return Code 5: Error in the execution phase

• Return Code 6: Abort

• Return Code 9: In execution

These return codes also correspond to the return codes logged in table SDBAH. Only for return codes 6 and 9 a different SDBAH entry exists: 9999. This 9999 may appear constantly if, for example, a BR*TOOL has been terminated because of an error or if an online backup was only recovered BEFORE the SDBAH update at the end of BRBACKUP.

16. Can I also use the BR*TOOLS for SAP systems that do not have SAP ABAP basis?

Yes, refer to Note 12741 for more information.

To use BRBACKUP, BRARCHIVE and BRRESTORE, see Note 320457.

In the case of MDM, see Note 936665.

As of Version 7. 00, an extended support of BRCONNECT is available (Note 892294).

17. Why does BRBACKUP use CPIO even if TAPE_COPY_COMMAND is set to DD?

DD is only used to backup large files, such as the Oracle data files. Smaller files, such as init<sid>.ora, are always copied with CPIO. Therefore, CPIO must always be installed correctly to avoid errors.

18. What is the importance of the "jid" parameter?

The parameter "-jid" is used to transfer a job identifier, which enables the system to map a BR*TOOLS run to an SAP and DB13 job. This prevents some of the problems described in Note 651452. Otherwise, this parameter alters nothing about the execution of BR*TOOLS.

19. Where can I find more information?

Information about using BR*TOOLS and SAPDBA is available in the SAP online documentation.

Additional information about other important topics is available on SAP Service Marketplace under the quick link "dbaora":

http://service.sap.com/dbaora

Note 1028624

Overview of the new DBA Cockpit

The DBA Cockpit replaces different transactions that were used for monitoring and administration up to now. These include the following transactions in particular, which now branch to individual functions in the DBA Cockpit:

DB13 DBA planning calendar
DB13C Central planning calendar
DB12 Backup logs
DB14 DBA operation logs
ST04 Database Performance Analysis: Oracle database overview
DB02 Database Performance: tables and indices

The transactions listed above continue to be available, but the transaction codes were renamed to <previous transaction code>OLD. This means that the transaction codes are now ST04OLD, DB02OLD, DB12OLD, DB13OLD, DB14OLD, and DB13COLD.

You use transaction DBACOCKPIT to call the DBA Cockpit. The DBA Cockpit has a navigation area that is visible in all the functions of the DBA Cockpit. This area contains a menu tree with the following access points:

- Performance (corresponds to the old transaction ST04)
- Space (corresponds to the old transaction DB02)
- Jobs (corresponds to the old transactions DB13, DB12, DB14, DB13C)
- Diagnostics

The individual functions of the DBA Cockpit are located beneath these four access points. You can call a function by clicking it.

Prerequisites for using the DBA Cockpit:

The prerequisites described here are required for monitoring and administration of the local system (that is, the system on which the DBA Cockpit is running).

• Some performance monitors within the DBA Cockpit require special database objects. These objects are created using an SQL script. See Note 706927 for this script and more information.

• *The new planning calendar requires BR*Tools 700 patch level 24 or higher.

• Some functions in the DBA Cockpit require the Oracle Active Workload Repository. This Oracle option must therefore be available for selection (see Note 1028068).

Additional corrections for the DBA Cockpit with Basis 7.00 Support Package 12 which are only corrected in Support Package 13:

• The correction from Note 1042725 (DB02 Refresh terminates in short dump) needs to be implemented.

• The correction from Note 1046668 (DBA Cockpit->Database->Overview causes a dump) needs to be implemented.

• You must import the transport that is attached to Note 1052909 (Transport_for_NW04s_SP12_only.zip). It corrects various small errors in the system administration and planning calendar.

• Implement the corrections from Note 1076147 (Incorrect status display of backups in planning calendar).

• Implement the corrections from Note 1084949 (DBACOCKPIT: Incorrect status display in Central Calendar).

Additional corrections for the DBA Cockpit with Basis 7.00 Support Package 12 and 13 which are only corrected in Support Package 14:

• Implement the corrections from Note 1081265 (DBACOCKPIT: Backup logs are not displayed).

• Implement the corrections from Note 1076507 (DBACOCKPIT SQL error ORA-942 during access to table DBAD).

• Implement the corrections from Note 1076716 (DBACOCKPIT: RFC connection cannot be entered).

• Implement the corrections from Note 1084146 (Planning calendar: Incorrect selection using list box).

• Implement the corrections from Note 1088211 (DBACOCKPIT: Error when editing planned actions).

• Implement the corrections from Note 1100026 (DBACOCKPIT: Short dump DYNP_TOO_MANY_RADIOBUTTONS_ON).

Additional corrections for the DBA Cockpit with Basis 7.00 Support Package 12, 13, and 14 that are only corrected in Support Package 15:

• Implement the corrections from Note 1110280 (DBACOCKPIT: Incorrect number of redo logs that are not saved).

• Implement the corrections from Note 1108971 (DBACOCKPIT: Overview is incorrect in Central Calendar).

• Implement the corrections from Note 1112726 (DBACOCKPIT: Button 'All' in 'DBA Logs' does not display data). This error occurs with Support Package 13 and Support Package 14 but not with Support Package 12.

• Implement the corrections from Note 1113261 (DBA Cockpit: Incorrect display of external jobs in DB13).

• Implement the corrections from Note 1107729 (DBACOCKPIT: Action list in planning calendar is incorrect).

• Implement the corrections from Note 1134253 (DBACOCKPIT: Display error in external BRCONNECT actions).

Additional corrections for DBA Cockpit with Basis 7.00 Support Package 12, 13, 14, and 15 that are corrected only in Support Package 16:

• Implement the corrections from Note 1142791 (Planning calendar: Incorrect status in the daily overview).

• Implement the corrections from Note 1139787 (Planning calendar: Option for profile in "Verify DB" missing).

• Implement the corrections from Note 1164574 (Planning calendar: db_error for action 'Cleanup').

• Implement the corrections from Note 1164986 (DBA Cockpit: Incorrect status of periodically scheduled jobs).

Additional corrections for DBA Cockpit with Basis 7.00 Support Package 12, 13, 14, 15 and 16 that are corrected only in Support Package 17:

• Implement the corrections from Note 1166977 (DBACOCKPIT: Display error for backups with redo log).

Further corrections that you may have to implement in remote systems (ABAP) that are connected to the DBA Cockpit:

• Implement the corrections from Note 1088975 (Short dump COMPUTE_INT_ZERODEVIDE in DB13).

• Implement the corrections from Note 1077188 (DBACOCKPIT: RFC for remote systems cannot be configured).

• Implement the correction from Note 1093883 (ORACLE: Function module DB6_PLAN_ADD_BATCH failed) in remote systems with Basis Release 640 if you want to use the planning calendar in the DBA Cockpit for these systems.

New planning calendar

(Transaction DB13 or Jobs -> DBA Planning Calendar in the DBA Cockpit menu tree)

The planning calendar previously used was replaced with the new calendar to meet legal requirements regarding the accessibility of screen programs.

The previously used planning calendar is still available in transaction DB13OLD. Completed actions are visible in both the old and new planning calendars. Actions that were scheduled in the old planning calendar also appear as scheduled in the new calendar. The reverse also applies: Actions that you have scheduled in the new planning calendar are also visible in the old calendar. However, there is one exception:

Periodically scheduled actions in the new planning calendar with a repetition period other than weekly (for example, hourly or daily) are not displayed in the old planning calendar.

This can lead to problems if the old and new planning calendar are used in parallel. We therefore advise against using both planning calendars at the same time.

Even if the old calendar is still usable, it now has the status "deprecated". For this reason, we recommend that you switch to the new calendar in the medium term, provided that you do not need to use it right away.

For more information about the new planning calendar, especially about the configuration and administration of external databases, see Note 1025707 and the documentation.

New central planning calendar

(Transaction DB13C or Jobs -> Central Calendar in the DBA Cockpit menu tree)

The new central planning calendar differs from the old planning calendar by having a different configuration for systems that are to be monitored. The old planning calendar is still available under transaction DB13COLD. The new central planning calendar uses the system configuration of the DBA Cockpit to add or remove systems.

To migrate the systems of the old central planning calendar to the new planning calendar, choose Administration -> Migration DB13C Configuration in the new central planning calendar.

New transaction DB02 (Space)
(Transaction DB02 -> Space in the DBA Cockpit menu tree)

Refer to Note 868063 and also to Note 1002840 if required.

Administration and monitoring of external databases

A feature of the DBA Cockpit is that you can monitor and administer external databases. This applies to both ABAP and non-ABAP systems.

Oracle databases and all other database systems supported by SAP can be connected as external databases. If you want to connect non-Oracle databases, the relevant database client software and the SAP database shared library must be installed.
(In this note, we assume that the system on which the DBA Cockpit is running is an Oracle database system. If this is not the case, but you intend to connect external Oracle databases, you must first install the Oracle database client software and the corresponding SAP database shared library.)

External Oracle databases are only supported as of Version 9.2.

If you need to connect external Unicode databases, the system on which the DBA Cockpit is running must be a Unicode system.

The connection of external databases requires a working secondary database connection; that is, there must be an entry in the DBCON table. When you add an external database in the system configuration of the DBA Cockpit, you can create a DBCON entry directly. The database user who is to be entered for the database connection must be the relevant schema owner, in other words, SAPR3, SAP<SID>, SAPSR3 or SAPDB<SID>. In MCOD systems, you must choose the database user who is the owner of the tables SDBAH and SDBAD.

Before you connect an external Oracle database, the following requirements must be met:

1. The script from Note 706927 must be executed on the external Oracle database.

2. For the planning calendar (DB13) and the related transactions DB12 and DB14, you also need to configure either an RFC ABAP connection (only allowed for external ABAP systems) or a connection through SAP gateway or a remote shell. For more information, see Note 1025707.

3. In addition, at least BR*Tools 700 patch level 24 (Oracle client 10) or BR*Tools 640 patch level 42 (Oracle client 9) must be installed on the external system.

4. You should ensure the system time does not differentiate between the remote system and the system, on which the DBA cockpit runs. The deviation must not be longer that 60 seconds under any circumstance.