Zeit in einer replizierten Umgebung

Da die Zeitinformationen wertmäßig vom primären NPS®-Knoten repliziert werden, gibt es keine automatische Konvertierung von Zeitwerten in ihre lokalen Entsprechungen oder Anpassungen für Unterschiede in der Zeitsynchronisation zwischen den Knoten. Der exakte Datums-/Zeitwert, der auf der Primärdatei erfasst wird, ist der Wert, der auf der Replik eingefügt wird.

Die Replikationslogik beruht auf zeitlicher Konsistenz zwischen allen NPS- und Replikationswarteschlangen-Manager-Knoten. In einer replizierten Umgebung, in der sich NPS-Systeme in verschiedenen Zeitzonen befinden, müssen Sie die Vorgänge mit Hilfe eines Zeitsynchronisationsdienstes, wie z. B. Network Time Protocol (NTP), synchronisieren. Weitere Informationen finden Sie unter Netzwerkkonfiguration auf der Knotenseite in der Dokumentation von Cloud Pak for Data.

Wichtig: Das Ändern der Uhrzeit bei laufenden Systemen kann zu Betriebsproblemen führen, z. B. zu Verzögerungen beim Auslösen von Ereignissen.

Zeit und NPS

Die Zeit auf dem NPS-Knoten basiert auf der Zeit des NPS-Hostsystems. Die Abfrageausführungsumgebung verwendet diese Zeit. Standardmäßig wird die Zeitzone als UNBEKANNT betrachtet. Sie können die Standardeinstellung jedoch außer Kraft setzen, indem Sie Zeitzoneninformationen für die Sitzungsvariable TIMEZONE angeben.

Die folgenden Verhaltensweisen gelten für zeitliche NPS-Typen und deren Handhabung:

Die temporalen Datentypen von Netezza® (DATE, TIME und TIMESTAMP) speichern Datums-, Zeit- und Zeitstempelwerte, die nicht die Zeitzone widerspiegeln, in der sie erzeugt wurden.
Es werden alle zulässigen Datums-, Zeit- und Zeitstempel-Literale aus einer SQL-Sitzung akzeptiert.
Die SQL-Funktionen CURRENT_DATE, CURRENT_TIME und CURRENT_TIMESTAMP (auch NOW) erzeugen Datums-, Zeit- und Zeitstempelwerte, die die Zeit in der aktuellen Zeitzone wiedergeben. Die aktuelle Zeitzone ist standardmäßig diejenige des NPS-Server-Hosts. Sie können diese Zeitzone in einer SQL-Sitzung außer Kraft setzen, indem Sie den Befehl SET TIME ZONE oder gleichwertig den Befehl SET TIMEZONE verwenden. Sie wirkt sich auf die Werte aus, die erzeugt werden, wenn diese Sitzung die drei Funktionen aufruft. Selbst auf einem einzigen Netezza gibt es keine Garantie dafür, dass Datums-, Zeit- oder Zeitstempelwerte, die von verschiedenen Client-Sitzungen (oder derselben Sitzung mit unterschiedlichen SET TIME ZONE Befehlseinstellungen) eingefügt werden, eine gemeinsame Zeitstempelreferenz oder Zeitzone haben.
Die Anwendung muss verwalten, ob die Zeitzoneninterpretation relativ zu Datums-, Zeit- und Zeitwerten in Tabellenspalten ist.
Zu den eingebauten Werkzeugen für den Umgang mit Zeit- und Zeitzoneninformationen gehören der Datentyp TIMETZ (ein Alias für den Datentyp TIME WITH TIME ZONE) und die Funktion TIMEZONE(). TIMETZ ist ein etwas anderer zeitlicher Datentyp, da die Werte einen Zeitzonen-Offset enthalten, den Sie in TIMETZ-Literalen angeben können (z. B. '01:23:45-06'). Wird ein zeitähnliches Literal ohne Zeitzonen-Offset in eine TIMETZ-Spalte eingefügt, verwenden die Replikationsdienste '+00' (GMT).

Das folgende Beispiel veranschaulicht die Zeitzonen anhand einer Netezza mit zwei Knoten, wobei sich der primäre Knoten in New York, USA (östliche Zeitzone), und der Replikationsknoten in London, Großbritannien (GMT), befindet. Die folgende Auftragszeile wird auf dem primären NPS-Knoten in New York angelegt und auf das Replikat in London repliziert. In diesem Beispiel ist der aktuelle Zeitstempel der 19. Januar 2012 um 9:12 Uhr.

