Share this page
Database Sizing
The only sizing impact of using PPM Database DMS or PPM External Database DMS is in your Database Server, as everything happens in the database.
Database Disk Space
The database disk space consumed by PPM Database DMS or PPM External Database DMS can be split into three different parts:
-
Space taken up by Document contents (about equal to total documents size)
-
Space taken up by Documents metadata (proportional to number of documents and propensity of PPM users to input lengthy documents descriptions, key words, and version comments.
-
Space taken up by TEXT Indexes
-
Index on document contents, proportional to total size and types of documents (index on pure text file such as a logs file might take more space than the file itself, while index on a picture file, even very large, does not take any space as no text content can be extracted from the picture).
-
Index on text metadata, proportional to the size of metadata (as all indexed metadata is text and can be indexed).
The PPM DMS Statistics & PPM Database DMS Sizing tool available from PPM Support automatically estimates the extra disk space needed in database to migrate an existing PPM Server environment to either of the database-based DMS solution. The tool computes estimates based on quantity of documents, total size of documents, and types of documents. All this information are retrieved from the KNTA_DOCUMENTS table of PPM database.
The tool can also provide estimates for new PPM installations, based on user's input on planned usage of documents in PPM (estimated total number and size of documents, text concentration of stored documents).
Customer Case
Here is an example of Database Space consumption from an existing PPM customer who used a Documentum-based DMS solution previously. Customer documents statistics lists customer documents statistics, and Customer Case: Document repartition by type lists detailed document repartition information.
Text-only documents contain high level text contents, Microsoft Office documents contain medium level text contents, and images as well as binary documents contain practically no text content. This is reflected in the document contents index size.
Text Index creation time: ~ 6 hours (on a 2-instance RAC server with 4 x Dual Core CPU Intel(R) Xeon(R) E5540 @ 2.53GHz per instance).
Disk space consumed by PPM Database DMS:
|
Item |
Disk Space Consumed (MB) |
|---|---|
|
Documents binary contents (BLOB Columns) |
32,041 |
|
DMS Tables without BLOB columns (not including KNTA_DOCUMENTS): |
30 |
|
Total Metadata Indexes |
21.7 |
|
Document Contents Indexes |
6,011 |
As you can see, the size of document contents index (~6 GB) accounts for almost 20 percent of the documents contents size (~32 GB). This is a relatively ratio, which can be explained by the large amount of office documents in the customer's attachments.
It might be possible that the index size is larger than the document contents if all the attachments are pure text files (such as .txt, .sql, and .log files).
Caution: The BLOB columns containing the documents are appearing slightly smaller than the estimated total size of documents (15 MB smaller). The reason is that the total size of the documents is an estimation, computed using "Versions count * file size of latest version" for each document. It appears that the earlier versions of documents are smaller in size in average, resulting in the observed discrepancy.
Database Server CPU
If you have no plan to enable full-text search (or more precisely, if you do not need to create TEXT indexes), there is virtually no impact on database CPU, as reading and writing documents contents to database are mainly I/O intensive operations.
If you do create TEXT indexes, but schedule them to be updated only out of peak hours, there should be no need to consider an upgrade of DB Server CPU based on standard PPM sizings.
However, if you are using frequent index updates, or use SYNC (ON COMMIT) indexes for real time indexing, a CPU upgrade of your DB Server might be necessary, especially if your PPM users tend to store a large amount of text intensive files in PPM (more than 1 GB of new documents per week, with peak document activity concentrated on a few hours in the week).
