SYSREC space for REORG

DB2 V7.1 in z/OS

Hi,

As far as I know, in REORG of a tablespace with shrlevel NONE, the space
required for SYSREC dataset is = number of records in table * "reclength" from
SYSTABLES for the table.

For multiple tables in tablespace, sum of above values for each.

Since "reclength" already accounts for extra 8 bytes(the header 6 bytes and
the ID map entry 2 bytes) and varchar, null indicators as well as editproc if
any, it should be sufficient.

1. Is this correct or something extra, for example clustering key length, if
available, also needs to be taken into consideration?

2. If the tablespace is compressed, then the HI-USED-RBA for the tablespace
dataset should be sufficient as primary quantity of SYSREC, right?

Thanks in advance for your thoughts.
Amar

IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion listserv that are being implemented to improve reliability and the overall user experience of DB2-L. These changes are coming on November 30th. Details at http://www.idug.org

---------------------------------------------------------------------------------
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". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. 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

Probably not interesting but I do reorg on TS (segmented) without sysrec
Only every table have to have a index

REORG TABLESPACE SPD2VE.SPSSP
LOG NO
SORTDATA
NOSYSREC
SHRLEVEL NONE
Regards
dusan

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of amar
Sent: Thursday, November 22, 2007 1:25 AM
To: [login to unmask email]
Subject: [DB2-L] SYSREC space for REORG

DB2 V7.1 in z/OS

Hi,

As far as I know, in REORG of a tablespace with shrlevel NONE, the space required for SYSREC dataset is = number of records in table * "reclength" from SYSTABLES for the table.

For multiple tables in tablespace, sum of above values for each.

Since "reclength" already accounts for extra 8 bytes(the header 6 bytes and the ID map entry 2 bytes) and varchar, null indicators as well as editproc if any, it should be sufficient.

1. Is this correct or something extra, for example clustering key length, if available, also needs to be taken into consideration?

2. If the tablespace is compressed, then the HI-USED-RBA for the tablespace dataset should be sufficient as primary quantity of SYSREC, right?

Thanks in advance for your thoughts.
Amar

IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion listserv that are being implemented to improve reliability and the overall user experience of DB2-L. These changes are coming on November 30th. Details at http://www.idug.org

---------------------------------------------------------------------------------
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". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. 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

IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion listserv that are being implemented to improve reliability and the overall user experience of DB2-L. These changes are coming on November 30th. Details at http://www.idug.org

---------------------------------------------------------------------------------
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". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. 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

dusan,

No-sysrec surely has its use, but is not desirable in
all cases, especially if restartablity is required for
a failure in the reload phase.

Thanks,
Amar

--- Pospí¹il Du¹an <[login to unmask email]> wrote:

> Probably not interesting but I do reorg on TS
> (segmented) without sysrec
> Only every table have to have a index
>
> REORG TABLESPACE SPD2VE.SPSSP
> LOG NO
> SORTDATA
> NOSYSREC
> SHRLEVEL NONE
> Regards
> dusan
>
> -----Original Message-----
> From: DB2 Data Base Discussion List
> [mailto:[login to unmask email] On Behalf Of amar
> Sent: Thursday, November 22, 2007 1:25 AM
> To: [login to unmask email]
> Subject: [DB2-L] SYSREC space for REORG
>
> DB2 V7.1 in z/OS
>
> Hi,
>
> As far as I know, in REORG of a tablespace with
> shrlevel NONE, the space required for SYSREC dataset
> is = number of records in table * "reclength" from
> SYSTABLES for the table.
>
> For multiple tables in tablespace, sum of above
> values for each.
>
> Since "reclength" already accounts for extra 8
> bytes(the header 6 bytes and the ID map entry 2
> bytes) and varchar, null indicators as well as
> editproc if any, it should be sufficient.
>
> 1. Is this correct or something extra, for example
> clustering key length, if available, also needs to
> be taken into consideration?
>
> 2. If the tablespace is compressed, then the
> HI-USED-RBA for the tablespace dataset should be
> sufficient as primary quantity of SYSREC, right?
>
> Thanks in advance for your thoughts.
> Amar
>
> IMPORTANT NOTICE:
>
> IDUG is pleased to announce a series of upgrades to
> the DB2-L discussion listserv that are being
> implemented to improve reliability and the overall
> user experience of DB2-L. These changes are coming
> on November 30th. Details at http://www.idug.org
>
>
---------------------------------------------------------------------------------
> 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". The IDUG
> DB2-L FAQ is at http://www.idugdb2-l.org. 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
>
> IMPORTANT NOTICE:
>
> IDUG is pleased to announce a series of upgrades to
> the DB2-L discussion listserv that are being
> implemented to improve reliability and the overall
> user experience of DB2-L. These changes are coming
> on November 30th. Details at http://www.idug.org
>
>
---------------------------------------------------------------------------------
> 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". The IDUG
> DB2-L FAQ is at http://www.idugdb2-l.org. 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
>



____________________________________________________________________________________
Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

IMPORTANT NOTICE:

IDUG is pleased to announce a series of upgrades to the DB2-L discussion listserv that are being implemented to improve reliability and the overall user experience of DB2-L. These changes are coming on November 30th. Details at http://www.idug.org

---------------------------------------------------------------------------------
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". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. 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