when do rows get deleted from SYSLGRNX

Kirk Hampton

when do rows get deleted from SYSLGRNX
Hi all,
We run several DB2 v6.1 subsystems across several LPAR's
on OS/390 v2.10, and one of them has accumulated vastly more rows
in SYSLGRNX than all the others. Late last year, I attempted to
REORG the SYSLGRNX tablespace during one of our maintenance
outages, but gave up after it ran over 2 1/2 hours in the unload phase.
Working with my DBA's early this year, we ran MODIFY
RECOVERY on most of the tablespaces in that subsystem, and I
thought that most of the rows should have been purged. I ran another
REORG at the end of November, this time removing the SORTKEYS
parameter. It still took over an hour to run, but it finished. However, I
was disappointed to learn that it still unloaded/reloaded over 5 million
rows in SYSLGRNX. There are less than 1200 tablespaces in this
subsystem.
I had saved the SYSREC dataset from the REORG, so I had
a look at the unloaded rows from SYSLGRNX. It appears that the vast
majority of the rows refer to the tablespaces belonging to our CCD
tables for Data Propagator. We never (well, hardly ever) Image Copy
these tables, since all the data in them is transient, and gets deleted
as soon as it is propagated to the target tables. I have Imaged them
and REORGed them occasionally, and I had done so earlier this year,
as well as running a MODIFY RECOVERY ... DELETE AGE(72) on
them. But still, there are rows in SYSLGRNX that have dates on them
all the way back to 1997, which is when these tables were first created.
Does anyone know what sequence of operations (COPY,
REORG, MODIFY ? ) will get rid of the ancient SYSLGRNX rows for these
tablespaces ? We are planning to start COPYing and MODIFYing
them on a weekly basis.

Thanks,

Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Business Services
Dallas, Texas




*********************************************************************************
Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be
advised that any reading, dissemination, forwarding, printing, copying
or other use of this message or its attachments is strictly prohibited. If
you have received this message in error, please notify the sender
immediately by reply message and delete this email message and any
attachments from your system.
*********************************************************************************

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Wayne Driscoll

Re: when do rows get deleted from SYSLGRNX
(in response to Kirk Hampton)
Kirk,
There was a discussion a while back regarding the fact that a DROP
TABLESPACE will not clean up SYSLGRNX rows, so this could explain some
of these old rows, especially if the tablespaces get dropped/recreated
occasionally. I don't remember all the details, but if you search the
archives you should find more information.
Wayne Driscoll
Sr. Software Developer
Quest Software
[login to unmask email]
NOTE: All opinions are strictly my own. EMail Address in sig must be
modified.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Kirk Hampton
Sent: Wednesday, December 17, 2003 5:25 PM
To: [login to unmask email]
Subject: [DB2-L] when do rows get deleted from SYSLGRNX


Hi all,
We run several DB2 v6.1 subsystems across several LPAR's on OS/390
v2.10, and one of them has accumulated vastly more rows in SYSLGRNX
than all the others. Late last year, I attempted to REORG the SYSLGRNX
tablespace during one of our maintenance outages, but gave up after it
ran over 2 1/2 hours in the unload phase.
Working with my DBA's early this year, we ran MODIFY RECOVERY on
most of the tablespaces in that subsystem, and I thought that most of
the rows should have been purged. I ran another REORG at the end of
November, this time removing the SORTKEYS parameter. It still took over
an hour to run, but it finished. However, I was disappointed to learn
that it still unloaded/reloaded over 5 million rows in SYSLGRNX. There
are less than 1200 tablespaces in this subsystem.
I had saved the SYSREC dataset from the REORG, so I had
a look at the unloaded rows from SYSLGRNX. It appears that the vast
majority of the rows refer to the tablespaces belonging to our CCD
tables for Data Propagator. We never (well, hardly ever) Image Copy
these tables, since all the data in them is transient, and gets deleted
as soon as it is propagated to the target tables. I have Imaged them
and REORGed them occasionally, and I had done so earlier this year, as
well as running a MODIFY RECOVERY ... DELETE AGE(72) on them. But
still, there are rows in SYSLGRNX that have dates on them all the way
back to 1997, which is when these tables were first created.
Does anyone know what sequence of operations (COPY, REORG, MODIFY
? ) will get rid of the ancient SYSLGRNX rows for these tablespaces ?
We are planning to start COPYing and MODIFYing them on a weekly basis.

