Replication: Nature of file for subscription-set?
Troels Arvin
I'm trying to grasp DB2 SQL-replication.
In the example at http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/
topic/com.ibm.swg.im.iis.db.repl.asnclp.sql.doc/topics/
iiyrsclpbldscriptsql.html there is a section called "ASNCLP script 5
(subscription-set member)".
The code in the example contains this statement:
SET PROFILE TBSPROFILE FOR OBJECT TARGET TABLESPACE OPTIONS UW
USING FILE "c:\TSTRG.TS" SIZE 700 PAGES;
What's the purpose of the TSTRG.TS file? What should the permissions of
such a file be? Should it be backed up? Or is it temporary while setting
up replication? If not: Is is a performance bottleneck (i.e.: should it be
put on potent storage?). And if it's not temporary: placing it in the
root of the filesystem seems odd; would a better placement be something
like ~db2inst1/sqllib?
--
Troels
Lennart Jonsson
Not sure (it was quite sime time since I played with sql replication),
but I think it is a tablespace that could be used for tables related to
subscription. I looked in my sample scripts that I created, and I notice
that I commented that section out, so I assume this means that tables
where created in USERSPACE1:
[ltjn@melkor
/view/ltjn_dyn_bas10/vob/NYA_DB/database/ddl/util/tek_88_example]$ cat
replicate_tables.sh
[...]
#------------------------------------------------------------------------------
# subscription set members
#------------------------------------------------------------------------------
TABLIST=`echo $TABLES | sed -e "s/,/ /g"`
for x in `echo $TARGETDB | sed -e "s/,/ /g"`; do
capmember_sql=sql/capmember_$x.sql
appmember_sql=sql/appmember_$x.sql
projtrg_sql=sql/projtrg_$x.sql
member_err=log/member_$x.err
rm -f $capmember_sql > /dev/null 2>&1
rm -f $appmember_sql > /dev/null 2>&1
rm -f $projtrg_sql > /dev/null 2>&1
rm -f $member_err > /dev/null 2>&1
asnclp <<EOF
SET SERVER CAPTURE TO DB $MASTERDB ID $USERNAME PASSWORD "$PASSWORD"
SET SERVER CONTROL TO DB $x ID $USERNAME PASSWORD "$PASSWORD"
SET SERVER TARGET TO DB $x ID $USERNAME PASSWORD "$PASSWORD"
SET OUTPUT CAPTURE SCRIPT "$capmember_sql" CONTROL SCRIPT
"$appmember_sql" TARGET SCRIPT "$projtrg_sql"
SET LOG "$member_err"
SET RUN SCRIPT LATER
#SET PROFILE TBSPROFILE FOR OBJECT TARGET TABLESPACE OPTIONS UW USING
#FILE "c:\TSTRG.TS" SIZE 700 PAGES
#CREATE MEMBER IN SETNAME SET00 APPLYQUAL AQ00 ACTIVATE YES SOURCE PROJECT
#TARGET NAME TRGPROJECT DEFINITION IN TSTRG00 CREATE USING PROFILE
TBSPROFILE
#TYPE USERCOPY COLS ALL REGISTERED;
`for t in $TABLIST; do echo "CREATE MEMBER IN SETNAME SET00 APPLYQUAL
AQ00 ACTIVATE YES SOURCE $SCHEMA.$t TARGET NAME $SCHEMA.$t DEFINITION
TYPE USERCOPY COLS ALL REGISTERED"; done`
QUIT
EOF
[...]
I can mail you the scripts I played with, in case you would like to
compare with your own things.
/Lennart
DavidT
> Hello,
>
> I'm trying to grasp DB2 SQL-replication.
>
If your target tables do not exist, asnclp will try to create them for
you. If you do not want the target tables to be created in the
default tablespace, then you need to give asnclp some information
about what the tablespaces you want it use. asnclp can also create
the target table spaces. You'll need to tell asnclp where to put it,
etc..
The Set Profile command tells asnclp about table spaces for those
situations where you're having asnclp create things for you. If your
target table already exists, the profile isn't necessary. If you're
good with all tables going into the default, no need for the profile
either.
The sample is just that and not a recommendation :) It's not likely
anyone would want to put table spaces in a root directory.
--
david
Troels Arvin
In comp.databases.ibm-db2, you recently wrote:
>> What's the purpose of the TSTRG.TS file?
[...]
> Not sure (it was quite sime time since I played with sql replication),
> but I think it is a tablespace that could be used for tables related to
> subscription. I looked in my sample scripts that I created, and I notice
> that I commented that section out, so I assume this means that tables
> where created in USERSPACE1:
Ah, it's to be interpreted as a tablespace container file, it seems.
[...]
> I can mail you the scripts I played with, in case you would like to
> compare with your own things.
I would very much appreciate that. Do you happen to also have init-scripts
for properly starting/stopping replication (capture and/or apply daemons)
on server boot/shutdown?
--
Troels