Systemstatistik nicht synchron

Question

Ich habe zwei Datenbanken, die sich in einer Verfügbarkeitsgruppe befinden, eine als primäres Replikat und die andere als sekundäre. Ich habe eine Speicherprozedur, die den folgenden Fehler zurückgibt.

DBCC-Ausführung abgeschlossen. Wenn DBCC Fehlermeldungen gedruckt hat, wenden Sie sich an Ihren Systemadministrator. Meldung 2767, Ebene 16, Status 1, Prozedur xxxx.sys.sp_table_statistics2_rowset, Zeile 105 [Stapelstartzeile 2] Die Statistik '_WA_Sys_00000026_0143D405' konnte in den Systemkatalogen nicht gefunden werden. DBCC-Ausführung abgeschlossen. Wenn DBCC Fehlermeldungen gedruckt hat, wenden Sie sich an Ihren Systemadministrator.

wenn ich die folgende Abfrage auf meinem sekundären Replikat ausführe (schreibgeschützt):

SELECT OBJECT_NAME(s.object_id) AS object_name
    , COL_NAME(sc.object_id, sc.column_id) AS column_name
    , s.name AS statistics_name  
FROM sys.stats AS s 
INNER JOIN sys.stats_columns AS sc ON s.stats_id = sc.stats_id AND s.object_id = sc.object_id  
WHERE s.name like  '%_WA_Sys_00000026_0143D405%'
ORDER BY s.name;

Die Statistik erscheint:

STOJOU QTYPCU_0          _WA_Sys_00000026_0143D405
STOJOU QTYPCU_0          _WA_Sys_00000026_0143D405_readonly_database_statistics

Wenn ich die Abfrage auf dem primären Replikat ausführe, wird sie nicht in den Systemtabellen angezeigt, aber wenn Sie unter die Tabelle STOJOU schauen, wird sie angezeigt.

Wie kann ich die Statistiken zwischen meinen beiden Systemen neu erstellen und / oder neu synchronisieren? Ich kann die Statistik auf meiner Primärdatenbank nicht löschen oder erstellen. Muss ich meine Synchronisation zwischen primär und sekundär beenden, um dies zu beheben? Danke für deine Hilfe.

Answer 1

Dies ist ein herausragender Fehler in SQL Server , der leider seit einiger Zeit ignoriert wird.

Sie können die fehlerhafte Statistik aufspüren und löschen / neu erstellen oder wie einige andere im obigen Thread vorgeschlagen haben:

Das Löschen der mit userstore_dbmetadata verbundenen Pools beim ASYNC-Commit behebt das Problem. DBCC FREESYSTEMCACHE (‘dbname’)

Oder erstellen Sie eine gespeicherte Prozedur, um zu überprüfen, ob es sich bei der Instanz um ein ASYNC-Commit handelt, und leeren Sie dann den Cache mithilfe eines Agentenjobs.

CREATE PROCEDURE [dbo].[sp_clear_dbmetadatacache]
AS
SET NOCOUNT ON
DECLARE @dbname SYSNAME
DECLARE @linebreak AS VARCHAR
SET @linebreak = CHAR + CHAR

CREATE TABLE #dbcc
(
command VARCHAR
)

DECLARE db_cursor CURSOR FOR
SELECT DISTINCT name
FROM sys.sysdatabases db
INNER JOIN sys.dm_hadr_database_replica_cluster_states dbcs
ON db.name = dbcs.database_name
OPEN db_cursor
FETCH NEXT FROM db_cursor INTO dbname WHILE @FETCH_STATUS = 0
BEGIN
CREATE TABLE #avmode
(
availability_mode_desc VARCHAR
)
DECLARE value AS VARCHAR(20) DECLARE @sqlcmd2 AS NVARCHAR(150) SET @sqlcmd2 = 'SELECT DISTINCT availability_mode_desc FROM sys.availability_replicas WHERE replica_server_name = @SERVERNAME’
INSERT INTO #avmode
EXECUTE sp_executesql @sqlcmd2
SELECT @value = availability_mode_desc
FROM #avmode
BEGIN
IF @value = ‘ASYNCHRONOUS_COMMIT’
GOTO A
ELSE
GOTO B
END
A:
DECLARE @sqlcmd AS NVARCHAR
SET @sqlcmd = ‘DBCC FREESYSTEMCACHE (’‘’ + @dbname +’‘’) ’+ @linebreak + ’GO’
INSERT INTO #dbcc EXECUTE sp_executesql @sqlcmd
—PRINT @sqlcmd
B:
DROP TABLE #avmode
FETCH NEXT FROM db_cursor INTO @dbname;
END
CLOSE db_cursor;
DEALLOCATE db_cursor;

GO