Thanks,

Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Business Services Dallas, Texas




************************************************************************
*********
Confidentiality Notice: This email message, including any attachments,
contains or may contain confidential information intended only for the
addressee. If you are not an intended recipient of this message, be
advised that any reading, dissemination, forwarding, printing, copying
or other use of this message or its attachments is strictly prohibited.
If you have received this message in error, please notify the sender
immediately by reply message and delete this email message and any
attachments from your system.
************************************************************************
*********

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". If you will be out of the office,
send the SET DB2-L NO MAIL command to [login to unmask email] The
IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: when do rows get deleted from SYSLGRNX
(in response to Wayne Driscoll)
The information is well hidden (a quick search has failed to find it
again, so I can't cite a reference): MODIFY RECOVERY will delete SYSLGRNX
records only if there are SYSCOPY records to delete. So if you never took
an IC, you never removed any SYSLGRNX records either.
What to do: take ICs of the tablespaces in question today. Tomorrow run
another IC and MODIFY RECOVERY... DELETE AGE(0) for them. This will remove
all but the most recent IC and all SYSCOPY and SYSLGRNX older than the
current day.
I have never experimented to find out whether the "SYSCOPY records to
delete" applies only to IC entries (full ICs), or FICs and REORG/LOAD
REPLACE LOG YES, or all SYSCOPY entries (unlikely). To be safe, use a full
IC; that will work in any case.
If you DROP a TS, SYSLGRNX records are not deleted - that happens only if
you create a new TS and the DBID/PSID get reused. In order to get rid of
the SYSLGRNX records when you drop the TS, you should first run a FIC and
then a MODIFY RECOVERY ... DELETE AGE(*) and then do the DROP (this puts
the TS in COPY Pending, that's why the procedure I proposed for your TSs
is a bit different).

Dr. Michael Ebert
DB2 Database Administrator
aMaDEUS Data Processing
Erding / Munich, Germany



Hi all,
We run several DB2 v6.1 subsystems across several LPAR's
on OS/390 v2.10, and one of them has accumulated vastly more rows
in SYSLGRNX than all the others. Late last year, I attempted to
REORG the SYSLGRNX tablespace during one of our maintenance
outages, but gave up after it ran over 2 1/2 hours in the unload phase.
Working with my DBA's early this year, we ran MODIFY
RECOVERY on most of the tablespaces in that subsystem, and I
thought that most of the rows should have been purged. I ran another
REORG at the end of November, this time removing the SORTKEYS
parameter. It still took over an hour to run, but it finished. However,
I
was disappointed to learn that it still unloaded/reloaded over 5 million
rows in SYSLGRNX. There are less than 1200 tablespaces in this
subsystem.
I had saved the SYSREC dataset from the REORG, so I had
a look at the unloaded rows from SYSLGRNX. It appears that the vast
majority of the rows refer to the tablespaces belonging to our CCD
tables for Data Propagator. We never (well, hardly ever) Image Copy
these tables, since all the data in them is transient, and gets deleted
as soon as it is propagated to the target tables. I have Imaged them
and REORGed them occasionally, and I had done so earlier this year,
as well as running a MODIFY RECOVERY ... DELETE AGE(72) on
them. But still, there are rows in SYSLGRNX that have dates on them
all the way back to 1997, which is when these tables were first created.
Does anyone know what sequence of operations (COPY,
REORG, MODIFY ? ) will get rid of the ancient SYSLGRNX rows for these
tablespaces ? We are planning to start COPYing and MODIFYing
them on a weekly basis.

Thanks,

Kirk Hampton
DB2 OS/390 Sysprog
IBM Certified Solutions Expert - DB2 V7 Database Administration OS/390
TXU Business Services
Dallas, Texas


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Max Scarpa

Re: when do rows get deleted from SYSLGRNX
(in response to Michael Ebert)
Anyway there are few PTFs (for V6/V7) dealing with SYSLGRNX records that
are not deleted after execution of MODIFY
utility (it miss to call SYSLGRNX cleanup routine under some
circumstances), maybe you're missing one of them.

Anyway the official way to drop a table without having SYSLGRNX rows left
is the method described by other listers and suggested as 'WAD' in some old
posts by IBM people.

Max Scarpa

DB2 for z/OS sysprog
Storage manager
WLM Administrator

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Tina Hilton

Re: when do rows get deleted from SYSLGRNX
(in response to Max Scarpa)
There was also a problem with exceeding maxlocks, which caused it to fail.
Restart wouldn't accomplish anything because the syscopy rows were already
gone. I cleaned up a system that had this problem by using BMC's C+/Modify
to insert quiesce rows and then rerunning the modify until it successfully
completed. As long as there is a row in syscopy (reorg, load, quiesce,
copy, etc.) it will attempt delete the rows from syslgrnx in addition to the
ones in syscopy.

Tina

-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Thursday, December 18, 2003 4:29 AM
To: [login to unmask email]
Subject: Re: when do rows get deleted from SYSLGRNX


Anyway there are few PTFs (for V6/V7) dealing with SYSLGRNX records that are
not deleted after execution of MODIFY utility (it miss to call SYSLGRNX
cleanup routine under some circumstances), maybe you're missing one of them.

Anyway the official way to drop a table without having SYSLGRNX rows left
is the method described by other listers and suggested as 'WAD' in some old
posts by IBM people.

Max Scarpa

DB2 for z/OS sysprog
Storage manager
WLM Administrator

----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". If you will be out of the office, send the SET
DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins
can be reached at [login to unmask email] Find out the latest on
IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Jim Tonchick

Re: when do rows get deleted from SYSLGRNX
(in response to Tina Hilton)
Your new practice of initiating image copies and running MODIFY will help
keep SYSLGRNX to a reasonable size.

Since you don't care about the contents of the tables. Here's a tip I use in
my test subsystem. Run MODIFY AGE(*), then COPY to a sequential file (not
GDG). After you do this once, insert a step to delete all the previous copy
datasets. You now have a process that keeps only one copy for each object. Run
weekly, it should go a long way to keep SYSLGRNX under control.

Jim Tonchick
Sr. Systems Programmer
Fiserv, Inc.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Ndt

Re: when do rows get deleted from SYSLGRNX
(in response to Jim Tonchick)
From the manual :
(dsnsqxxx - DROP statement )
Deleting SYSLGRNG records for dropped table spaces: After dropping a table
space, you cannot delete the associated records. If you want to remove the
records, you must quiesce the table space, and then run the MODIFY RECOVERY
utility before dropping the table space. If you delete the SYSLGRNG records
and
drop the table space, you cannot reclaim the table space.


I think this way is easier than dealing with copy



Below is my test to confirm what the manual says :

1/ report recovery : no syscopy enty , 1 syslg entry

DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROW
DSNU588I DR06 DSNUPPCP - NO DATA TO BE
REPORTED
DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSN
UCDATE UCTIME START RBA STOP RBA START LRSN STOP
LRSN
070291 15124559 000720BC2EF3 000720BC42F8 000720BC2EF3
000720BC42F8

2/ modify delete age(*)

OUTPUT START FOR UTILITY, UTILID = TXDN99
MODIFY RECOVERY TABLESPACE DSNDB04.ALEX01 DELETE AGE(*)
UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

3/ report recovery : always the same , syslg entry is still here

DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROWS
DSNU588I DR06 DSNUPPCP - NO DATA TO BE
REPORTED
DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSND
UCDATE UCTIME START RBA STOP RBA START LRSN STOP
LRSN
070291 15124559 000720BC2EF3 000720BC42F8 000720BC2EF3
000720BC42F8

4/ Quiesce
5/ Report : 1 syscopy entry , 1 syslg
DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROWS
TIMESTAMP = 2003-12-19-15.32.16.817697, IC TYPE = *Q*, SHR LVL = ,
DSNUM
DEV TYPE = , IC BACK = , STYPE = W, FILE
SEQ
LOW DSNUM = 0000, HIGH DSNUM =
0000
JOBNAME = AST0010S, AUTHID = AST0010 , COPYPAGESF = -
1.0E+00
NPAGESF = -1.0E+00 , CPAGESF = -
1.0E+00
DSNAME = DSNDB04.ALEX01 , MEMBER NAME
=


DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSND
UCDATE UCTIME START RBA STOP RBA START LRSN STOP
LRSN
070291 15124559 000720BC2EF3 000720BC42F8 000720BC2EF3
000720BC42F8

6/ Modify
DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TXDN99
DSNUGUTC - MODIFY RECOVERY TABLESPACE DSNDB04.ALEX01 DELETE AGE(*)
06 DSNUMDEL - ALL LOCALSITE SYSCOPY RECORDS FOR TABLESPACE= DSNDB04.
HAVE BEEN DELETED
06 DSNUGSRX - TABLESPACE DSNDB04.ALEX01 IS IN COPY PENDING
06 DSNUMODA - MODIFY COMPLETED SUCCESSFULLY
DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4

7/Report : nothing in syscopy and syslg !

DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROWS
DSNU588I DR06 DSNUPPCP - NO DATA TO BE
REPORTED
DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSND
DSNU588I DR06 DSNUPPLR - NO DATA TO BE
REPORTED

Note : The last modify didn't report that syslg antry was deleted




Regards ,

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Phil Grainger

Re: when do rows get deleted from SYSLGRNX
(in response to Ndt)
but the point is, if there are no rows in SYSCOPY for MODIFY RECOVERY to purge, then it does not clean out SYSLGRNX either!

Phil Grainger
Computer Associates
Product Manager, DB2
Tel: +44 (0)161 928 9334
Fax: +44 (0)161 941 3775
Mobile: +44 (0)7970 125 752
[login to unmask email]



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of nguyen
Sent: Friday, December 19, 2003 2:51 PM
To: [login to unmask email]
Subject: Re: when do rows get deleted from SYSLGRNX


From the manual :
(dsnsqxxx - DROP statement )
Deleting SYSLGRNG records for dropped table spaces: After dropping a table
space, you cannot delete the associated records. If you want to remove the
records, you must quiesce the table space, and then run the MODIFY RECOVERY
utility before dropping the table space. If you delete the SYSLGRNG records
and
drop the table space, you cannot reclaim the table space.


I think this way is easier than dealing with copy



Below is my test to confirm what the manual says :

1/ report recovery : no syscopy enty , 1 syslg entry

DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROW
DSNU588I DR06 DSNUPPCP - NO DATA TO BE
REPORTED
DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSN
UCDATE UCTIME START RBA STOP RBA START LRSN STOP
LRSN
070291 15124559 000720BC2EF3 000720BC42F8 000720BC2EF3
000720BC42F8

2/ modify delete age(*)

OUTPUT START FOR UTILITY, UTILID = TXDN99
MODIFY RECOVERY TABLESPACE DSNDB04.ALEX01 DELETE AGE(*)
UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

3/ report recovery : always the same , syslg entry is still here

DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROWS
DSNU588I DR06 DSNUPPCP - NO DATA TO BE
REPORTED
DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSND
UCDATE UCTIME START RBA STOP RBA START LRSN STOP
LRSN
070291 15124559 000720BC2EF3 000720BC42F8 000720BC2EF3
000720BC42F8

4/ Quiesce
5/ Report : 1 syscopy entry , 1 syslg
DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROWS
TIMESTAMP = 2003-12-19-15.32.16.817697, IC TYPE = *Q*, SHR LVL = ,
DSNUM
DEV TYPE = , IC BACK = , STYPE = W, FILE
SEQ
LOW DSNUM = 0000, HIGH DSNUM =
0000
JOBNAME = AST0010S, AUTHID = AST0010 , COPYPAGESF = -
1.0E+00
NPAGESF = -1.0E+00 , CPAGESF = -
1.0E+00
DSNAME = DSNDB04.ALEX01 , MEMBER NAME
=


DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSND
UCDATE UCTIME START RBA STOP RBA START LRSN STOP
LRSN
070291 15124559 000720BC2EF3 000720BC42F8 000720BC2EF3
000720BC42F8

6/ Modify
DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = TXDN99
DSNUGUTC - MODIFY RECOVERY TABLESPACE DSNDB04.ALEX01 DELETE AGE(*)
06 DSNUMDEL - ALL LOCALSITE SYSCOPY RECORDS FOR TABLESPACE= DSNDB04.
HAVE BEEN DELETED
06 DSNUGSRX - TABLESPACE DSNDB04.ALEX01 IS IN COPY PENDING
06 DSNUMODA - MODIFY COMPLETED SUCCESSFULLY
DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4

7/Report : nothing in syscopy and syslg !

DSNU582I DR06 DSNUPPCP - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01 SYSCOPY
ROWS
DSNU588I DR06 DSNUPPCP - NO DATA TO BE
REPORTED
DSNU586I DR06 DSNUPSUM - REPORT RECOVERY TABLESPACE DSNDB04.ALEX01
SUMMARY
DSNU588I DR06 DSNUPSUM - NO DATA TO BE
REPORTED


DSNU583I DR06 DSNUPPLR - SYSLGRNX ROWS FROM REPORT RECOVERY FOR TABLESPACE
DSND
DSNU588I DR06 DSNUPPLR - NO DATA TO BE
REPORTED

Note : The last modify didn't report that syslg antry was deleted




Regards ,

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Ndt

Re: when do rows get deleted from SYSLGRNX
(in response to Phil Grainger)
Phil ,
Didn't you see the test i 've done. You can verify it by yourself.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Hello

Re: when do rows get deleted from SYSLGRNX
(in response to Ndt)
My question is : Does every body has an idea why DROP doesn't do the job ?

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Georg Peter

AW: when do rows get deleted from SYSLGRNX
(in response to Hello)
Daniel,

AFAIK the table SYSIBM.SYSLGRNX resides in the DB2 directory.

And no DB2 directory table can be accessed with DML.

With kind regards - mit freundlichen Gruessen,
Georg H. Peter c/o
-------------------------------------------------------------------
Datenzentrale Baden-Wuerttemberg
Software Development & Technology Center
Knowledge Center Database Systems
Krailenshaldenstrasse 44, 70469 Stuttgart, Germany, Europe
e:mail [login to unmask email]
Phone 0049-711-8108-271
PC-Fax 004971189696071
Internet (only in german language):http://www.dzbw.de
----------------------------------------------------------------------

-----Ursprüngliche Nachricht-----
Von: Daniel [mailto:[login to unmask email]
Gesendet: Montag, 22. Dezember 2003 15:00
An: [login to unmask email]
Betreff: Re: when do rows get deleted from SYSLGRNX

My question is : Does every body has an idea why DROP doesn't do the job ?

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Michael Ebert

Re: AW: when do rows get deleted from SYSLGRNX
(in response to Georg Peter)
Hi Peter,

no that has no relation. The cleanup is not done by DML, it is a
sideeffect of a DDL (like the removal of a VSAM file when you do a DROP
TS). As for the reason, Dan Courter from IBM Utilities Dev. wrote this on
16.5.00:

There are two places where SYSLGRNX should be cleaned up.

1) DROP attempts to clear out obsolste records. However, if it fails
(resource unavailable) the DROP continues. Cleanup will be performed
later, at the time the same DBID/PSID pair is reused by a CREATE

2) That's the second one. CREATE performs a second check to clear out
obsolete records before it reuses the identifier pair.

I can see that the DROP cleanup routine is being invoked but we are
only getting a partial cleanup. I have asked two other programmers to
look at this and I'll post more later. I have not tested the CREATE
cleanup scenario to know at this time if it is working or not.

I'm not sure about point 1 - it seems that DROP never attempts the
cleanup. I don't remember that the question ever was resolved in a
satisfactory manner. So it seems that DB2 just lets CREATE do the job, not
DROP.

MfG, ME.



Daniel,

AFAIK the table SYSIBM.SYSLGRNX resides in the DB2 directory.

And no DB2 directory table can be accessed with DML.

With kind regards - mit freundlichen Gruessen,
Georg H. Peter c/o
-------------------------------------------------------------------
Datenzentrale Baden-Wuerttemberg
Software Development & Technology Center
Knowledge Center Database Systems
Krailenshaldenstrasse 44, 70469 Stuttgart, Germany, Europe
e:mail [login to unmask email]
Phone 0049-711-8108-271
PC-Fax 004971189696071
Internet (only in german language):http://www.dzbw.de
----------------------------------------------------------------------

-----Ursprüngliche Nachricht-----
>Von: Daniel [mailto:[login to unmask email]
Gesendet: Montag, 22. Dezember 2003 15:00
>An: [login to unmask email]
>Betreff: Re: when do rows get deleted from SYSLGRNX

My question is : Does every body has an idea why DROP doesn't do the job ?


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". If you will be out of the office, send the SET DB2-L NO MAIL command to [login to unmask email] The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm