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.