Topic:
Database reconnect on a standby database instance specified via profile parameters on an ORACLE parallel server database system.
New development in 2.2F and 3.0A
Contents
--------
- Explanation of the database reconnect
- Database reconnect for Oracle parallel server
- R/3 Profil Parameter
Explanation of the database reconnects
--------------------------------------
The database reconnect function, by which a work process continues and is not restarted, is explained in Note 98051. This function must be activated as described in Note 98051 so that the database reconnect on a standby instance for an ORACLE parallel server is possible.
Database reconnect for ORACLE parallel server
---------------------------------------------
In an ORACLE parallel server system, database instances can be installed on different servers, but with the data physically accessible to all of them. Furthermore, we assume the following R/3 Oracle parallel server configuration which can be used as a fail-safe database service:
- Server A: Primary database server with database instance A
- Server B: Standby database server with database instance B
- Server C, D, E ... : R/3 application servers
Servers A and B are in a cluster with shared disks on which the database files are located. The work processes from the R/3 application servers connect to the database on system start via database instance A on the primary database server. If the work processes connect via more than one instance to the database, there would soon be a considerable performance loss (with the exception of MPP systems). The database instance B on the standby database server B can be defined in the profiles of the application servers via parameter settings described in the section "R/3 Profil Parameter".
If the standby database server B is defined, the database reconnect tests after an database error of the class RECONNECT (see note 98051) whether the database instance A on the Primary database server can be reached. If this is the case, the work process which received the error return code reconnects itself to the Primary database server. Otherwise, an automatic reconnect to the standby database instance B on the database server B is carried out. In addition, the other work processes are informed about this "Connect-Switch" so that all work processes reconnect to database instance B.
As of Release 2.2G and 3.0B, it is possible that a primary database server is redefined as a new standby database server. This parameter defines a failed primary database server as the new "standby database server". If the additional parameter is set, an automatic database reconnect is attempted again to the old primary database instance after a database reconnect of the work processes to a standby database instance if a database reconnect to the standby database instance was not successful. This is called "symmetric database reconnect for OPS" below. The corresponding parameters are described in the section "R/3 Profil Parameter".
R/3 Profile parameters
----------------------
rsdb/oracle_sid: SID of the primary database instance
for example: rsdb/oracle_sid =C11
rsdb/oracle_host: Host name of the primary data base server
for example: rsdb/oracle_host =hs0001
(Valid up to and including
Release 3.1G and 4.0A)
SAPDBHOST: Host name of the primary database server
for example: rsdb/oracle_host =hs0001
(replaces deb parameter rsdb/oracle_host;
as of Releases 3.1H and 4.0B)
rsdb/oracle_sid_standby: SID of the standby database instance
for example: rsdb/oracle_sid_standby
=C11_002
rsdb/oracle_host_standby: Hostname of the standby database server
for example: rsdb/oracle_host_standby
=hs0002
The following parameters do not have to be set, there is no default value that can be changed. More detailed information and settings can be taken from the parameter descriptions.
rsdb/oracle_home_standby: Home directory of the standby database
instance. The parameter must only be set if
there is also an application server running
on the standby database server.
For ex.: rsdb/oracle_home_standby
=/oracle/C11
dbs/ora/tnsname_standby: Service Name for the Connect to the standby
Database instance. The parameter must be set
if the connect to the database is carried out
by SQL*NET V2.
For exampel: dbs/ora/tnsname_standby =C11_002
rsdb/reco_symmetric: Activates the "Symmetrical DB reconnect for
OPS". There is no default for the parameter.
It must be set in every R/3 instance profile
of an application server where the
"Symmetrical DB reconnect for OPS" should be
activated. The parameter can be set from
Release 2.2G and 3.0B.
For example: rsdb/reco_symmetric =ON
rsdb/reco_sync_all_server:Notify all application servers in the system
if a reconnect to the standby database server
is required.
The parameter should only be set if all of
the application servers in a system connect
to one database server.
Up to and including 3.0E, the parameters must
be set in every instance profile; from 3.0F
there is a default - it is then sufficient to
enter it once in DEFAULT.PFL.
The parameter can be set from 2.2H and 3.0C
For example: rsdb/reco_sync_all_server =ON
rsdb/reco_ping_cmd: Activates a "Ping test" to the database
servers when a database error occurs. The
results of this test help to decide whether
a reconnect to the standby database server
should be attempted. The "Ping test" is
available from Releases 2.2H or 3.0D (on NT,
it is only available from Release 3.0E).
If necessary, the default can be changed and
is platform dependent. The character string
"hostname" must appear in the parameter and
in each case, it is substituted by the
actual hostname of the database server in
question.
For example: rsdb/reco_ping_cmd=ping -s
hostname 64 2
rsdb/reco_tcp_service: Activates a "TCP connect test" to the
database servers if a database error occurs.
The results of this test help to decide
whether a reconnect to the standby database
server should be attempted. The "TCP connect
test" is available from Release 3.0E and is
activated from Release 3.0F via a default for
rsdb/reco_tcp_service.
A standard service should be selected for the
parameter, that is available on the database
servers.
For example: rsdb/reco_tcp_service =login
rsdb/reco_tcp_timeout: Controls the default timout of 10000
milliseconds for the TCP connect test. There
is no default for the parameter. Generally,
you should not need to set this parameter. If
it is set, this must be done in all of the
instance profiles.
For example: rsdb/reco_tcp_timeout =20000
Additional key words
OPS (Oracle Parallel Server)
No comments:
Post a Comment