INSERT INTO ordertable values (1, current_timestamp, 'Product A');

Die Zeile in der Tabelle auf dem primären NPS-Knoten würde wie folgt aussehen:


ORDERNUMBER |   ORDERTIMESTAMP    | ORDERDETAILS
------------+---------------------+--------------
          1 | 2012-01-19 09:12:06 | Product A

Diese Zeile wird auch auf den Replikations-NPS-Knoten repliziert und hat die gleichen Werte. Die Werte sind genau, aber wie im Beispiel gezeigt, gibt es keine Informationen darüber, auf welche Zeitzone sich diese Angaben beziehen. Zum Zeitpunkt des Beispiels herrscht in New York Standardzeit (EST), und der Zeitunterschied zwischen New York und London beträgt 5 Stunden (-05). Da die Zeile etwa zur gleichen Zeit repliziert wird, zu der sie eingefügt wurde, wird die Zeit auf dem replizierenden NPS-Knoten als 14:12 Uhr Ortszeit (GMT) registriert.

Umgehungen für Zeitzonenunterschiede

Wichtig: Wenn der NTP-Synchronisierungsdienst die Replikationsknoten nicht synchronisieren kann, beachten Sie die folgenden Abhilfemaßnahmen.

Zeitzonenunterschiede können sich auf Berichtsanwendungen auswirken, die auf dem Replikations-NPS-Knoten laufen. Wie im vorangegangenen Beispiel gezeigt, können der Datenbank beispielsweise neue Daten hinzugefügt werden, die scheinbar mehrere Stunden zurückliegen. Darüber hinaus entstehen zusätzliche Probleme, wenn die Rollen der beiden NPS-Knoten vertauscht werden (London ist nun der primäre und New York der replizierende Knoten). In diesem Fall gibt es Zeilen mit Zeitstempeln aus der Zukunft relativ zur Replik.

Es gibt mehrere Möglichkeiten, Zeitzonenunterschiede zu umgehen. Die richtige Lösung hängt von Ihren Anwendungen und Ihrer Umgebung ab.

Alle Zeitangaben müssen sich auf eine gemeinsame Basis beziehen (z. B. UTC oder GMT).
Erfassen Sie zeitzonenspezifische Informationen, wenn die Zeit erfasst wird.
Erfassen Sie Gebiets-, Standort- oder Systeminformationen für alle Datensätze (z. B. in einer Standortspalte und einer separaten Standortinformationstabelle).

Diese Ansätze werden in den folgenden Abschnitten beschrieben.

Alle Zeiten relativ zu einer gemeinsamen Basis machen

Bei diesem Ansatz wandelt die Anwendung, die die Änderungen in der Datenbank vornimmt, alle Zeitangaben in eine gemeinsame Basis um (z. B. UTC oder GMT). Dazu setzen Sie die Sitzungsvariable TIMEZONE im NPS auf die gewünschte Basiszone, so dass alle zeitbezogenen Funktionen denselben Wert verwenden.

Im vorherigen Beispiel würden die Anwendungen die Sitzungsvariable TIMEZONE auf jedem Knoten auf GMT setzen, bevor sie die DML-Vorgänge ausführen:

SYSTEM(ADMIN)=> SET TIMEZONE='GMT';
SET VARIABLE
SYSTEM(ADMIN)=> show timezone;
NOTICE: Time zone is GMT
SHOW VARIABLE

Die gleiche INSERT-Anweisung wie im vorherigen Abschnitt würde nun die aktuelle Zeit relativ zur GMT aufzeichnen:


ORDERNUMBER |   ORDERTIMESTAMP    | ORDERDETAILS
------------+---------------------+--------------
          1 | 2012-01-19 14:12:06 | Product A

Der GMT-Zeitstempel ist der Wert, der an den Replikations-NPS-Knoten in London repliziert wird. Infolgedessen würde eine Berichtsanwendung sehen, dass alle Zeilen mit denselben Werten aktualisiert werden.

