SQL Server-Datensatz in schreibgeschützter Dateigruppe aktualisiert?

8

Ich habe eine sehr große Datenbank in unserem Data Warehouse, in der wir Partitionierung implementiert haben, um Wartung und Backups zu verwalten. Datensätze eines bestimmten Alters werden schließlich einmal im Monat in eine schreibgeschützte Dateigruppe migriert.

Gelegentlich versucht unser ETL-Prozess, ältere Datensätze zu aktualisieren, die bereits in das Archiv migriert wurden, und wir erwarten, dass diese fehlschlagen. Ich habe jedoch mindestens zwei aktuelle Beispiele, bei denen der Datensatz im Test aktualisiert wird, selbst wenn er sich in einer Partition in der schreibgeschützten Dateigruppe in unserer Testumgebung zu befinden scheint (Abfragen sys.partition_functionsund sys.partition_range_values).

Ein identischer Datensatz in der Produktion verursacht den erwarteten Fehler beim Versuch, den Datensatz zu aktualisieren. Die zwei Male, die wir dies bisher bemerkt haben, schlägt das Update in der Produktion fehl, ist aber im Test erfolgreich (niemals umgekehrt).

Relevante Fakten zur Umwelt:

  • SQL Server 2012 SP3 CU3 (Build 11.0.6537.0)
  • Test ist Developer Edition, Produktion ist Enterprise
  • Kann andere wie gewünscht versorgen: Ernsthaft ratlos im Moment ...

UPDATE 19.08.2016

Hatte neue Rekorde irgendwie über Nacht aktualisiert. Bestätigt, dass es sich um eine schreibgeschützte Dateigruppe handelt. Es wurde festgestellt, dass ich Datensätze aktualisieren kann, die gleichzeitig eingefügt wurden (dh sich auch auf derselben Partition in der schreibgeschützten Dateigruppe befinden). Ich habe einen einzelnen Datensatz auf derselben Partition identifiziert und konnte den Datensatz mehrmals aktualisieren. Versuche, den über Nacht aktualisierten Datensatz zu aktualisieren, führen zu dem erwarteten Fehler.

UPDATE 11.08.2016

Während der nächtlichen Testverarbeitung auf der schreibgeschützten Partition werden weiterhin Aktualisierungen durchgeführt. Der Versuch, dieselben Datensätze aus dem Prozess zu aktualisieren, schlägt fehl. Der Versuch, dieselben Datensätze zu aktualisieren, während er angemeldet war wie der Benutzer, der sie zuvor aktualisiert hat, ist fehlgeschlagen. Ich kann das Problem auch nicht duplizieren, indem ich einen ähnlichen Datensatz aktualisiere, der vom nächtlichen Prozess noch nicht berührt wurde.

UPDATE 04.08.2016

Heute wurde festgestellt, dass es nicht auf diese einzelne Tabelle beschränkt ist, da ich ein anderes Vorkommen desselben Verhaltens in einer anderen Tabelle mit demselben Partitionsschema entdeckt habe.

UPDATE 03.08.2016

Das Ausführen des Skripts über dieses MSDN-Skript bestätigt, was ich bei Verwendung der Partitionshilfeansichten von Kendra Little ph.FilegroupDetailund ph.ObjectDetailaus dieser Demo erhalte . Der betreffende Datensatz befindet sich in Partition 2 (der Partitionsspaltenwert für den betreffenden Datensatz lautet 18.03.2015).

Filegroup     Low Boundary     UpperBoundary
Archive  (RO) NULL             1900-01-01
Archive  (RO) 1900-01-01       2015-04-01
ActiveFG (RW) 2015-04-01       2015-07-01
ActiveFG (RW) 2015-07-01       2015-10-01
ActiveFG (RW) 2015-10-01       2015-01-01
ActiveFG (RW) 2016-01-01       2016-04-01
ActiveFG (RW) 2016-04-01       2016-07-01
ActiveFG (RW) 2016-07-01       2016-10-01
ActiveFG (RW) 2016-10-01       2017-01-01
ActiveFG (RW) 2017-01-01       2115-01-01
ActiveFG (RW) 2115-01-01       NULL

Code zum Platzieren der Tabelle auf der Partition (es gibt keine anderen Indizes)

ALTER TABLE [dbo].[TABLE_NAME] ADD  CONSTRAINT [pk_TABLE_NAME] PRIMARY KEY CLUSTERED 
(
    [ETL_VERS_START_DTM] ASC,
    [ACCT_NO] ASC,
    [ACCT_TYPE] ASC
) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON ps_SmallTablesDate(ETL_VERS_START_DTM)

Die Update-Anweisung, die fehlschlagen sollte (über Informatica):

UPDATE TABLE_NAME SET ETL_JOB_SEQ_NUM = ?, ETL_IUD_CD = ?, ETL_UPD_DTM = ?, ETL_DEL_DTM = ? WHERE ETL_VERS_START_DTM = ? AND ACCT_NO = ? AND ACCT_TYPE = ?
ETL_VERS_START_DTM (ETL_VERS_START_DTM:Date:): "03/17/2015 23:30:02.140000000"
ETL_JOB_SEQ_NUM (ETL_JOB_SEQ_NUM:Int:): "1173651"
ETL_IUD_CD (ETL_IUD_CD:Char.1:): "D"
ETL_UPD_DTM (ETL_UPD_DTM:Date:): "08/02/2016 02:32:45.000000000"
ETL_DEL_DTM (ETL_DEL_DTM:Date:): "08/02/2016 00:10:03.567000000"
ACCT_NO (ACCT_NO:Char.12:): "1234567890"
ACCT_TYPE (ACCT_TYPE:Char.3:): "OLN"

UPDATE 2017-02-21

Nach all dieser Zeit haben wir festgestellt, dass beim Zusammenführen der ältesten aktiven Partition in das Archiv ein Teil der Datensätze nicht von der aktiven Dateigruppe in die Archivdateigruppe auf der Festplatte verschoben wurde. Die folgende Abfrage zeigt, dass Datensätze von Partition 2 ActiveFG zugeordnet wurden, während die Überprüfung des tatsächlichen Partitionierungsschemas zeigt, dass dieselben Datensätze von der Partitionsfunktion in die Archivdateigruppe sortiert werden sollten.

SELECT  OBJECT_NAME(P.[object_id]) ,
    P.index_id ,
    P.partition_number ,
    F.name ,
    F.filegroup_guid
FROM    sys.allocation_units AU
    JOIN sys.partitions P ON P.partition_id = AU.container_id
    JOIN sys.filegroups F ON F.data_space_id = AU.data_space_id
WHERE   P.partition_number IN ( 1, 2, 3 )
    AND P.[object_id] = OBJECT_ID('TABLE_NAME')
ORDER BY P.partition_number;

Ich habe die gesamte Partitionierung in den tatsächlich verwendeten Datenbanken zurückgesetzt und eine Version derjenigen beibehalten, die für die Arbeit mit dem Microsoft-Ticket defekt war. Ich muss den Partitionierungsplan mit unserem DW-Team überarbeiten, aber ich gebe zu, dass ich ein bisschen scheu bin, es erneut zu versuchen.

Microsoft konnte dieses Verhalten nicht duplizieren und ist daher zu diesem Zeitpunkt mit dem Ticket fertig. Sie scheinen bereit zu sein, es einfach abzuschütteln und anzunehmen, dass es 2014/2016 nicht vorhanden ist? Sie können es scheinbar nicht in ihren Labors replizieren, obwohl ich es weiterhin in der Datenbank haben kann, selbst nachdem ich es von der Sicherung in meinem System wiederhergestellt habe.

toosuto
quelle
Ich habe die gesamte Partitionierung in den tatsächlich verwendeten Datenbanken zurückgesetzt und eine Version derjenigen beibehalten, die für die Arbeit mit dem MS-Ticket defekt war. Ich muss den Partitionierungsplan mit unserem DW-Team überarbeiten, aber ich gebe zu, dass ich ein
bisschen

Antworten:

1

Ich muss etwas gestehen.

Als ich jung war, habe ich einmal einen ETL-Prozess erstellt, der damit begann, schreibgeschützte Dateigruppen in schreibgeschützt zu ändern, die ETL-Arbeit zu erledigen und sie dann wieder auf schreibgeschützt zu setzen.

Nur für den Fall, dass Sie einen Kollegen haben, der teuflisch war wie ich (ich war jung, ich brauchte das Geld), können Sie testen durch:

  1. Ändern Sie den Namen der schreibgeschützten Dateigruppe. Auf diese Weise schlagen die Skripte fehl, wenn jemand fest codierte Skripte hat, die die Dateigruppe nach Namen ändern. Oder etwas schwieriger:

  2. Verwenden Sie den Profiler oder erweiterte Ereignisse, um jeden zu verfolgen, der eine ALTER DATABASE ausführt.

Brent Ozar
quelle
Wir hatten dem DW-Team tatsächlich ein Skript zur Verfügung gestellt, um diese Änderung vorzunehmen, damit sie uns nicht in der Nacht bei der seltenen, aber erwarteten Gelegenheit wecken mussten, dass ihr Job fehlschlug. Wir haben auch einen Audit-Trigger auf Serverebene (für DDL_SERVER_LEVEL_EVENTS), mit dem die Treffer der Lese- / Schreibeigenschaft der Dateigruppe festgelegt werden. Es sendet uns das SQL-Skript, den Benutzer und die IP-Adresse, die vom DBA-Team überprüft werden sollen.
Toosuto
Obwohl ich den Eindruck haben könnte, dass sie so hinterhältig sind, dass sie unser Skript verwenden, um die Dateigruppeneinstellungen vor ihrem ETL-Prozess zu ändern, sind sie technisch nicht bewusst genug, um nach unserem Trigger zu suchen und ihn zu deaktivieren.
Toosuto