In general, the Content Server creates default database tables in default table spaces but it's also possible to define custom table spaces for specific content categories.

Configuring a table space for blob data

The binary content of blobs stored in the CoreMedia CMS has different access characteristics than other content properties: it usually read from beginning to end as a stream, and blobs are generally too large to be cached in database main memory. Therefore, you may want to store blob data in a different table space than other tables automatically created by CoreMedia CMS.

The required settings depend on the type of database in use and are described in this chapter for all supported databases. The settings described are only basic configuration steps. When tuning is required, a database administrator has to be involved.

Generally, the Content Server creates the table holding blob data when you start it first. You can augment the DDL create statement used by the Content Server's SQL scripts with own extensions. Use the property db.blob-table-options in the database specific property file (properties/corem/mysql.properties, for example).

By default, this property is commented out, causing the database to select a default table space. The commented line shows the syntax of the relevant SQL fragment for the respective database.

Caution

The property db.blob-table-options only takes effect on the first startup of the content server.

Oracle

The supplied SQL fragment is appended in the LOB STORE AS clause. The example syntax below refers to a table space myBlobTablespace for holding the actual blob data.

db.blob-table-options=TABLESPACE myBlobTablespace

MS SQL

The supplied SQL fragment is appended at the end of the CREATE TABLE statement. The example syntax below refers to a table space myBlobTablespace for holding the actual blob data.

db.blob-table-options=TEXTIMAGE_ON myBlobTablespace

Configuring tablespaces and index tablespace for content tables

Content type specific tables vary considerably in their size and access frequency. Therefore, it might make sense to distribute them across different table spaces. Also, databases allow you to store indexes in a different table space than the original data.

The SQL DDL statements for content type specific tables are created automatically by the Content Server. To control these statements, set the attributes Tablespace and IndexTablespace in your doctypes.xml file.

Selecting a table space per content type

To select the table space for a content type specific table, set the attribute Tablespace on the respective content type's definition. The example uses a table space bigTablespace for the tables of content type Article.

<DocType Name="Article" Tablespace="bigTablespace">
  ...
</DocType>

Selecting an index table space per content type

To select the table space for a content type's primary key index and auxiliary indexes created by the Content Server, set the attribute IndexTablespace on the respective content type's definition. This also configures the default table space for all indexes created on content properties of the respective content type. The example uses a table space quickTablespace for the index tables of the content type Article.

<DocType Name="Article" IndexTablespace="quickTablespace">
  ...
</DocType>

Selecting an index table space per property

To select a table space for an index on an indexed content type property, set the attribute IndexTablespace on the respective property's definition. This is only possible for String, Integer, and Date properties, but not for XML, blob and link list properties. The example uses the table space quickTablespace for the index tables of the property ArticleCode of the content type Article.

<DocType Name="Article">
  <StringProperty Name="ArticleCode" Length="20" Index="true" 
    IndexTablespace="quickTablespace"/>
  ...
</DocType>