So müsste eine Meldeanwendung im obigen Beispiel die unterschiedlichen relativen Betriebszeiten der beiden Regionen berücksichtigen. Eine Abfrage, die "alle Bestellungen von heute" anzeigt, müsste berücksichtigen, was "heute" in Bezug auf die verschiedenen Standorte (New York und London) bedeutet. In diesem Fall könnte es für die Anwendung von Vorteil sein zu wissen, woher der Auftrag stammt, um die relative Zeit in die eines Ortes umrechnen zu können. Um dies zu erreichen, könnte eine Anwendung alle üblichen Zeitstempelinformationen (die im Beispiel GMT verwenden) in eine andere spezifische Zeitzone konvertieren und dann die Informationen verarbeiten. Betrachten Sie eine erweiterte Version des vorherigen Beispiels, bei der die Ausgabe wie folgt aussieht:


ORDERNUMBER |      TIMESTAMP      | ORDERDETAILS
-------------+---------------------+--------------
           8 | 2012-04-13 13:40:41 | t3
           7 | 2012-04-13 13:40:25 | t2
           6 | 2012-04-13 13:40:13 | t1
           5 | 2012-04-13 13:34:32 | jki
           4 | 2012-04-13 13:33:49 | def
           3 | 2012-04-13 13:33:33 | abc
           2 | 2012-04-12 14:41:40 | Product A
           1 | 2012-04-12 14:33:03 | Product A

Diese Einträge sind alle GMT-Zeitstempel. Sie können mit Hilfe von SQL-Funktionen wie folgt in andere relative Zeiten umgewandelt werden. Stellen Sie zunächst auf Pacific Daylight Time um:

SELECT ordernumber, timezone('PDT',
timestamp(substring(ordertimestamp,1,10),
timetz(substring(ordertimestamp, 12)))) as ts, orderdetails FROM
ordertable2 ORDER BY ts desc;

Die Ausgabe ist wie folgt:


ORDERNUMBER |           TS           | ORDERDETAILS
------------+------------------------+--------------
          8 | 2012-04-13 06:40:41-07 | t3
          7 | 2012-04-13 06:40:25-07 | t2
          6 | 2012-04-13 06:40:13-07 | t1
          5 | 2012-04-13 06:34:32-07 | jki
          4 | 2012-04-13 06:33:49-07 | def
          3 | 2012-04-13 06:33:33-07 | abc
          2 | 2012-04-12 07:41:40-07 | Product A
          1 | 2012-04-12 07:33:03-07 | Product A

In diesem Beispiel werden die Informationen in denselben Zeilen auf die östliche Sommerzeit umgerechnet:

SELECT ordernumber, timezone('EDT',
timestamp(substring(ordertimestamp,1,10),
timetz(substring(ordertimestamp, 12)))) as ts, orderdetails FROM
ordertable2 ORDER BY ts desc;

Die Ausgabe ist wie folgt:


ORDERNUMBER |           TS           | ORDERDETAILS
------------+------------------------+--------------
          8 | 2012-04-13 09:40:41-04 | t3
          7 | 2012-04-13 09:40:25-04 | t2
          6 | 2012-04-13 09:40:13-04 | t1
          5 | 2012-04-13 09:34:32-04 | jki
          4 | 2012-04-13 09:33:49-04 | def
          3 | 2012-04-13 09:33:33-04 | abc
          2 | 2012-04-12 10:41:40-04 | Product A
          1 | 2012-04-12 10:33:03-04 | Product A

Für Anwendungen, die in verschiedenen Zeitzonen ausgeführt werden, können Zeitvergleiche und -verarbeitungen relativ zur Sitzungszeitzone einer Anwendung durchgeführt werden. Wie in den Beispielen gezeigt, verwenden Sie dazu eine gemeinsame relative Zeitbasis (z. B. UTC).

Erfassen von zeitzonenspezifischen Informationen

Der Ansatz, zeitzonenspezifische Informationen zu erfassen und einzubeziehen, ist ähnlich wie der Ansatz, eine gemeinsame Zeitbasis zu verwenden. Mit dem Ansatz, zeitzonenspezifische Informationen zu erfassen und einzubeziehen, können Sie auch den Herkunftsort der Zeileninformationen speichern, wenn sich NPS-Knoten in verschiedenen Zeitzonen befinden.

