Optimale Online Diagnose von RAC Datenbanken Johannes Ahrends Technical Director Quest Software GmbH

Transkript

1 Optimale Online Diagnose von RAC Datenbanken Johannes Ahrends Technical Director Quest Software GmbH Copyright 2006 Quest Software

2 Quest Software Gegründet 1987, an der Nasdaq seit Mio. US-Dollar Umsatz im Jahr 2005 Wachstum von 22% ca Mitarbeiter 43 Niederlassungen über Kunden ca Mitarbeiter in R & D $M USD '99 '00 '01 '02 '03 '04 05

3 Around the world Irvine Columbus Montreal Chicago Toronto St. Louis Ottawa Detroit Calgary Seattle Pleasanton Denver San Dallas Francisco Houston Mexico Guatemala El Salvador Panama New York Boston D.C. Raleigh Atlanta Colombia Peru Westlake Halifax Venezuela Brazil Norway Denmark Netherlands Sweden Finland Lithuania/Latvia UK Germany Poland Ireland Estonia Hungary Belgium Romania France Slovenia/Croatia Spain Turkey Italy Portugal Greece Israel U.A.E. Saudi Arabia Russia China India Thailand Singapore Malaysia Indonesia Korea (South) Taiwan Japan Hong Kong Chile Uruguay Argentina South Africa Australia New Zealand

4 Quest Software in D/A/CH gegründet Mitarbeiter aktuell: ca. 100 Mitarbeiter EMEA1 Headoffice in Köln Quest Software GmbH in Zürich Niederlassungen in Hamburg Frankfurt München Kunden 95%+ der Top 500

5 Quest Lösungen Database Management Verwaltung von Datenbanken während ihres gesamten Lebenszyklus, von der Entwicklung bis hin zum Einsatzsupport Application Performance Management Robuste Management Lösungen um Performance-Probleme bei Anwendungen zu erkennen, zu analysieren und zu lösen Infrastructure Management Umfassende Funktionalität, um Windows und Unix Infrastrukturen zu Verwalten und zu integrieren.

6 Online Diagnose von RAC Datenbanken Alle Informationen auf einen Blick Datenbank-Dateien Interconnect Automatic Storage Manager Einzelne Instanzen Cluster Overhead

7 Interconnect load: Anzahl Blöcke, die zwischen den Instanzen über den Interconnect übertragen werden Blocks In/Out über den Network Durchschnittliche Interconnect Zeit für den Transfer eines Blockes über den Interconnect Prozentsatz Prozentsatz der Gesamtzeit der Zeit, für den in denen die Standard SpeicherRequest und IO und Datenbank dieübertragung einen Block einesnicht lokal Status einer Metriken Blockes über gefunden Interconnect hat sondern einen Gesamtaktivität für die gesamte des der RAC- Clusters ASM einzelnen Instanz Umgebung Der Grad der Gleichverteilung Request auf des eine andere Instanz Der Interconnect Instanz Load imund Cluster der ausführen Gesamtstatistiken musste. Bereich Globale Prozentsatz Status der zeigt Instanzen im der RAC die übergreifenden Cluster die Statistiken derzeit erreichbar Durchschnittliche Blocks Datenbank In/Out sind auf Zeit das IO des Netzwerk Interconnects für Subsystem das Lesen eines Blockes von Disk

8 Segment Master Für jedes Segment (Tabelle, Index, Partition) der Datenbank gibt es im RAC eine Instanz die Master, d.h. Verwalter des Segmentes ist. Für jeden Block, auf den eine Instanz zugreifen möchte (außer lokalen), muss sie den Master fragen, woher sie den Block bekommen kann. Mögliche Antworten: Der Master hat den Block Eine dritte Instanz hat den Block Der Block muss von der Platte gelesen werden

9 Ich brauche emp #2 Instance #1 braucht emp #2 Hier sind sie SELECT * FROM emp WHERE empno= 2 Ich bin der Master der emp Tabelle Ich habe die Daten für empno 2

10 Ich brauche emp #2 Lese sie von der Platte SELECT * FROM emp WHERE empno=2 Ich bin der Master der emp Tabelle Disk Zugriff

11 RAC skaliert gut, wenn Die Last gut Die zwischen Zeit für die den Instanzen verteilt istdatenübertragung über den Interconnect Der Overhead der Clusterverwaltung viel kleiner ist als der gering ist gegenüber der Plattenzugriff Gesamtlaufzeit

12 Performanceoptimierung im RAC Optimale Performance der Datenbank nur bei optimaler Performance aller Instanzen Engpässe auf einzelnen Instanzen schlagen auf die gesamte RAC Datenbank durch Wichtige Data Block Engpässe: Row level locks Latches (cache buffers chains) Buffer busy waits (data block/free lists) Sequences

13 Balancing Probleme Hohe Last auf dieser Instanz Verzögerung auf anderen Instanzen, weil sie auf Daten der kritischen Instanz warten

14 Interconnect Latency Die RAC Architektur erwartet, dass es eine sehr geringe Latenzzeit des Interconnects gibt. Das bedeutet: Der Interconnect muss optimal konfiguriert sein Der Interconnect muss eine dedizierte Leitung haben

15 Interconnect Best Practices Metalink Note Nr Gigabit Ethernet Keine Crossoverkabel UDP Buffersize auf OS Maximum UDP Checksumming einschalten

16

17 Interconnect Aktivität Je größer die Interconnect Aktivität, desto größer der Cluster overhead: Skalierbarkeit sinkt Interconnect Aktivität minimieren durch: Anwendungen trennen (DWH, OLTP) Dedizierte Benutzergruppen (Nur dann gibt es kein Loadbalancing mehr) Partitionierung von kritischen Tabellen

18 Cluster waits

19 Ab 6 Instanzen Aufbau von Instanzgruppen

20 Spotlight On RAC Architektur Client-Installation Kein Agent auf dem Server Schema in der Datenbank für Speicherung von Basisdaten Keine DBA-Rechte für das Schema erforderlich Auswertung von Data-Dictionary Informationen Performanceinformationen über V$-Views Schwellenwerte individuell einstellbar ASM-Instanz Überwachung integrierbar Drill-Down in einzelne Instanzen

21 Weitere Informationen Copyright 2006 Quest Software