Hello.
We are adding some extents to our DB. I've done this in a test environment, but want to confirm the size of the variable extent that was created is correct based on the values used in the structure file.
We are currently using 4K block size and the variable extent being added reads, "table_idx":208,1;8 /test/db/. How do you calculate the size it should be created? I found this link, https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dmadm/extent-length.html#wwconnect_header, which helped me calculate some of the variable extends but having an issue with this one.
Thanks in advance for your help!
I'm assuming it's a terminology thing, but you don't set sizes for variable extents. They are variable.
Thanks for responding James. You are correct that variable extents are not created to a fixed size. What I am asking about is the initial allocation for a variable-length extent. In the example I provided, the extent was created as 64K but I have some others such as "table2":104,128;512 /test/db/ that get created as 2MB. How do you calculate what the initial extent size will be created as?
When you use Type II areas the minimum size of an extent is the cluster size times the block size. For the table2 area you have specified a 512 block cluster size for a 4K database block size so you get a 2MB extent.
If you use a cluster size of 1 (the default) then you can assume a 64K extent for a 4K block size.
> On Aug 22, 2016, at 12:11 PM, Keith Sudbury wrote:
>
> If you use a cluster size of 1 (the default) then you can assume a 64K extent for a 4K block size.
>
>
>
DO NOT DO THIS.
cluster size 1 is a typ i data area. no one should be using those for any purpose.
Well yeah... as soon as you make the Schema Area Type II I won't have any Type I areas anywhere :-)
Thanks Keith for your help. I really do appreciate it! I will save this info for future reference.
Thanks Gus for the info on the type 1 storage areas.
> On Aug 22, 2016, at 2:08 PM, Keith Sudbury wrote:
>
> Well yeah... as soon as you make the Schema Area Type II I won't have any Type I areas anywhere :-)
>
>
>
true. but making the schema area type ii gives approximately zero benefit to anyone and it would be a /lot/ of work.
any other project would be more valuable.
I mostly agree with you Gus. The one exception would be the SQL statistics tables. For a large MT environment the SQL stats tables can get quite large and quite fragmented. Especially for column based stats.
Also pinning all of the schema objects to B2 is more of a pain once you have several GBs of stats that keep growing as new tenants are added.
There are many other things on our wish list that should come before that though :-)