Version 9 Storage Areas

---

[Background] [Version 9 Features] [Backup Considerations] [Conversion Issues] [Conclusion]

Progress Software have now released Progress Version 9. Many enhancements have been introduced into Version 9 some of them are shown below:

• Scalability of the number of user connections has been increased to allow from a single user to over 10,000 users.
• Many off-line operations have been made available as on-line operations.
• Many performance improvements have been made throughout the complete product range.
• The introduction of a Native SQL-92 interface to the database
• The introduction of a cost based SQL Query optimiser
• Stored Procedures for the Database

One very useful improvement has been made to the Progress Database Engine. This improvement is the introduction of ‘Storage Areas’.

Background

In the past Progress has allowed us to have either a single or a multi-volume database.

A single volume database resides on the disk in a single database file. This file name is the name of the database suffixed with a ‘.db’ extension. E.g. sports.db

This file can only grow to a size that is permitted by the operating system, the maximum size that these files can be is 2 Gigabytes or the limit set by the physical disk that is available.

e.g. 512 Megabyte disk.

So that the size of the database is not constrained by this limitation it is possible to create a database which has more than one file to contain the database information. These are known as Multi-volume databases. Each of these database files are called extents, each extent has a filename consisting of the database name with a suffix of the extent number. e.g. .d1 .d2 .d3 .d4 etc. Each extent can be up to 2 Gigabyte in size as described above.

Within Version 9 of Progress all databases must be multi-volume, however you can have a multi-volume database with only one variable extent if you wish.

Version 9 Features

By using existing multi-volume extents we can create a database that can be up to 200 Gigabytes (depending on the operating system). However this quantity of information is not easy to manage. It also may not be large enough for our application. To resolve these issues a new feature has been incorporated into the Progress database engine. This new feature is called ‘Storage Areas’.

‘Storage Areas’ allow databases to be created that have many more extents than was possible under previous versions of Progress. For instance if you created a database in Version 9 that contained 100 storage areas it would be the equivalent of having a hundred Version 8 multi-volume databases. This would allow you to have a database of over 6,000 Gigabytes when using a 1k block size for the database. The maximum size that the database can now reach is 15 Petabytes (Very Big!).

Storage areas are not only for databases of this magnitude. With storage areas you get other features that can be very useful even for smaller databases.

The new storage area architecture allows the administrator of the database to specify which storage area they wish to use to store a specific table or index.

You could, for instance:

• Locate tables that do not change often in one storage area (i.e. historic files that do not get updated, only added to) and tables that change often in a different storage area, you can dump and reload only the tables that will have become fragmented over time, enhancing the general system performance and simplifying maintenance tasks

• Alternatively the indexes for all or some of the tables can be stored in a different location which had faster disks providing increased performance. If you decided that the indexes required re-building the process would be much faster. By separating the indexes into a number of storage areas the rebuild process could be significantly improved.

Each storage area can be dumped and reloaded independently of each other, greatly simplifying the administration of a large database.

Just about any combination or split of files and indexes can be created providing many combinations that are only limited by your imagination.

Backup Considerations

When backing up a database it is important that all the relevant files are backed up. This used to be reasonably easy with Version 8 of Progress, all the database related files were prefixed by the database name and suffixed by the relevant extension.

With Version 9 and the addition to the product of ‘Storage Areas’ the prefix now also contains the storage area reference number (e.g. sports_12.d1, sports_12.d2 – for storage area 12).

These files are part of the main database and must be backed up with the other files.

If the Progress backup utility (probkup) is used then all these files will be backed up automatically.

Conversion Issues

Your version 8 databases can be converted to Version 9 using ‘proutil’. But, it will only work on an existing multi-volume database. As I said above, all Version 9 databases must be multi-volume. So if you are still using a single volume database, then do not worry. Convert your existing single-volume database to a multi-volume database and the conversion can begin.

A converted database will however locate all the tables and indexes into the same ‘storage area’. So to make best use of the new architecture the tables and indexes will have to be moved. Progress have created utilities to perform these tasks and they can be done on-line.

If you have the time, it may be more practical to perform a dump and reload into Version 9. By performing the dump and reload and making sure that the new database schema has been setup appropriately the data can be reloaded straight into your new database architecture.

Conclusion

There are many other new features that I have not mentioned above which all add to the performance and manageability of the database. Should you upgrade to Version 9 to run your database?

Yes. Even with small databases of a few hundred megabytes you will get benefits from upgrading. Don’t jump in - plan the layout of your database relating it to the files that you are using within your application. Don’t create too many storage areas you will have to administer them all.

Investigate the other features available. Use variable block sizes, these can be specified on a per storage area basis depending on the content of your tables.

Finally, have you recently split your database into two databases in an attempt to alleviate administration tasks, it may be beneficial to put them back into one database. If your transactions span more than one database and you are not using two phase commit, then you should either enable two phase commit or move back to a single database. Problems may be just round the corner.

© Copyright Proxcom Limited 1999 - All Rights Reserved

[Top] [Background] [Version 9 Features] [Backup Considerations] [Conversion Issues] [Conclusion]