Du weißt natürlich, dass du eine Oracle Datenbank Standard Edition 2 im Einsatz hast, denn schließlich hast du ja auch die Standard Edition 2 lizenziert. Glaubst du? Oder weißt du es?

Glauben ist gut, ein SQL-Befehl in diesem Fall besser. Nicht selten kommt es vor, dass Kunden fest davon überzeugt sind, eine bestimmte Edition installiert zu haben. Ebenso nicht selten gibt es dann jedoch eine böse Überraschung, wenn sich im Falle eines Audits herausstellt, dass es doch nicht so ist. Im schlimmsten Fall können hier Lizenznachforderungen in Größenordnungen auf einen Kunden zukommen. Diese Art von Überraschungen mag niemand. Doch wie kannst du herausfinden, welche Datenbank Edition und/oder Datenbank Version tatsächlich installiert ist? Mit dieser simplen Abfrage gehst du auf Nummer sicher und kannst einen Abgleich mit vorhandenen Lizenzen vornehmen.

Es lohnt sich von Zeit zu Zeit, mit dieser simplen Abfrage auf Nummer sicher zu gehen und einen Abgleich mit den vorhandenen Lizenzen vorzunehmen. Kommt es hier zu Abweichungen, solltest du entsprechend handeln. Die Spezialisten von ASPICON unterstützen dich auch gern in allen technischen und lizenzrechtlichen Fragen.

Wir haben uns in den ersten beiden Teilen unseres kleinen Rundumschlages zum Thema Dbvisit Standby Multiplatform v11 bereits grundsätzlichen Themen als auch dem Einsatz von Dbvisit für SQL Server gewidmet.

• Dbvisit Standby MP v11 – Getestet für SQL Server!
• Dbvisit Standby MultiPlatform (MP) v11 – We are excited!

Das Anlegen je einer Diskgroup pro Oracle Datenbank kann auf Systemen mit vielen Datenbanken leicht aufwändig, unübersichtlich und fehleranfällig werden. Eine perfekte Lösung für dieses Problem, stellen wir dir in diesem Beitrag vor:  FLEX-Diskgroups mit Quotagroups.

Die seit jeher im Automated Storage Management (ASM) bekannten EXTERNAL‑, NORMAL- oder HIGH-Redundancy-Diskgroups haben ein Problem gemeinsam: Datenbanken in diesen Diskgroups können sich mehr oder weniger beliebig des Platzes bedienen. Laufen mehr als eine Datenbank im ASM, konkurrieren diese also um Platz und können sich im Extremfall durch Ausreizen des Freiplatzes gegenseitig zum Stillstand bringen. Bei den genannten Diskgroup-Typen behilft man sich daher gern damit, für jede Datenbank eine eigene Diskgroup bereitzustellen. Das kann auf Systemen mit vielen Datenbanken sehr schnell unübersichtlich werden. Und es schützt letztlich noch nicht davor, dass sich ein DBA mit mangelnder Selbstdisziplin „mal schnell“ aus einer anderen Diskgroup bedient, weil er gerade dringend Platz benötigt.

Diesem Problem begegnet Oracle mit einem Quotakonzept, das eines der Features von FLEX-Diskgroups ist. Die Umsetzung erfolgt dabei über zwei Konstrukte, die Filegroup und die Quotagroup, auf die wir im Folgenden genauer eingehen.

Oracle bietet eine Fülle von leistungsstarken Funktionen an, die unsere Arbeit erleichtern sollen. Grundsätzlich ist das ja nichts Schlechtes. Wenn man dadurch jedoch in eine Kostenfalle tappt, weil man möglicherweise Features nutzt, die gar nicht lizenziert sind, kann das schnell teuer werden. Denn trotz erheblicher Einschränkung sind nach wie vor auch in der Oracle Datenbank Standard Edition einige Features der Enterprise Edition verfügbar. Für diese Features ist unter Umständen eine separate Lizenz oder die Lizenzierung einer speziellen Option nötig. Aktiviert man diese Funktionen nun ohne die entsprechende Lizenzierung – ob gewollt oder ungewollt – kann das kostspielige Konsequenzen im Hinblick auf Lizenzverstöße nach sich ziehen. Das gilt nicht nur für die Standard Edition (/One), sondern zum Teil auch für die Enterprise Edition.

Was du tun kannst, um die versehentliche Nutzung von Enterprise Edition Features so gut wie möglich zu vermeiden, was du dennoch beachten solltest und bei welchen Features besondere Vorsicht geboten ist, haben wir im folgenden Beitrag für dich zusammengefasst.

Die Oracle Clusterware ist ein wichtiger Bestandteil der Oracle High Availability Architecture. Ressourcen, die unter Kontrolle der Clusterware stehen, werden überwacht, bei Systemstart automatisch hoch gefahren und nach einem Absturz neu gestartet oder auf einen anderen Server verschoben. Der Haupteinsatzzweck der Clusterware ist aber vor allem die Absicherung eines Serverausfalls.

Ein Cluster ist aufgrund seiner Komplexität anfälliger für Störungen in der Infrastruktur. Und eine der fatalsten Störungen ist der, auch nur vorübergehende, Ausfall des Netzwerk-Heartbeats zwischen den Clusterservern. In einem solchen Fall ist eine Kommunikation zwischen allen Clusterservern nicht mehr möglich und die Konsistenz des Clusters potentiell gefährdet. Wie die Oracle Clusterware darauf reagiert, ist insbesondere in Failover-Konstellationen von essentieller Bedeutung. Der heutige DBA-Tipp beschreibt, was du in diesem Umfeld beachten musst, damit dein High-Availability-Ansatz nicht „nach hinten losgeht“.