| How is content stored in the JCR tables, nodes, and UUIDs?
Content is stored in the repository against a complex schema of interrelated tables. For each node within a workspace it is modeled via the following tables at a minimum:
- ICMSTJCRWSNODES
- ICMSTJCRLINKS
- ICMSTJCRNODELOCKS
- ICMSTUT00XXXX (for each nodetype it will have information stored in it)
Each node is modeled through a graph of information stored across multiple tables. For this reason, deleting a node is not such a simple matter as removing one row from a table in the database. The interrelated connections between all of the tables must be handled. In many cases, the level of logic required is not encoded in any singular SQL command that can be sent to the database.
Does IBM publish the JCR database schema?
No. The data in the JCR is separated across several tables in the database. There is no simple correlation between the WCM objects and database tables or rows.
What data can be safely deleted from the database without causing corruption?
In most cases there is not simply a SQL statement that can be constructed to fix an application issue. The context or semantics for functions are encoded in the application and not the database itself.
How many characters are allowed for a user ID in JCR?
For Portal 6.0.1.x and earlier, there is a limit of 32 characters for user ID's which are using JCR.
For Portal 6.1 and later, the user ID length can be up to 175 characters.
Can you synchronize PDM Document libraries between two servers?
You can use PDM Staging to Production to upload PDM data to a production server. However, you cannot use Staging to Production for complete synchronization, as it requires the user to manually synchronize deletes, renames, and moves.
If restoring databases from backup, do we need to restore all Portal/JCR databases at once?
Yes. It is a best practice to always backup and restore all of the databases at the same time.
Can you share the same JCR database between two different portal (non-clustered) instances?
No. This is not possible unless the schema names are different.
Can you share the same JCR database when the schema names are different?
Yes. Provided that the schema names are unique for each portal instance.
When using the same JCR database with different schemas, the schemas will use the same tablespaces, but different tables/indexes.
You will notice that during the DBTransfer task for the first portal instance, there are 5 tablespaces ICMSFQ04, ICMLNF32, ICMLFQ32, ICMVFQ04 and ICMLSNDX which are created and required for JCR. These tablespace names are hard coded in the script and cannot be changed. The task also creates the necessary tables and indexes in these tablespaces for schema 1. When the DBTransfer is run for the second portal instance, a second set a tables and indexes will be created in these same tablespaces, but these tables and indexes will be for schema 2.
What is the use of icmjcradminwar?
The icmjcradminwar includes a number of functions that are used by the content repository. The primary function however is the InitServlet. The InitServlet is loaded to initialize the content repository for usage by applications.
As part of this initialization, the cache of node types within the system must be initially prepared. This cache is a large cache that requires multiple reads against the tables of the repository. As such, it does take a while for the cache to be loaded.
Due to this time, rather than make the first application request encounter this delay, the InitServlet experiences the delay during the server startup.
This behavior is by design and the application should not be disabled as several of the core portal functions depend upon the content repository.
|