HADR and C Storred Prcedures

[Mark A]

I found this in the doc:

"HADR does not replicate stored procedure and UDF object and library files.
You must create the files on identical paths on both the primary and standby
databases. If the standby database cannot find the referenced object or
library file, the stored procedure or UDF invocation will fail on the
standby database."

I am using XML Extender which is implemented by IBM via some C stored procs.
My HADR servers are identical OS's (RH AS3) and I backed up the primary
database, then restored it on the second server to create a standby
database. Will I have any issues with "objects" or 'libraries" as mentioned
in the above quote?

[Phil Sherman]

the CREATE PROCEDURE (external) statement has clauses that identify the
physical location of the executable code that forms the procedure. When
you restore the database, the definition of the procedure will exist in
the standby database but the executable code will not. (CREATE PROCEDURE
specifically allows this.)

You must manually copy all of the executable code for external
procedures to the standby system. Code must be copied from every
location where it resides on the primary server. You must also copy new
and updated external procedures to the standby system. Code on the
standby system must be located in the same directories as the primary
system.

Phil Sherman

Mark A wrote:

I found this in the doc:

"HADR does not replicate stored procedure and UDF object and library files.
You must create the files on identical paths on both the primary and standby
databases. If the standby database cannot find the referenced object or
library file, the stored procedure or UDF invocation will fail on the
standby database."

I am using XML Extender which is implemented by IBM via some C stored procs.
My HADR servers are identical OS's (RH AS3) and I backed up the primary
database, then restored it on the second server to create a standby
database. Will I have any issues with "objects" or 'libraries" as mentioned
in the above quote?

[Mark A]

"Phil Sherman" <ps******@ameritech.net> wrote in message
news:wR*****************@newssvr17.news.prodigy.co m...

the CREATE PROCEDURE (external) statement has clauses that identify the
physical location of the executable code that forms the procedure. When
you restore the database, the definition of the procedure will exist in
the standby database but the executable code will not. (CREATE PROCEDURE
specifically allows this.)

You must manually copy all of the executable code for external procedures
to the standby system. Code must be copied from every location where it
resides on the primary server. You must also copy new and updated external
procedures to the standby system. Code on the standby system must be
located in the same directories as the primary system.

Phil Sherman

Do you know the executables are located by default?

[Ian]

Mark A wrote:

"Phil Sherman" <ps******@ameritech.net> wrote in message
news:wR*****************@newssvr17.news.prodigy.co m...

the CREATE PROCEDURE (external) statement has clauses that identify the
physical location of the executable code that forms the procedure. When
you restore the database, the definition of the procedure will exist in
the standby database but the executable code will not. (CREATE PROCEDURE
specifically allows this.)

You must manually copy all of the executable code for external procedures
to the standby system. Code must be copied from every location where it
resides on the primary server. You must also copy new and updated external
procedures to the standby system. Code on the standby system must be
located in the same directories as the primary system.

Phil Sherman

Do you know the executables are located by default?

Generally they are stored in the .../sqllib/function directory, although
it is possible to place them elsewhere (look at the IMPLEMENTATION field
in syscat.procedures).

[Phil Sherman]

See the "CREATE PROCEDURE (external)" statement in the SQL Reference v2
for details about where the default locations are. Note that the default
locations for fenced and unfenced procedures are different.

Your RHAS3 systems will have a single directory for each type of
procedure. (.../sqllib/function and ..../sqllib/function/unfenced)

Don't forget that some developers may have specified their own locations
for the executable - see Ian's reply above.

Phil Sherman
Mark A wrote:

"Phil Sherman" <ps******@ameritech.net> wrote in message
news:wR*****************@newssvr17.news.prodigy.co m...

the CREATE PROCEDURE (external) statement has clauses that identify the
physical location of the executable code that forms the procedure. When
you restore the database, the definition of the procedure will exist in
the standby database but the executable code will not. (CREATE PROCEDURE
specifically allows this.)

You must manually copy all of the executable code for external procedures
to the standby system. Code must be copied from every location where it
resides on the primary server. You must also copy new and updated external
procedures to the standby system. Code on the standby system must be
located in the same directories as the primary system.

Phil Sherman

Do you know the executables are located by default?

[Mark A]

"Phil Sherman" <ps******@ameritech.net> wrote in message
news:iH****************@newssvr17.news.prodigy.com ...

See the "CREATE PROCEDURE (external)" statement in the SQL Reference v2
for details about where the default locations are. Note that the default
locations for fenced and unfenced procedures are different.

Your RHAS3 systems will have a single directory for each type of
procedure. (.../sqllib/function and ..../sqllib/function/unfenced)

Don't forget that some developers may have specified their own locations
for the executable - see Ian's reply above.

Phil Sherman

All of my C stored procedures are part of the XML Extender.

[m0002a]

Object libraries for C Stored Procedures created by XML Extender do not
need to be copied to the HADR standby server, since they are already in
the DB2 install path and have symbolic links pointing to them from
sqllib.