Leistungsoptimierung von DataGuard

Transkript

1 Betrifft: Autor: Leistungsoptimierung von DataGuard Dr. Gérard Schaller Art der Info: DBA-Tipps (Mai 2003) Quelle: Gesammelte Erfahrungen der Trivadis Consultants 1. Einführung DataGuard ist die neue Generation der Standby-Datenbanken, die mit der Version Oracle9i eingeführt wurde. Die Standardwerte der Konfiguration von DataGuard sind insgesamt zufriedenstellend. Um jedoch die einwandfreie Funktion von DataGuard sowie maximalen Schutz vor Datenverlusten zu erzielen, wird ein Tuning empfohlen. Dies ist umso wichtiger, da sich die Übertragungs- und Anwendungsregeln für Redo- Daten von einer DataGuard-Version zur nächsten geändert haben und so eine Anpassung der Konfigurationsparameter erforderlich ist. Wir geben an dieser Stelle einige Empfehlungen bezüglich der Konfiguration von DataGuard, damit Sie im Rahmen physikalischer Standby-Datenbanken bestmögliche Leistungsergebnisse erzielen können. 2. ARCH-Übertragung versus LogWriter-Übertragung Der zuverlässigste Übertragungsweg erfolgt über den ARCH-Prozess. Man sollte jedoch beachten, dass der Schutz vor Datenverlust in diesem Modus etwas geringer ist. Die Daten des Online-Redo werden über einen Redo-Switch auf die Backup-Site übertragen, was bei Failover der Online-Daten zu Datenverlusten führen kann. Bei der LGWR-Übertragung werden alle Schreibvorgänge des Online-Redo vom LogWriter-Prozess synchron oder asynchron auf die Standby-Site geschrieben. Wenn auf der Standby-Site Standby-Redo-Logs erstellt werden, schreibt der LogWriter direkt in die Standby-Redo-Logs (SRL). Die Verwendung von SRLs ist im ASYNC-Modus nicht obligatorisch, wird jedoch empfohlen. Ohne SRL wird auf der Standby-Site ein Archiv erstellt und nach und nach gefüllt. Wenn die Standby-Site aktiviert wird und das Archiv noch nicht vollständig gefüllt ist (was sehr wahrscheinlich ist), kommt es zu Konflikten. In diesem Fall kann das unzureichend gefüllte Archiv nicht verwendet werden, was Datenverluste zur Folge hat.

2 3. Optimierung der Übertragungsparameter a) ASYNC ist der wichtigste Parameter, der die Kapazität zur Unterstützung des LGWR-Übertragungsmodus beeinflusst. Er bestimmt die Größe des Puffers, der auf der Primary-Site vom LogWriter gefüllt wird, bevor der Inhalt auf die Standby-Site übertragen wird. Die Standardgröße beträgt 2048 K, also 1 MB. Der Cache-Parameter init.ora _ns_max_flush_wt bestimmt die maximale Wartezeit für Inaktivität - wenn der Puffer also nicht mehr gefüllt wird - bevor der Puffer auf die Standby-Site übertragen wird. Der Standardwert ist bei den Versionen , und unterschiedlich und reicht von 30 Sekunden bis zu 5 Sekunden. Bei Aktivität wartet Oracle mit der Übertragung nicht, bis der Puffer voll ist, sondern bestimmt nach einem internen Algorithmus den optimalen Schwellenwert für den Start der Übertragung. Wenn der Puffer voll ist, bevor er geleert wird, wird im Alert-Log die Fehlermeldung "ASYNC buffer full" ausgegeben. In diesem Fall ist der Puffer vermutlich zu klein. Unsere persönlichen Erfahrungen haben gezeigt, dass die optimale Größe je nach Version von Oracle variiert. Bei Version wird empfohlen, den ASYNC- Puffer-Parameter auf mindestens 4096 K (2 MB) zu setzen. Tritt oben erwähnte Fehlermeldung auf, wechselt Oracle automatisch in den ARCH-Modus, bis zum nächsten Log Switch bzw. Reopen. Dies verringert vorübergehend Ihren Schutz vor Datenverlusten. Der Fehler kann vermieden werden, indem man den ASYNC-Parameter auf einen Wert setzt, der mindestens doppelt so hoch ist wie der Standardwert. b) Bei Oracle Net kann der SDU-Parameter (Service Data Unit) geändert werden. Dies geschieht auf dem Client und dem Listener. Der Standardwert liegt bei 2 K. Wird er auf 32 K (32768 Bit) erhöht, liegt der Gewinn bei der Übertragungszeit bei allen Konfigurationen (ARCH, ASYNC, SYNC) bei 5-10 %. Oracle empfiehlt die Festlegung dieses Parameters. Anmerkung: Damit dieser Parameter wirksam wird, muss der Listener einen anderen Port als 1521 abhören, da es sonst zu einer automatischen Registrierung der Instanz mit dem Listener kommt, wodurch der Parameter deaktiviert wird. Standby 1 listener.ora.. SID_LIST_DGPERF_LIST = (SID_LIST = (SID_DESC = (SDU=32768)

3 (ORACLE_HOME = /mnt/app/oracle/product/9.2.1) (SID_NAME = DGPERF1) ) ) Prod 1 tnsnames.ora DGPERF = (DESCRIPTION = (SDU = 32768) (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(port = 1508)(HOST = ))) (CONNECT_DATA = (SID = DGPERF1)) 4. Optimierung des Netzwerkverkehrs über SSH In einem WAN (Wide Area Network) oder MAN (Metropolitan Area Network) kann die Netzwerkbandbreite eine der Hauptursachen für Übertragungsverzögerungen sein. Der Netzwerkverkehr zwischen der Primary-Site und der Standby-Site kann reduziert werden, indem die Datenübertragung per Port Forwarding in einem Secure Shell- (SSH)-Tunnel komprimiert wird. Durch diese Komprimierung wird die Leistung für den ARCH-Modus und den LGWR ASYNC-Modus erhöht. Für den synchronen LGWR-Modus ist die erzielte Leistung jedoch geringer. Eine detaillierte Beschreibung befindet sich in der Metalink-Note der SSH-Port Forwarding Installation. Ist SSH auf den beiden Servern installiert, hier haprd für die Primary-Site und habck für die Standby-Site, wird die Konfiguration folgendermaßen vorgenommen: Bei haprd: dg= (ADDRESS=(PROTOCOL=tcp)(PORT=1525)(HOST=habck))) (CONNECT_DATA=(SID=sales))) Bei habck: dg= (ADDRESS=(PROTOCOL=tcp)(PORT=1525)(HOST=haprd)))

4 (CONNECT_DATA=(SID=sales))) Die init.ora Parameter beziehen sich auf diese Services: log_archive_dest_2= (service=dg) fal_client=dg fal_server=dg Um die oben erläuterte Konfiguration zu ändern und SHH zum Forwarding des Datenverkehrs von DataGuard zu verwenden, wird folgendermaßen verfahren: a) SSH-Setup zur Autorisierung des Forwarding mit Komprimierung. Bei haprd als User Oracle: $ ssh -C -L 9025:habck:1525 oracle@habck Daten, die auf der lokalen Produktions-Site an Port 9025 ankommen, werden komprimiert an den Port 1525 des Host habck weitergeleitet. Bei habck als User Oracle: $ ssh -C -L 9023:haprd:1525 oracle@haprd b) Die Oracle-Services werden folgendermaßen angepasst Bei haprd: dg_ssh= (ADDRESS=(PROTOCOL=tcp)(PORT=9025)(HOST=localhost)) (ADDRESS=(PROTOCOL=tcp)(PORT=1525)(HOST=habck))) (CONNECT_DATA=(SID=sales)(SERVER=dedicated))) Bei habck: dg_ssh=

5 (ADDRESS=(PROTOCOL=tcp)(PORT=9023)(HOST=localhost)) (ADDRESS=(PROTOCOL=tcp)(PORT=1525)(HOST=haprd))) (CONNECT_DATA=(SID=sales)(SERVER=dedicated))) c) Folgende Parameter müssen für die Nutzung des SSH-Service geändert werden log_archive_dest_2=(service=dg_ssh) fal_client=dg_ssh fal_server=dg_ssh Schlussbemerkung: Der ARCH-Übertragungsmodus ist nach wie vor am leistungsfähigsten, bietet aber keinen optimalen Schutz vor Datenverlusten. Im ASYNC-Modus sollte der ASYNC-Puffer vergrößert werden, um eine entsprechende Fehlermeldung zu vermeiden. Andernfalls wechselt DataGuard automatisch in den ARCH-Modus. Der SDU-Parameter der Konfiguration von Oracle Net kann in allen Konfigurationen auf 32 K erhöht werden, um die Leistung um 5 bis 10 % zu steigern. Übertragungsverzögerungen können durch Komprimierung über einen SSH-Tunnel erheblich reduziert werden. Wenn Sie mehr über DataGuard und die erweiterten Funktionen für DBA erfahren möchten, bieten wir in unseren Schulungszentren DBA-Kurse für Fortgeschrittene an (AI9- B-DBA). Natürlich können wir Sie auch vor Ort bei der Implementierung und beim Tuning Ihrer DataGuard-Konfiguration unterstützen. Dr Gérard Schaller, Trivadis AG Trivadis AG Gerard.Schaller@trivadis.com Gérard Schaller Rue de Marterey 5 Tel.: CH-1005 Lausanne Fax: Internet: