Hello Tandem Experts and Enthusiast,

I would like to to ask for your help and ask for guidance on how to reduce the EOF usage for the file we have (it says SQL Base Table). We have a table that monitors its usage and can see that Partition 1 is at 80.4% already, while Partition 2 is 0.2%.
The solutions that I have in mind is to delete some of the old datas in the SQL file, not sure though if it will reduce the usage. Comments and suggestions are very appreciated, cheers everyone.

ESCRIPTON VOLUME LOCATION EOF STATUS
Partition 0 $DS02.prdaSQL.CMCMBRT 30.7%
Partition 1 $DS03.prdaSQL.CMCMBRT 80.4%
Partition 2 $DS04.prdaSQL.CMCMBRT 0.2%
Partition 3 $DS05.prdaSQL.CMCMBRT 33.8%

Index 1 $DS02.prdaSQL 24.2%
Index 2 $DS02.prdaSQL 50.2%
Index 3 $DS02.prdaSQL 36.5%

Below is the fileinfo of the SQL table file:

$DS03.PRDASQL.CMCMBRT
SQL BASE TABLE
CATALOG $DS02.PRDASDX
VERSION 2
TYPE K
FORMAT 1
EXT ( 37752 PAGES, 37752 PAGES, MAXEXTENTS 16 )
REC 251
PACKED REC 250
BLOCK 4096
KEY ( COLUMN 0, OFFSET 0, LENGTH 10, ASC,
COLUMN 1, OFFSET 10, LENGTH 19, ASC,
COLUMN 2, OFFSET 29, LENGTH 5, ASC,
COLUMN 3, OFFSET 34, LENGTH 2, ASC )
INDEX ( 1, $DS02.PRDASQL.CMCMBRX1,
COLUMN 11, OFFSET 64, LENGTH 8, ASC,
UNIQUE )
INDEX ( 2, $DS02.PRDASQL.CMCMBRX2,
COLUMN 12, OFFSET 72, LENGTH 17, ASC,
COLUMN 13, OFFSET 89, LENGTH 12, ASC,
NOT UNIQUE )
INDEX ( 3, $DS02.PRDASQL.CMCMBRX3,
COLUMN 30, OFFSET 227, LENGTH 24, ASC,
NOT UNIQUE )
PART ( 0, $DS02, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 1, $DS03, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "510266020", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 2, $DS04, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "592108275", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 3, $DS05, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "592108575", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
AUDIT
BUFFERED
AUDITCOMPRESS
OWNER 190,1
SECURITY (RWEP): OOOO
SECONDARY PARTITION
DATA MODIF: 18 Feb 2022, 16:12, OPEN
CREATION DATE: 8 Jul 2019, 20:30
REDEFINITION DATE: 5 Jun 2014, 19:43
LAST OPEN: 17 Feb 2022, 22:42
EOF: 993939456 (80.3% USED)
EXTENTS ALLOCATED: 13
INDEX LEVELS: 3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 21 Feb 2022 21:21:04 -0800 (PST), Bry Pas <bryanpascua88@gmail.com> wrote:

Hello Tandem Experts and Enthusiast,

I would like to to ask for your help and ask for guidance on how to reduce the EOF usage for the file we have (it says SQL Base Table). We have a table that monitors its usage and can see that Partition 1 is at 80.4% already, while Partition 2 is 0.2%.

The solutions that I have in mind is to delete some of the old datas in the SQL file, not sure though if it will reduce the usage. Comments and suggestions are very appreciated, cheers everyone.

ESCRIPTON VOLUME LOCATION EOF STATUS
Partition 0 $DS02.prdaSQL.CMCMBRT 30.7%
Partition 1 $DS03.prdaSQL.CMCMBRT 80.4%
Partition 2 $DS04.prdaSQL.CMCMBRT 0.2%
Partition 3 $DS05.prdaSQL.CMCMBRT 33.8%

Index 1 $DS02.prdaSQL 24.2%
Index 2 $DS02.prdaSQL 50.2%
Index 3 $DS02.prdaSQL 36.5%

Below is the fileinfo of the SQL table file:

$DS03.PRDASQL.CMCMBRT
SQL BASE TABLE
CATALOG $DS02.PRDASDX
VERSION 2
TYPE K
FORMAT 1
EXT ( 37752 PAGES, 37752 PAGES, MAXEXTENTS 16 )
REC 251
PACKED REC 250
BLOCK 4096
KEY ( COLUMN 0, OFFSET 0, LENGTH 10, ASC,
COLUMN 1, OFFSET 10, LENGTH 19, ASC,
COLUMN 2, OFFSET 29, LENGTH 5, ASC,
COLUMN 3, OFFSET 34, LENGTH 2, ASC )
INDEX ( 1, $DS02.PRDASQL.CMCMBRX1,
COLUMN 11, OFFSET 64, LENGTH 8, ASC,
UNIQUE )
INDEX ( 2, $DS02.PRDASQL.CMCMBRX2,
COLUMN 12, OFFSET 72, LENGTH 17, ASC,
COLUMN 13, OFFSET 89, LENGTH 12, ASC,
NOT UNIQUE )
INDEX ( 3, $DS02.PRDASQL.CMCMBRX3,
COLUMN 30, OFFSET 227, LENGTH 24, ASC,
NOT UNIQUE )
PART ( 0, $DS02, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 1, $DS03, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "510266020", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 2, $DS04, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "592108275", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 3, $DS05, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "592108575", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
AUDIT
BUFFERED
AUDITCOMPRESS
OWNER 190,1
SECURITY (RWEP): OOOO
SECONDARY PARTITION
DATA MODIF: 18 Feb 2022, 16:12, OPEN
CREATION DATE: 8 Jul 2019, 20:30
REDEFINITION DATE: 5 Jun 2014, 19:43
LAST OPEN: 17 Feb 2022, 22:42
EOF: 993939456 (80.3% USED)
EXTENTS ALLOCATED: 13
INDEX LEVELS: 3

Bryan,

Audited SQL/MP tables such as this can have their partitions 'altered' online, which moves rows from one partition to another.
It reads like whoever defined these partitions either used an old distribution of the data, or took a guess that wasn't quite right.

Look in the SQL/MP Reference manual, in the ALTER TABLE section There are many options here, including ADD , MOVE , REUSE and DROP of a PARTITION.
You probably need to use MOVE.

These operations all work using a TMF transaction... with corresponding LOCKS on the table data.
This should be done by someone with good SQL/MP database management experience.

The first step is to determine what the ideal balance of primary key valuse in the table is, and whether the number of partitions is appropriate.

There is a fairly comprehensive description of how to allow this repartitioning to occur while processing continues, in the 'Considerations' portion of that part of the manual.
You should read that thoroughly and understand the impacts. There are some simple examples at the end of the ALTER TABLE section.

Bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, February 22, 2022 at 10:32:03 AM UTC-8, Bill Honaker wrote:

On Mon, 21 Feb 2022 21:21:04 -0800 (PST), Bry Pas <bryanp...@gmail.com> wrote:

Hello Tandem Experts and Enthusiast,

I would like to to ask for your help and ask for guidance on how to reduce the EOF usage for the file we have (it says SQL Base Table). We have a table that monitors its usage and can see that Partition 1 is at 80.4% already, while Partition 2 is 0.2%

. The solutions that I have in mind is to delete some of the old datas in the SQL file, not sure though if it will reduce the usage. Comments and suggestions are very appreciated, cheers everyone.

ESCRIPTON VOLUME LOCATION EOF STATUS
Partition 0 $DS02.prdaSQL.CMCMBRT 30.7%
Partition 1 $DS03.prdaSQL.CMCMBRT 80.4%
Partition 2 $DS04.prdaSQL.CMCMBRT 0.2%
Partition 3 $DS05.prdaSQL.CMCMBRT 33.8%

Index 1 $DS02.prdaSQL 24.2%
Index 2 $DS02.prdaSQL 50.2%
Index 3 $DS02.prdaSQL 36.5%

Below is the fileinfo of the SQL table file:

$DS03.PRDASQL.CMCMBRT
SQL BASE TABLE
CATALOG $DS02.PRDASDX
VERSION 2
TYPE K
FORMAT 1
EXT ( 37752 PAGES, 37752 PAGES, MAXEXTENTS 16 )
REC 251
PACKED REC 250
BLOCK 4096
KEY ( COLUMN 0, OFFSET 0, LENGTH 10, ASC,
COLUMN 1, OFFSET 10, LENGTH 19, ASC,
COLUMN 2, OFFSET 29, LENGTH 5, ASC,
COLUMN 3, OFFSET 34, LENGTH 2, ASC )
INDEX ( 1, $DS02.PRDASQL.CMCMBRX1,
COLUMN 11, OFFSET 64, LENGTH 8, ASC,
UNIQUE )
INDEX ( 2, $DS02.PRDASQL.CMCMBRX2,
COLUMN 12, OFFSET 72, LENGTH 17, ASC,
COLUMN 13, OFFSET 89, LENGTH 12, ASC,
NOT UNIQUE )
INDEX ( 3, $DS02.PRDASQL.CMCMBRX3,
COLUMN 30, OFFSET 227, LENGTH 24, ASC,
NOT UNIQUE )
PART ( 0, $DS02, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 1, $DS03, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "510266020", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 2, $DS04, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "592108275", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
PART ( 3, $DS05, 37752 PAGES, 37752 PAGES, MAXEXTENTS 16, FORMAT 1,
( "08", "592108575", [ 0, 0, 0, 0, 0 ], [ 0, 0 ] ) )
AUDIT
BUFFERED
AUDITCOMPRESS
OWNER 190,1
SECURITY (RWEP): OOOO
SECONDARY PARTITION
DATA MODIF: 18 Feb 2022, 16:12, OPEN
CREATION DATE: 8 Jul 2019, 20:30
REDEFINITION DATE: 5 Jun 2014, 19:43
LAST OPEN: 17 Feb 2022, 22:42
EOF: 993939456 (80.3% USED)
EXTENTS ALLOCATED: 13
INDEX LEVELS: 3

Bryan,

Audited SQL/MP tables such as this can have their partitions 'altered' online, which moves rows from one partition to another.
It reads like whoever defined these partitions either used an old distribution of the data, or took a guess that wasn't quite right.

Look in the SQL/MP Reference manual, in the ALTER TABLE section There are many options here, including ADD , MOVE , REUSE and DROP of a PARTITION.
You probably need to use MOVE.

These operations all work using a TMF transaction... with corresponding LOCKS on the table data.
This should be done by someone with good SQL/MP database management experience.

The first step is to determine what the ideal balance of primary key valuse in the table is, and whether the number of partitions is appropriate.

There is a fairly comprehensive description of how to allow this repartitioning to occur while processing continues, in the 'Considerations' portion of that part of the manual.
You should read that thoroughly and understand the impacts. There are some simple examples at the end of the ALTER TABLE section.

Bill

In regard to your question about whether deleting older data in the table will reduce the EOF, the answer is that doing so might reduce the EOF, but it depends on details of your data. If the older data has key values that make it fall into partition 1
of the table, then deleting that older data will free up space within partition 1. That will not directly reduce the EOF. However, after the older data has been deleted, you can use the FUP command RELOAD to compact the data that remains in the
partition, and that will reduce the EOF.

Both deleting the older data and the RELOAD can be done while the applications that use the table are up and running, so you should not have to disrupt normal operations for this.

Without knowing the characteristics of the data that is stored in that table, I cannot say whether deleting the old data will only be a temporary solution or will result in a long-term balancing of the data across the partitions of the table.

Pardon me if you have already done the following analysis, but let me point it out in case you have not.

The FIRST KEY value for partition 2 of the table looks suspiciously close to the FIRST KEY value for partition 3 of the table. It could be that whoever set up the table originally, either misunderstood how the values of the keys would be distributed, or
made some simple error in calculating the value for the FIRST KEY of partition 2. Note the FIRST KEY values:

null
"08", "510266020"
"08", "592108275" <--- this is the suspicious one
"08", "592108575"

If that FIRST KEY value for partition 2 actually should have been more nearly halfway between the value for partition 1 and partition 3, that could easily explain why too many rows have gone into partition 1 and very few have gone into partition 2.
Without knowing more about the data being stored in the table, I cannot say for sure that is the reason for the imbalance, but seems like a reasonable point to investigate.

That second column of the key is 19 bytes long, so the FIRST KEY value is specifying only the high-order 9 bytes of the key value. It might be true that taking the simple-minded approach of changing the "592108275" to something like "550000000" (roughly
halfway between the FIRST KEY of partition 1 and partition 3 would NOT be the correct choice. It might be that the data is such that a very large portion of the key values do begin with "08", "592108", and so the correct FIRST KEY value for partition 2
should only be a little smaller than what it currently is -- it depends on the distribution of the full key values.

If you do determine that a particular new value for the FIRST KEY value of partition 2 would result it a much more even balance of rows among the partitions, then Bill's suggestion of using the online version of the ALTER TABLE command probably would be
a good way to get the change made. There are some restrictions on the changes a single ALTER TABLE command can make, so sometimes a change requires multiple steps. Someone familiar with using ALTER TABLE for these kinds of table adjustments should be
involved.

The online version of ALTER TABLE can be performed while the applications that use the table are running normally, so this change also can be done without disrupting normal operations of the system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bryan,

Audited SQL/MP tables such as this can have their partitions 'altered' online, which moves rows from one partition to another.
It reads like whoever defined these partitions either used an old distribution of the data, or took a guess that wasn't quite right.

Look in the SQL/MP Reference manual, in the ALTER TABLE section There are many options here, including ADD , MOVE , REUSE and DROP of a PARTITION.
You probably need to use MOVE.

These operations all work using a TMF transaction... with corresponding LOCKS on the table data.
This should be done by someone with good SQL/MP database management experience.

The first step is to determine what the ideal balance of primary key valuse in the table is, and whether the number of partitions is appropriate.

There is a fairly comprehensive description of how to allow this repartitioning to occur while processing continues, in the 'Considerations' portion of that part of the manual.
You should read that thoroughly and understand the impacts. There are some simple examples at the end of the ALTER TABLE section.

Bill

Hi Bill,

Thank you for your comment and suggestion. I will forward this with our App team to look and consider your suggestions, I am new to Tandem/NonStop and don't have a knowledge with SQL/MP but I will try to look into the Manuals and see how the ALTER TABLE
works. Again thank you, Bill.

Cheers,

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <ec983910-0eb2-451d-bc79-4acec4d2b256n@googlegroups.com>, bryanpascua88@gmail.com says...

Bryan,=20
=20
Audited SQL/MP tables such as this can have their partitions 'altered' on= >line, which moves rows from one partition to another.=20
It reads like whoever defined these partitions either used an old distrib= >ution of the data, or took a guess that wasn't quite right.=20
=20
Look in the SQL/MP Reference manual, in the ALTER TABLE section There are=

many options here, including ADD , MOVE , REUSE and DROP of a PARTITION.=
=20

You probably need to use MOVE.=20
=20
These operations all work using a TMF transaction... with corresponding L= >OCKS on the table data.=20
This should be done by someone with good SQL/MP database management exper= >ience.=20
=20
The first step is to determine what the ideal balance of primary key valu= >se in the table is, and whether the number of partitions is appropriate.=20 >>=20
There is a fairly comprehensive description of how to allow this repartit= >ioning to occur while processing continues, in the 'Considerations' portion=

of that part of the manual.=20

You should read that thoroughly and understand the impacts. There are som= >e simple examples at the end of the ALTER TABLE section.=20
=20
Bill

Hi Bill,

Thank you for your comment and suggestion. I will forward this with our App=
team to look and consider your suggestions, I am new to Tandem/NonStop and= don't have a knowledge with SQL/MP but I will try to look into the Manuals= and see how the ALTER TABLE works. Again thank you, Bill.

Cheers,

Are you looking to re-partition the table for a better distribution
of rows or simply increase the size of each partition ?

Your MaxExtents is only 16 currently

-- set maxextents larger on a single partitions
alter table <partition name> partonly maxextents <nn>;

-- set maxextents larger on all partitions
alter table <table> maxextents <nn>;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, February 23, 2022 at 6:34:50 p.m. UTC-5, JShepherd wrote:

In article <ec983910-0eb2-451d...@googlegroups.com>,
bryanp...@gmail.com says...

Bryan,=20
=20
Audited SQL/MP tables such as this can have their partitions 'altered' on= >line, which moves rows from one partition to another.=20
It reads like whoever defined these partitions either used an old distrib= >ution of the data, or took a guess that wasn't quite right.=20
=20
Look in the SQL/MP Reference manual, in the ALTER TABLE section There are=

many options here, including ADD , MOVE , REUSE and DROP of a PARTITION.=
=20

You probably need to use MOVE.=20
=20
These operations all work using a TMF transaction... with corresponding L= >OCKS on the table data.=20
This should be done by someone with good SQL/MP database management exper= >ience.=20
=20
The first step is to determine what the ideal balance of primary key valu= >se in the table is, and whether the number of partitions is appropriate.=20 >>=20
There is a fairly comprehensive description of how to allow this repartit= >ioning to occur while processing continues, in the 'Considerations' portion=

of that part of the manual.=20

You should read that thoroughly and understand the impacts. There are som= >e simple examples at the end of the ALTER TABLE section.=20
=20
Bill

Hi Bill,

Thank you for your comment and suggestion. I will forward this with our App=
team to look and consider your suggestions, I am new to Tandem/NonStop and= don't have a knowledge with SQL/MP but I will try to look into the Manuals= and see how the ALTER TABLE works. Again thank you, Bill.

Cheers,

Are you looking to re-partition the table for a better distribution
of rows or simply increase the size of each partition ?

Your MaxExtents is only 16 currently

-- set maxextents larger on a single partitions
alter table <partition name> partonly maxextents <nn>;

-- set maxextents larger on all partitions
alter table <table> maxextents <nn>;

If there is a lot of dead space in the table (see DSAP), you can look into FUP RELOAD also.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, February 25, 2022 at 2:06:55 AM UTC+5:30, Randall wrote:

On Wednesday, February 23, 2022 at 6:34:50 p.m. UTC-5, JShepherd wrote:

In article <ec983910-0eb2-451d...@googlegroups.com>,
bryanp...@gmail.com says...

Bryan,=20
=20
Audited SQL/MP tables such as this can have their partitions 'altered' on=

line, which moves rows from one partition to another.=20

It reads like whoever defined these partitions either used an old distrib=

ution of the data, or took a guess that wasn't quite right.=20

=20
Look in the SQL/MP Reference manual, in the ALTER TABLE section There are=

many options here, including ADD , MOVE , REUSE and DROP of a PARTITION.=
=20

You probably need to use MOVE.=20
=20
These operations all work using a TMF transaction... with corresponding L=

OCKS on the table data.=20

This should be done by someone with good SQL/MP database management exper=

ience.=20

=20
The first step is to determine what the ideal balance of primary key valu=

se in the table is, and whether the number of partitions is appropriate.=20

=20
There is a fairly comprehensive description of how to allow this repartit=

ioning to occur while processing continues, in the 'Considerations' portion=
of that part of the manual.=20

You should read that thoroughly and understand the impacts. There are som=

e simple examples at the end of the ALTER TABLE section.=20

=20
Bill

Hi Bill,

Thank you for your comment and suggestion. I will forward this with our App=
team to look and consider your suggestions, I am new to Tandem/NonStop and=
don't have a knowledge with SQL/MP but I will try to look into the Manuals=
and see how the ALTER TABLE works. Again thank you, Bill.

Cheers,

Are you looking to re-partition the table for a better distribution
of rows or simply increase the size of each partition ?

Your MaxExtents is only 16 currently

-- set maxextents larger on a single partitions
alter table <partition name> partonly maxextents <nn>;

-- set maxextents larger on all partitions
alter table <table> maxextents <nn>;

If there is a lot of dead space in the table (see DSAP), you can look into FUP RELOAD also.

Hello Bry,

Please increase the maxextents of $DS03.PRDASQL.CMCMBRT to 25.

SQLCI
ALTER TABLE $DS03.PRDASQL.CMCMBRT PARTONLY 25;

After that, reload the table partition:
SQLCI
FUP RELOAD $DS03.PRDASQL.CMCMBRT,PARTOF $DS02,SLACK 0,DEALLOCATE,RATE 60;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, February 28, 2022 at 1:46:05 PM UTC+8, indra...@gmail.com wrote:

On Friday, February 25, 2022 at 2:06:55 AM UTC+5:30, Randall wrote:

On Wednesday, February 23, 2022 at 6:34:50 p.m. UTC-5, JShepherd wrote:

Hello All, thank you so much for your feed back. This helps a lot and I appreciate your inputs, the alter table command is a charm and it extends the maxextent of the table, however I would also like to know how can I distribute the data into the other
partition (Partition 2 $DS04.prdaSQL.CMCMBRT 0.2%) since this seems to be not in used by the application. Thank you again.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, March 16, 2022 at 6:06:21 AM UTC-7, Bry Pas wrote:

On Monday, February 28, 2022 at 1:46:05 PM UTC+8, indra...@gmail.com wrote:

On Friday, February 25, 2022 at 2:06:55 AM UTC+5:30, Randall wrote:

On Wednesday, February 23, 2022 at 6:34:50 p.m. UTC-5, JShepherd wrote:

Hello All, thank you so much for your feed back. This helps a lot and I appreciate your inputs, the alter table command is a charm and it extends the maxextent of the table, however I would also like to know how can I distribute the data into the other

partition (Partition 2 $DS04.prdaSQL.CMCMBRT 0.2%) since this seems to be not in used by the application. Thank you again.

In regard to distributing the data more evenly, I discussed that a bit in my earlier reply on February 22. Do you have specific questions about what I suggested in that reply? If so, please clarify your questions..

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)