Cisco Cisco Unified Contact Center Enterprise 9.0(2) Troubleshooting Guide
12
Troubleshooting Guide for Cisco Unified Contact Center Management Portal Release 8.0(1)
Use the following SQL script to update TB_IMP_TIDEMARK:
CREATE TABLE #TEMP (RESOURCE_INSTANCE_ID UNIQUEIDENTIFIER,
CATALOG VARCHAR (50))
INSERT #TEMP
EXECUTE ap_clu01_get_exony_db_resource_instance
DECLARE @v_RESOURCE_INSTANCE_ID UNIQUEIDENTIFIER
SELECT @v_RESOURCE_INSTANCE_ID = RESOURCE_INSTANCE_ID FROM
#TEMP
DELETE FROM TB_IMP_TIDEMARK
WHERE RESOURCE_INSTANCE_ID = @v_RESOURCE_INSTANCE_ID
INSERT TB_IMP_TIDEMARK (
CLUSTER_RESOURCE_ID,
TABLE_NAME,
RESOURCE_INSTANCE_ID,
TIDEMARK1,
TIDEMARK2,
TIDEMARK3,
TIDEMARK4)
SELECT
CLUSTER_RESOURCE_ID,
TABLE_NAME,
@v_RESOURCE_INSTANCE_ID,
TIDEMARK1,
TIDEMARK2,
TIDEMARK3,
TIDEMARK4,
FROM TB_IMP_TIDEMARK
CATALOG VARCHAR (50))
INSERT #TEMP
EXECUTE ap_clu01_get_exony_db_resource_instance
DECLARE @v_RESOURCE_INSTANCE_ID UNIQUEIDENTIFIER
SELECT @v_RESOURCE_INSTANCE_ID = RESOURCE_INSTANCE_ID FROM
#TEMP
DELETE FROM TB_IMP_TIDEMARK
WHERE RESOURCE_INSTANCE_ID = @v_RESOURCE_INSTANCE_ID
INSERT TB_IMP_TIDEMARK (
CLUSTER_RESOURCE_ID,
TABLE_NAME,
RESOURCE_INSTANCE_ID,
TIDEMARK1,
TIDEMARK2,
TIDEMARK3,
TIDEMARK4)
SELECT
CLUSTER_RESOURCE_ID,
TABLE_NAME,
@v_RESOURCE_INSTANCE_ID,
TIDEMARK1,
TIDEMARK2,
TIDEMARK3,
TIDEMARK4,
FROM TB_IMP_TIDEMARK
Audit data is not replicated through SQL Server but through the Unified
CCMP Replication system. When importer session files are replicated
from one side to another, they are bulk-loaded by the Data Import Server
into the database. As this process takes place, the Data Import Server logs
its progress into a series of state tables in the database.
CCMP Replication system. When importer session files are replicated
from one side to another, they are bulk-loaded by the Data Import Server
into the database. As this process takes place, the Data Import Server logs
its progress into a series of state tables in the database.
These importer state tables are replicated using standard SQL Server
replication but are uniquely identified on each side by a
RESOURCE_INSTANCE_ID. The system on each side uses these state
tables to track the arrival of new data into the database fact tables for
further processing.
replication but are uniquely identified on each side by a
RESOURCE_INSTANCE_ID. The system on each side uses these state
tables to track the arrival of new data into the database fact tables for
further processing.
TB_IMP_FCT_PARTITION is the base state table. This contains a
definition of all the fact table partitions that have been created on each
side. There are usually two identical rows in here, differentiated by
RESOURCE_INSTANCE_ID (one for each side). This table links to
TB_IMP_FCT_PARTITION_TIDEMARK and
TB_IMP_FCT_PARTITION_TIDEMARK_SLICE.
definition of all the fact table partitions that have been created on each
side. There are usually two identical rows in here, differentiated by
RESOURCE_INSTANCE_ID (one for each side). This table links to
TB_IMP_FCT_PARTITION_TIDEMARK and
TB_IMP_FCT_PARTITION_TIDEMARK_SLICE.
Unfortunately, when one database is restored to another side, these state
tables are no longer correct. As a result, data may exist in the fact
partitions in the restored database that the system is unaware of. The
following steps recover the state tables on the failed database. It is very
important that SQL Server replication is running while you perform these
steps.
tables are no longer correct. As a result, data may exist in the fact
partitions in the restored database that the system is unaware of. The
following steps recover the state tables on the failed database. It is very
important that SQL Server replication is running while you perform these
steps.