Toss/Create limits for the Type I Areas

Posted by George Potemkin on 13-May-2015 04:08

Documentation ("OpenEdge Data Management: Database Administration") says about proutil -C setTableTossLimit:

"For a Type II area, SETTABLETOSSLIMIT sets the table toss limit for the specified table. For a Type I area, SETTABLETOSSLIMIT issues a warning that all tables and LOBs in an area must have the same toss limit, and prompts you to confirm setting the toss limit for all tables and LOBs in the area containing the specified table."

The blocks in Type I area are "social", SAT1 has only one RM chain but nevertheless we can have two different Toss/Create limits in the same area:

Proutil -C setTableTossLimit updates the _StorageObject._Toss-Limit for all /existent/ table objects in the specified area. But when we will add new tables into the same area Progress will create for them the _StorageObject records with default values. Maybe it's just a bug. As result when we will create/update/delete the records in these tables Progress will use the _Toss-Limit of the correspondent table. So the different processes at the same time can use the different rules for the same RM chain.

Test that confirms this:

I created a database with SAT1:
d "My Area":7,32;1 .

I created the "t900" table in "My Area" and run:
proenv>proutil mydb -C setTableTossLimit t900 900
Object "t900" is in Type I area 7.
Toss limits for all tables and blobs in this area will be changed.
Do you want to continue? (11538)
y
Toss limit for object number 1 in area 7 set to 900. (12515)
Toss limit set to 900 for all tables and blobs in area 7. (12496)

Then I created the "t300" table in the same area:
proenv>proutil mydb -C dispTossCreateLimits 7
Table object number: 1, Toss Limit: 900, Create limit: 150. (12852)
Table object number: 2, Toss Limit: 300, Create limit: 150. (12852)

Then created a few records in t900 with record size less than Toss Limit of t900:

DEFINE VARIABLE i AS INTEGER     NO-UNDO.
&SCOPED-DEFINE tbl t900
REPEAT i = 1 TO 100:
  CREATE {&tbl}.
  ASSIGN {&tbl}.f = FILL("x", 600).
END.


proenv>proutil mydb -C chanalys "My Area"

          LIST OF RM CHAIN BLOCKS
                free    # free
        dbkey   space   slots   hold
        608     1592    28      0
1 block(s) found in the RM chain.

Then I did exactly the same for the "t300" table:

proenv>proutil mydb -C chanalys "My Area"

          LIST OF RM CHAIN BLOC
                free    # free
        dbkey   space   slots
        1152    2834    30
        704     350     26
        768     350     26
...
18 block(s) found in the RM chain.

proutil mydb -C dbrpr

1. Database Scan Menu
8. Rebuild RM Chain
10. Change Current Working Area

proenv>proutil mydb -C chanalys "My Area"

         LIST OF RM CHAIN BLOCKS
               free    # free
       dbkey   space   slots   hold
       96      312     24      0
       128     350     26      0
       160     350     26      0
       192     350     26      0
...
34 block(s) found in the RM chain.


In other words, proutil -C dbrpr added the blocks of the "t900" table to the RM chain. I.e. dbrpr used the default toss limit or more exactly dbrpr preferred to use the toss limit of the "t300" table (I don't know why it chose "t300"). When I run proutil -C setTableTossLimit to re-set all toss limits to 900 bytes and re-run dbrpr the utility has shrinked the RM chain down to one block.

Conclusion:
1) Don't use Type I areas.
2) If you use them (hopefully for unimportant data) then use the default Toss/Create limits to avoid the ambiguity.

Regards,
George

All Replies

Posted by Marie Candela on 13-May-2015 12:23
George,
 
Interesting.  What caused you to investigate this?
What release did you use to investigate?
 
-Marie
 
 
[collapse]
From: George Potemkin [mailto:bounce-GeorgeP12@community.progress.com]
Sent: Wednesday, May 13, 2015 5:09 AM
To: TU.OE.RDBMS@community.progress.com
Subject: [Technical Users - OE RDBMS] Toss/Create limits for the Type I Areas
 
Thread created by George Potemkin

Documentation ("OpenEdge Data Management: Database Administration") says about proutil -C setTableTossLimit:

"For a Type II area, SETTABLETOSSLIMIT sets the table toss limit for the specified table. For a Type I area, SETTABLETOSSLIMIT issues a warning that all tables and LOBs in an area must have the same toss limit, and prompts you to confirm setting the toss limit for all tables and LOBs in the area containing the specified table."

The blocks in Type I area are "social", SAT1 has only one RM chain but nevertheless we can have two different Toss/Create limits in the same area:

Proutil -C setTableTossLimit updates the _StorageObject._Toss-Limit for all /existing/ table objects in the specified area.

But when we will add new tables into the same area Progress will create for them the _StorageObject records with default values.

Maybe it's just a bug. As result when we will create/update/delete the records in these tables Progress will use the _Toss-Limit of the correspondent table. So the different processes at the same time can use the different rules for the same RM chain.

Test that confirms this:

I created a database with SAT1:
d "My Area":7,32;1 .

I created the "t900" table in "My Area" and run:
proenv>proutil mydb -C setTableTossLimit t900 900
Object "t900" is in Type I area 7.
Toss limits for all tables and blobs in this area will be changed.
Do you want to continue? (11538)
y
Toss limit for object number 1 in area 7 set to 900. (12515)
Toss limit set to 900 for all tables and blobs in area 7. (12496)

Then I created the "t300" table in the same area:
proenv>proutil mydb -C dispTossCreateLimits 7
Table object number: 1, Toss Limit: 900, Create limit: 150. (12852)
Table object number: 2, Toss Limit: 300, Create limit: 150. (12852)

Then created a few records in t900 with record size less than Toss Limit of t900:

DEFINE VARIABLE i AS INTEGER     NO-UNDO.
&SCOPED-DEFINE tbl t900
REPEAT i = 1 TO 100:
  CREATE {&tbl}.
  ASSIGN {&tbl}.f = FILL("x", 600).
END.


proenv>proutil mydb -C chanalys "My Area"

          LIST OF RM CHAIN BLOCKS
                free    # free
        dbkey   space   slots   hold
        608     1592    28      0
1 block(s) found in the RM chain.

Then I did exactly the same for the "t300" table:

proenv>proutil mydb -C chanalys "My Area"

          LIST OF RM CHAIN BLOC
                free    # free
        dbkey   space   slots
        1152    2834    30
        704     350     26
        768     350     26
...
18 block(s) found in the RM chain.

proutil mydb -C dbrpr

1. Database Scan Menu
8. Rebuild RM Chain
10. Change Current Working Area

proenv>proutil mydb -C chanalys "My Area"

         LIST OF RM CHAIN BLOCKS
               free    # free
       dbkey   space   slots   hold
       96      312     24      0
       128     350     26      0
       160     350     26      0
       192     350     26      0
...
34 block(s) found in the RM chain.


In other words, proutil -C dbrpr added the blocks of the "t900" tables to the RM chain. I.e. dbrpr used the default toss limit.

Conclusion:
1) Don't use Type I areas.
2) If you use them (hopefully for unimportant data) then use the default Toss/Create limits to avoid the ambiguity.

Regards,
George

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]
Posted by George Potemkin on 13-May-2015 12:52

Marie,

I used V10.2B for tests.

It was just a curiousity. I has wrote a program that reports (among other things) the Toss/Create limits for the tables. The program can be run against a database with SAT1. So my primary question was which _StorageObject record to choose to report the Toss/Create limits for SAT1.

Kind regard,

Curious George

Posted by gus on 03-Jun-2015 16:02

maybe it is a bug that you are using type 1 data areas. :)

This thread is closed