The following error is seen in the server log shortly after the entry Initializing context = clearwell
2015-04-27 09:20:46,964 DETAIL [cluster.locator.consistency] (clusterupdateservice.clusterupdateservice:) Unable to validate database instance esadb_lds_index_258867348$1
com.teneo.esa.common.database.PersistenceException: [#81042] Query failed. Operation=findByQuery failed because of an hibernate exception, args={1.EN_US}
at com.teneo.esa.common.database.PersistenceHelper.throwPersistenceException(PersistenceHelper.java:258)
at com.teneo.esa.common.database.PersistenceManagerImpl.findByQuery(PersistenceManagerImpl.java:395)
at com.teneo.esa.common.database.PersistenceManagerImpl.findByQuery(PersistenceManagerImpl.java:359)
at com.teneo.esa.common.database.PersistenceManagerImpl.findByQuery(PersistenceManagerImpl.java:577)
at com.teneo.esa.common.database.MTBatchPersistanceManager.findByQuery(MTBatchPersistanceManager.java:392)
at com.teneo.esa.cluster.DataStoreMetaDataImpl.fetch(DataStoreMetaDataImpl.java:372)
at com.teneo.esa.cluster.DataStoreLocatorImpl$1.execute(DataStoreLocatorImpl.java:554)
at com.teneo.esa.cluster.DataStoreLocatorImpl$1.execute(DataStoreLocatorImpl.java:551)
at com.teneo.esa.common.database.Transaction.execute(Transaction.java:79)
at com.teneo.esa.common.database.Transaction.transact(Transaction.java:126)
at com.teneo.esa.common.database.Transaction.transactInternal(Transaction.java:110)
at com.teneo.esa.common.database.Transaction.transact(Transaction.java:104)
at com.teneo.esa.cluster.ClusterServiceBase$TransactionT1.transact(ClusterServiceBase.java:298)
at com.teneo.esa.cluster.ClusterServiceBase$TransactionT1.transact(ClusterServiceBase.java:310)
at com.teneo.esa.cluster.DataStoreLocatorImpl.getMetaData(DataStoreLocatorImpl.java:551)
at com.teneo.esa.cluster.DataStoreLocatorImpl.validateMetaData(DataStoreLocatorImpl.java:568)
at com.teneo.esa.cluster.ClusterUpdateService.refreshLocatorState(ClusterUpdateService.java:1788)
at com.teneo.esa.cluster.ClusterUpdateService.checkConsistency(ClusterUpdateService.java:507)
at com.teneo.esa.cluster.ClusterUpdateService.createServiceInternal(ClusterUpdateService.java:189)
at com.teneo.esa.cluster.ClusterServiceBase.createService(ClusterServiceBase.java:69)
at com.teneo.esa.admin.service.AbstractService$1.call(AbstractService.java:1289)
at com.teneo.esa.admin.service.AbstractService.ensureExclusive(AbstractService.java:1456)
at com.teneo.esa.cluster.ClusterServiceBase.ensureExclusive(ClusterServiceBase.java:233)
at com.teneo.esa.admin.service.AbstractService.create(AbstractService.java:1284)
at com.teneo.esa.admin.service.AbstractService.doRun(AbstractService.java:1135)
at com.teneo.esa.admin.service.AbstractService.run(AbstractService.java:1083)
at java.lang.Thread.run(Thread.java:662)
The following errors are seen in the MySQL log file D:\MySQLData\data\:
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Error: the size of single-table tablespace file .\esadb_lds_index_258867348@00241\t_data_store_meta_data.ibd
InnoDB: is only 0 0, should be at least 65536!
InnoDB: Error: the size of single-table tablespace file .\esadb_lds_index_258867348@00241\t_data_store_meta_data_ext1.ibd
InnoDB: is only 0 0, should be at least 65536!
InnoDB: Error: the size of single-table tablespace file .\esadb_lds_index_258867348@00241\t_data_store_temp_meta_data.ibd
InnoDB: is only 0 0, should be at least 65536!
InnoDB: Error: the size of single-table tablespace file .\esadb_lds_index_aomccze4af\a_lucene_uninvert_pivot.ibd
InnoDB: is only 0 0, should be at least 65536!
InnoDB: Error: the size of single-table tablespace file .\esadb_lds_index_aomccze4dn\a_lucene_uninvert_blobs_shadow.ibd
InnoDB: is only 0 0, should be at least 65536!
...
InnoDB: Error: table 'esadb_lds_index_258867348@00241/t_data_store_meta_data'
InnoDB: in InnoDB data dictionary has tablespace id 42065,
InnoDB: but tablespace with that id or name does not exist. Have
InnoDB: you deleted or moved .ibd files?
InnoDB: This may also be a table created with CREATE TEMPORARY TABLE
InnoDB: whose .ibd and .frm files MySQL automatically removed, but the
InnoDB: table still exists in the InnoDB internal data dictionary.
InnoDB: Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting-datadict.html
InnoDB: for how to resolve the issue.
Cause
Many factors can cause this condition. According to the MySQL Reference Manual, these errors can occur when "the server crashes in the middle of a data dictionary operation", resulting in the ".frm" and ".ibd" files becoming out-of-sync. It may also be caused by security software, such as anti-virus, interfering with MySQL write transactions.
Recommended list of antivirus exclusions for Veritas eDiscovery Platform
Unable to log into eDiscovery Platform with MySQL timezone error
Depending on which particular eDiscovery case database(s) is affected by the issue, services may or may not start up successfully.
If eDiscovery eventually starts up successfully, Veritas eDiscovery Support can help match the affected databases mentioned in file D:\MySQLData\data\.err to the corresponding eDiscovery cases. A recent case backup of the case(s) can then be restored to correct the issue.
If eDiscovery does not completely start up, it may be necessary to restore the most recent appliance backup to correct the issue.
"Please wait while the Clearwell appliance finishes its initialization"