Überprüfung der Fremdschlüsseleinschränkung "online"

8

Wenn wir eine riesige Faktentabelle haben und eine neue Dimension hinzufügen wollen, können wir das so machen:

%Vor%

Hinweis: Alle oben genannten Informationen bearbeiten nur Tabellenmetadaten und sollten unabhängig von der Tabellengröße schnell sein. Dann können wir einen Job ausführen, um GiantFactTable.NewDimValueId in kleinen Transaktionen zu füllen, so dass der FK nicht verletzt wird. (An diesem Punkt werden alle INSERTs / UPDATEs - z. B. Backfill-Vorgänge - vom FK überprüft, da er aktiviert, aber nicht "vertrauenswürdig" ist)

Nach dem Abgleich wissen wir , dass die Daten konsistent sind. Meine Frage ist, wie SQL Engine auch erleuchtet werden kann. Ohne die Tabelle offline zu nehmen.

Dieser Befehl wird den FK vertrauenswürdig machen, aber es erfordert eine Schema-Änderung (Sch-M) Sperre und wahrscheinlich Stunden dauern (Tage?) die Tabelle offline zu nehmen:

%Vor%

Über die Arbeitslast: Tabelle hat einige hundert Partitionen (feste Nummer), Daten werden jeweils an eine Partition angehängt (in einer Round-Robin-Art), niemals gelöscht. Es gibt auch eine konstante Lese-Workload, die den Clustering-Schlüssel verwendet, um einen (relativ kleinen) Bereich von Zeilen von jeweils einer Partition zu erhalten. Es wäre akzeptabel, jeweils eine Partition einzeln zu überprüfen und offline zu schalten. Aber ich kann keine Syntax dafür finden. Irgendwelche anderen Ideen?

    
Serguei 23.10.2013, 18:37
quelle

1 Antwort

1

Ein paar Ideen fallen mir ein, aber sie sind nicht hübsch:

Leiten Sie Workloads um und führen Sie die Prüfbedingung offline aus

  1. Erstellen Sie eine neue Tabelle mit derselben Struktur.
  2. Ändern Sie den Workload "Einfügen", um ihn in die neue Tabelle einzufügen
  3. Kopieren Sie die Daten von der vom Workload "read" verwendeten Partition in die neue Tabelle (oder eine dritte Tabelle mit derselben Struktur)
  4. Ändern Sie den Workload "read", um die neue Tabelle zu verwenden
  5. Führen Sie alter table aus, um die Einschränkung zu prüfen und sie so lange zu lassen, wie sie benötigt wird.
  6. Ändern Sie beide Arbeitslasten in die Haupttabelle.
  7. Fügen Sie die neuen Zeilen wieder in die Haupttabelle ein
  8. Neue Tabelle (n) löschen

Eine Variation des obigen ist, die relevante Partition in die neue Tabelle in Schritt 3 zu wechseln. Das sollte schneller sein als das Kopieren der Daten, aber ich denke, Sie müssen die Daten nach der Einschränkung kopieren (und nicht einfach umschalten) wurde überprüft.

Fügen Sie alle Daten in eine neue Tabelle ein

  1. Erstellen Sie eine neue Tabelle mit derselben Struktur und Einschränkung, die aktiviert wurde
  2. Ändern Sie die Arbeitslast "Einfügen" in die neue Tabelle
  3. Kopieren Sie alle Daten stapelweise von der alten in die neue Tabelle und warten Sie so lange, bis Sie fertig sind
  4. Ändern Sie den Workload "read" in die neue Tabelle. Wenn Schritt 3 zu lange dauert und die Arbeitslast "Lesen" Zeilen benötigt, die nur in die neue Tabelle eingefügt wurden, müssen Sie diese Umstellung manuell verwalten.
  5. Alte Tabelle löschen

Index zur Beschleunigung der Constraint-Prüfung verwenden?

Ich habe keine Ahnung, ob das funktioniert, aber Sie können versuchen, einen nicht gruppierten Index für die Fremdschlüsselspalte zu erstellen. Stellen Sie außerdem sicher, dass ein Index für den relevanten eindeutigen Schlüssel in der Tabelle vorhanden ist, auf den der Fremdschlüssel verweist. Der alter table -Befehl ist möglicherweise in der Lage, sie zu verwenden, um die Überprüfung zu beschleunigen (zumindest durch Minimierung von IO im Vergleich zu einem vollständigen Tabellenscan). Die Indizes können natürlich online erstellt werden, um Störungen zu vermeiden.

    
acfrancis 04.11.2013 01:53
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wie konvertiert man das Excel File-Format nach Drive API Upload in G-Sheet?