Ever faced a MaxDb database with lots of small data files? We did. Due to the archiving of several documents and document types, the MaxDb of the Content Server kind of exploded in size. At first, 1 Gb files were added. then 2GB, 4 Gb, … Now that the bulk of the archiving is done, the Content Server database doesn’t grow exponentially anymore. But we have now ‘a lot’ of ‘small’ files:
Screenshot taken from Database Manager 7.6
Same database, but screenshot taken with the new MaxDB Studio
The goal of this document is to show you how to re-organize the files online.
In 2 words: delete the data file (Maxdb will distribute the data over the other data files if you want) and recreate new (bigger) data files.
According to SAP “Note 1173395 – FAQ: MaxDB Configuration”:
Please keep in mind that such operations always carry some risk, and be sure that the necessary precautions are taken (restorable backup available; although online, I suggest to execute the reorganization at moments of low load).
This said, we will show you how to resize the data files. The next screenshots in this document are taken on a quality system named IQ5.
MaxDB Database Manager was used, but I’m sure this will work also in the new MaxDB Studio.
Step 1 – Analysis of Initial data file situation
In the Database Manager, logon to the database (as CONTROL or SUPERDBA, or your own defined MaxDB Admin). go to Information –> Data Area
Remark: DATA0001 was already deleted.
==> Our goal is to replace all the 1, 2 and 4Gb files with 3 new files of 8 Gb.
Before you continue, make sure you have a fresh cup of coffee.
Step 2 – Reorganize (small) data file(s)
Before deleting a data file, check its current usage, and check if the amount of data can be spread over the remaining data files. If required, create a new data file first.
In our case, enough space is free in DATA0011/12/13
Go to Configuration –> Volumes
Right-mouse click on the data file you want to delete, and select ‘Delete’
We’ll assume we still need the data 😉
Now, you can sit back and enjoy your coffee for a few minutes.
As a result, DATA0002 is now gone:
Is data really spread over the other volumes? Well, check via Information –> Data Area –> Usage
and compare with the screenshot taken in Step 1.
Before repeating this step for DATA0003/4/5/6/7/8/9, I created a new DATA0001 of 8Gb.
Remark: check/adapt the ‘Device/File’ name, as the default ‘DATA0001′ will probably not be the desired value.
Usage of the data files now:
Ok, now we can delete the DATA0003/4/5/6/7/8/9, and recreate a DATA0002/3 of 8Gb.
After some coffee cups, the situation of the data files is now:
For aesthetic reasons, one could recreate DATA0004/5/6, and drop DATA0011/12/13. But the mechanism stays the same.
What happens if there is not enough space in the remaining data files?
Woops, restore ….
No, just kidding. The developers did a good job, and issue a warning (okay, not a very clear one):
But at least the file is not removed 🙂