Sie müssen den Datentyp für die Zeitangaben von TIMESTAMP in VARCHAR ändern. Sie können die Zeichendarstellung der Zeitstempelinformationen immer noch in datums-/zeitbezogene Typen für die Verwendung in Funktionen konvertieren, da mehrere Funktionen einen unterschiedlichen Zeichentyp akzeptieren können. Alternativ können Sie auch getrennte Felder für Datums- und Zeitangaben verwenden und die Zeit mit dem Typ TIMETZ speichern.

In diesem Beispiel wird, ähnlich wie im Originalbeispiel, der Typ VARCHAR verwendet, um die Zeitstempelinformationen zu erfassen:

INSERT INTO ordertable2 values (1, timezone('EDT', current_timestamp),
'Product A');

In diesem Beispiel, das die Funktion TIMEZONE verwendet, wurde die Zeitzone der Sitzungsvariablen zunächst auf GMT gesetzt (wie in dem Beispiel, das im vorherigen Abschnitt eine gemeinsame relative Zeitbasis verwendet hat). Dies ist notwendig, da die von der Funktion TIMEZONE zurückgegebene Zeitdarstellung auf der Abweichung von der GMT basiert, die im ersten Parameter für die Funktion angegeben ist (in diesem Fall "EDT").

Die sich daraus ergebende Auftragszeile in der Tabelle sieht wie folgt aus:


ORDERNUMBER |     ORDERTIMESTAMP     | ORDERDETAILS
------------+------------------------+--------------
          1 | 2012-01-19 09:12:06-05 | Product A

Der Zeitstempel hat jetzt den lokalen Zeitstempel des primären NPS-Knotens (EST), aber mit dem Offset in Stunden von der GMT ('-05'). Dieser Wert wird auf den Replikations-NPS-Knoten in London repliziert. Eine Berichtsanwendung, die auf dem Londoner NPS-Knoten läuft, kann anhand der Uhrzeit der Zeile erkennen, dass sie auf dem New Yorker NPS-Knoten entstanden ist. Dennoch muss die Anwendung den Zeitstempel in einen gemeinsamen, lokalen oder relativen Zeitwert umwandeln, um gültige Vergleiche mit den Werten durchführen zu können.

Erfassen von Standortkennungsinformationen

Die Erfassung von Informationen zur Standortidentifizierung ist ähnlich wie der zweite Ansatz. Anstatt jedoch die Zeit auf eine gemeinsame Basis zu setzen und den relativen Versatz zu erfassen, verwendet dieser dritte Ansatz ortsbezogene Informationen, um den entsprechenden Datumszeitwert zu generieren, der zur Konvertierung, Identifizierung oder zum Nachschlagen von Ortskennungen verwendet werden kann. In diesem Szenario werden die Zeitzoneneinstellungen der Sitzung als Standardzeitzoneneinstellungen des Systems beibehalten.

Die Verfügbarkeit von orts- oder zeitzonenspezifischen Informationen ist für die Erfassung der Sitzung erforderlich. Sie können dies erreichen, indem Sie einen Ortscode, eine Zeitzone, einen Zeitzonen-Offset oder eine andere Kennung in die Sitzung oder auf andere Weise übergeben. Es folgt eine Beispieltabelle:


ORDERNUMBER |    ORDERTIMESTAMP    | ORDERDETAILS | LOC_CODE
------------+----------------------+--------------+----------
          1 | 2012-01-19 09:12:06  | Product A    | 1

Das Feld LOC_CODE kann dann eine Zuordnung zu einer anderen Tabelle sein, die Ortsangaben enthält:


LOC_CODE |   LOCATIONCITY   | LOCATIONTZ | TIMEZONEOFFSET
---------+------------------+------------+----------------
       1 | New York, NY     | EST        | -5

Sie können das Format und die gespeicherten Informationen an die jeweiligen Anwendungsanforderungen anpassen.

Andere ähnliche Ansätze erfassen eine spezifische Zeitzonenkennung oder einen spezifischen Zeitversatz, anstatt einen Code, der einer anderen Tabelle zugeordnet ist. Entscheidend ist die Möglichkeit, Informationen zu erfassen, die dann an eine Zeitkonvertierungsfunktion wie TIMEZONE() weitergegeben werden können. Wie in der ersten Reihe von Beispielen dargestellt, können Sie Zeitwerte für Analysen, Vergleiche, Berichte und andere Zwecke in eine gemeinsame Basis konvertieren.