Integration eines alternativen MS SQL Server-Schemas

Ein alternatives Schema für die Automation Engine ermöglicht es Ihnen, die klassische Automation Engine-Datenbank in zwei separate Datenbanken aufzuteilen.

Diese Seite beinhaltet Folgendes:

Übersicht

Wenn Sie Zeilen in einer MS SQL Server-Datenbank löschen, können die Datensätze entweder als Ghost-Datensätze gekennzeichnet oder sofort gelöscht werden. Dies hängt von Ihrer Datenbankkonfiguration ab:

Wenn Ihre Datenbank mit geclusterten und/oder Heap-Tabellen konfiguriert ist und die Versionskontrolle aktiviert ist (read_committed_snapshot=ON), werden die Datensätze nicht gelöscht, sondern als Ghost-Datensätze gekennzeichnet.

Der Ghost Cleanup-Vorgang, ein Single-Thread-Vorgang, löscht diese Datensätze physisch im Hintergrund.
Wenn Ihre Datenbank nur mit Heap-Tabellen konfiguriert ist und die Versionskontrolle deaktiviert ist (read_committed_snapshot=OFF), werden die Datensätze physisch sofort gelöscht.

Dieses Konzept garantiert einen Leistungsgewinn beim Löschen mehrerer Zeilen. Bei großen Systemen kann der Ghost-Bereinigungsprozess allerdings hinter dem restlichen System liegen und dieses blockieren.

Das Automation Engine-System schreibt jede Transaktion in die Datenbank und löscht sie, nachdem sie erfolgreich verarbeitet wurde. Das bedeutet, dass die AEZeilen größtenteils aus den MQ-Tabellen löscht. Wenn Sie ein alternatives Datenbankschema verwenden, können Sie Ihre Datenbank aufteilen und ihre MQ-Tabellen in einer separaten Datenbank ablegen. Aus diesem Grund wird der Ghost-Bereinigungsprozess in der zweiten Datenbank (MQ) nicht verwendet, und die Leistung wird gesteigert.

Das folgende Architekturdiagramm zeigt die klassischen und alternativen Datenbankschemata.

Das klassische Datenbankschema ist mit geclusterten und Heap-Tabellen konfiguriert und aktiviert die Versionskontrolle (read_committed_snapshot=ON). Im alternativen Datenbankschema ähnelt die erste Datenbank (AE) der Datenbank im klassischen Schema. Es gibt nur zwei Unterschiede:

Die erste Datenbank (AE) im alternativen Schema wird nur mit geclusterten Tabellen konfiguriert.
Die MQ-Tabellen in der ersten Datenbank (AE) im alternativen Schema sind Synonyme (Verknüpfungen) zur entsprechendie Registerkarteelle in der zweiten Datenbank (MQ)

Die zweite Datenbank (MQ) wird mit Heap-Tabellen konfiguriert, und die Versionskontrolle ist deaktiviert (read_committed_snapshot=OFF). Sie enthält die tatsächlichen MQ-Tabellen.

Die alternative Datenbank:

ist nur für MS SQL Server verfügbar
kann in das klassische Datenbankschema umgewandelt werden und umgekehrt
kann von DBLOAD verwaltet werden, sieh AE DB Load
Muss die Versionskontrolle aktiviert haben

Wenn dies nicht der Fall ist, wird Sie vom Dienstprogramm DBLOAD aktiviert.

Mehr Informationen:

Sie können ein System mit einem alternativen Plan von Grund auf neu erstellen, oder Sie können ein vorhandenes klassisches Schema in ein anderes Schema umwandeln.

AE-System mit dem alternativen Schema völlig neu erstellen

Sie können ein alternatives Schema entweder mit dem Dienstprogramm DBLoad oder manuell erstellen.

Erstellen eines alternativen Datenbankschemas mit dem Dienstprogramm DBLoad

