First, run "prostrct list dbname" against your database to ensure your structure file is current. The schema area is always area number 6, and application areas are 7 and above. In the structure file the line for the schema area should look something like this:
Code:
d "Schema Area":6,64;1 /path_to_db/dbname.d1
If you have an area called "default" it is an application area. if you run "proutil dbname -C dbanalys > output_file" you will get a report that gives you the mapping of storage objects (tables/indexes) to storage areas. If the variable extent of the "default" storage area is growing, there are a couple of approaches you can take to find what is growing.
One is easy, if tedious. By this point you have run the dbanalys report, which shows you record counts for each table. After some period of time you deem appropriate, run another one (to a different file). Compare the outputs, concentrating on the tables in the "default" area. Import the data into Excel if that helps you, remembering that some lines in the dbanalys report may wrap to two lines if the table name is long. If one table has a large delta from one report to the next, it is likely the culprit.
The second method would involve starting the database with the -tablerangesize startup parameter, setting it high enough for all the application tables in your database. Then you can write some ABL code to pull out the create, read, update, and delete stats from the _TableStat VST (at this point you care about creates, and maybe updates). Once you know the table that is growing, you can also query the _UserTableStat VST to see if a particular user or batch job is the cause of the growth. If this sounds confusing, the first approach is the way to go for you.
Also check the value of the records per block for this storage area in the structure file. It is the value after the comma. If it is set too low, then your storage area consuming disk space unnecessarily by storing partially-empty blocks. If this is a multi-table area, a value of 128 would be your best bet. Typically this value is tuned based on the tables' mean record size (also reported by dbanalys), but this is usually not feasible when there are multiple tables. If the value of RPB is very low, like 1, this can cause very rapid growth and needs to be addressed. You can't change the RPB value of an existing storage area; all you can do is create a new area with the desired RPB and move your data into it.
If you have one table that is growing rapidly, it is a good idea to put it in its own storage area so you can manage it more easily and tune the area to its data characteristics. In the meantime, if you feel that extend operations are slowing you down, add another fixed extent to the "default" area so you will not be extending constantly.
One other thing: check that you have large file support enabled in your database. If you don't, when the variable extent reaches 2 GB in size it won't be able to grow anymore and your DB will shut down. Run "proutil dbname -C describe" and check for feature ID 5, "Large Files". If it's not there you can enable it with "proutil dbname -C enablelargefiles", provided you have an Enterprise RDBMS license.
For more on all things storage optimization, please read
Storage Optimization Strategies by our friend TomB.
