R3trans check finished with return code: 12

This message appears when you failed to starsap:

Detail can be found in startdb.log:

/usr/lib/hpux64/dld.so: Unable to find library 'libodm9.so'.
ERROR:ORA-12547: TNS:lost contact

/usr/lib/hpux64/dld.so: Unable to find library 'libodm9.so'.
/usr/lib/hpux64/dld.so: Unable to find library 'libodm9.so'.
ORA-12547: TNS:lost contact
------------------------------ Wed Aug 22 05:56:03 METDST 2007Connect to the database to verify, that the database is now open
R3trans check finished with return code: 12
*** ERROR: Startup of database failed
Notify Database Administrator.

/usr/sap/FS3/SYS/exe/run/startdb: Terminating with error code 12

Solution:
Relink the file /oracle/FS3/920_64/lib/libodm9.so -> libodmd9.so

Application Link Enabling (ALE)

ALE is a middleware that able for SAP to connect to other SAP/Non SAP system. Data is exchanged between applicaitons and remains consistent in all applications.

Application systems are loosely coupled in an ALE integrated system. Data is exchanged asynchronously, whereby the data arrives in the receiver system, even if the receiver system cannot be connected to at the time the data is sent. ALE uses synchronous communication for reading data only.

Applications are integrated using a local database rather than a central one. There is no data retention. ALE guarantees the distribution and synchronization of master data, Customizing data and transaction data through asynchronous communication.

Synchronous communication is used in ALE to read data only.

ALE Benefits:

• Application data can be distributed between different releases of R/3 Systems
• Data can continue to be exchanged after a release upgrade without requiring special maintenance
• Customers can add their own enhancements
• Communication interfaces enable connections to non-SAP systems.
• R/3 and R/2 Systems can communicate with each other.

ALE has functions for monitoring messages flows and handling communication problems.

Implementation Considerations:
Things to be thought thru during implementation:

• Determining functions and processes
• Specifying global settings
• Modeling company structure
• Modeling control data and master data

Data across particpating system need to be uniform in term of definition. For connecting to non sap system, it is acheived with the help of external converter (ALE converter).

ALE Process

Messsage distribution is based on IDoc. In the outbound system an IDoc containing the data to be transferred is created and prepared for dispatch in the outbound system.

Then the IDoc is transferred to the target system.

In the target system the IDoc starts inbound processing. The data is processed and then posted in the application either fully automatically or part manually. Inbound and outbound IDocs can be processed individually or in a packet. In mass processing several IDocs are processed together in one packet.

System Landscape Directory (SLD) - 101

Anchronym for it is SLD. It is a central information system for SAP landscape. But it also can be use for non-sap system.

SLD contains two type of information:

• Component information - what can be installed
• Landscape description - what is installed

SAP recommends that you only use one SLD.
If you have more the one SLD instance, you must ensure that all content is synchronized by using the export & import function, which is describe in SAP note - 764393.

There are several style of SLD implementation. Please view the planning guide on (BC-NETWEAVER-SLD folder)

More information
- help.sap.com
- service marketplace

Answer from Forum (ittoolbox)
Great question!! The way I explain the SLD is that it is like an LDAP for your systems. It is a directory that contains all the information on your landscape from a technical, business, and software component level. It kind of uses a publish and subscribe model where the SLD is made aware of new systems in the landscape, publishes this infomation for other subscribing systems to use.

For example, lets say I want to use solution mananger to monitor all of my systems in my landscape. It would use the information stored in the SLD to "discover" these systems and to connect. XI also uses the SLD for all of its message routing As a Basis person, you will most likely be working with SM, Portal, JDI, mabye even MDM (Master Data Management). All of these use the SLD in their own way.

As a Basis person you become the administrator of the SLD as well (in most cases). If you have portal developers that are writing Web Dynpros that require a JCO connection -- you would be the person to setup that in the SLD so they wouldn't have to hard code the connection string into their programs.

Oracle Alert and Trace files

Here is the reference where you can find oracle alert and trace files information. This two files is a good starting point for troubleshooting:

Alert file
The alert.log file contains a record of all significant database events and messages, including:

• all instance startups and shutdowns
• messages to the operator console
• errors that cause trace files to be written.
• CREATE, ALTER and DROP operations on a database, tablespace or rollback segment.

The alert.log file is continuously appended to, so it will grow large fast. You should consider backing it up to tape and routinely deleting it. It is a normal text file, and it may be deleted even when the database is up and running.

The path for SAP is /oracle/saptrace/background

Trace File
The Oracle background processes (LGWR, DBWR, PMON, SMON etc) create special debugging files called 'trace files' when Oracle encounters an exception condition. A trace file contains:

• a call stack trace.
• dumps of SGA, PGA, and supervisor stacks.

The default path is in $ORACLE_HOME/rdbms/log

You may change the location of these files by setting the following parameter in the init.ora: BACKGROUND_DUMP_DEST. To find out what BACKGROUND_DUMP_DEST is set to, do the following:

% sqldba mode=line;
SQLDBA> connect internal;
SQLDBA> show parameter user_dump_dest;

or check in the init.ora