Sie benötigen zwei leere MS SQL Server-Datenbanken mit ODBC-Verbindungen und einen Benutzer, der auf beide Datenbanken zugreifen kann. Zum Beispiel AE (mit Versionskontrolle) und MQDB (ohne Versionskontrolle). AE enthält die anfänglichen Daten und MQDB die MQ-Tabellen für die Beschleunigung.

Die Datei UCYBDBld.ini enthält einen neuen Abschnitt namens [MQDB]. Sie können die ODBC-Verbindung zu MQDB im neuen Abschnitt [MQDB] definieren, genau wie im Abschnitt ODBC.

Wenn in der INI-Datei gültige ODBC-Verbindungen vorhanden sind, wird das Dienstprogramm DBLoad im Split-Datenbankmodus ausgeführt. Das bedeutet, dass die erforderlichen Operationen in der MQDB-Datenbank durchgeführt werden.

Mit zwei gültigen leeren Datenbanken können Sie die UC_UPD.txt mit dem Dienstprogramm DBLoad ausführen. Nach erfolgreicher Ausführung erhalten Sie die geteilte Datenbank. Anschließend können Sie die Arbeits- und/oder Kommunikationsprozesse auf dem System starten und die Programme wie gewohnt verwenden.

Ein alternatives Datenbankschema manuell erstellen

Erstellen Sie zwei Datenbanken mit ODBC -Verbindung. Zum Beispiel AE und MQDB.

AE enthält die anfänglichen Daten und MQDB die MQ-Tabellen für die Beschleunigung.
Laden Sie den anfänglichen Daten in die AE-Datenbank.
- Überprüfen Sie die Einstellungen mit den dbcc-Benutzeroptionen
- Stellen Sie sicher, dass die Datenbank mit Versioning läuft. Wenn dies nicht der Fall ist, führen Sie folgenden Befehl aus:
  
  alter database xxxx set read_committed_snapshot on
Bereiten Sie die MQDB-Datenbank vor.
- Erstellen Sie die MQ-Tabellen mit KEY NONCLUSTERED. Erstellen Sie Anweisungen in mqdb_ddl.sql.
- Überprüfen Sie die Einstellungen mit dbcc useroptions.
- Stellen Sie sicher, dass die Datenbank OHNE Versioning läuft. Führen Sie dazu folgenden Befehl aus:
  
  alter database xxxx set read_committed_snapshot off
Benennen Sie die ursprünglichen MQ-Tabellen in der AE-Datenbank in *_org mit den Anweisungen um, die mit dem folgenden Befehl generiert werden:

select 'exec sp_rename ' + name + ' ,' + name + '_org;' from sys.tables where name like 'mq%'
Erstellen Sie Synonyme für MQBD. Führen Sie die Anweisungen in der AE aus, die mit dem folgenden Befehl generiert werden:

select 'create synonym [dbo].[' + replace (name,'_org','') + '] for [MQDB].[dbo].[' + replace (name,'_org','') + '];' from sys.tables where name like 'mq%'

Klassisches AE-Datenbankschema in ein alternatives Datenbankschema konvertieren

Sie müssen eine zweite, leere MS SQL Server-Datenbank erstellen.

Wichtig! Für die neue Datenbank dürfen keine Tabellen definiert sein. Beispielsweise sollte "SELECT count(*) as DIVDB_Int4 FROM INFORMATION_SCHEMA.TABLES" 0 zurückgeben.

Definieren Sie die ODBC-Verbindung für diese Datenbank und setzen Sie sie auf den neuen [MQDB]-Abschnitt in der Datei ucybdbld.ini.

Laden Sie normale anfängliche Daten mit der UC_UPD.txt. Wenn die zweite Datenbank leer ist, teilt das Dienstprogramm DBLoad Ihre Datenbank in das neue Schema auf.

Überprüfen des Versioning-Status

Um die Einstellungen für das Versioning auf Ihrer Datenbank abzufragen, können Sie den folgenden Befehl verwenden:

select is_read_committed_snapshot_on as DIVDB_Int4 from sys.databases where name = 'DB_NAME'

Siehe auch: