M-A-O-L

Welches ist der allerbeste Artikel zum Thema Oracle Statistics?

Das Eye on Oracle fragt sich: Do Oracle Database innovations really matter?

Database 11g will boast a host of new, innovative features – such as Database Replay and its new Real Application Testing-related capabilities — but do these new fangled gadgets really matter to DBAs in the trenches?

Das frag ich mich manchmal auch. Schlussendlich ist aber nach den zwei 10g Releases auch hier wieder Manageability einer der Innovationsschwerpunkte, und da gibt es bei Oracle doch noch einiges zu verbessern.

Ja so ist es leider: 10.1.0.5 is the terminal patchset. Diese Entscheidung von Oracle, nota bene mehr als ein Jahr nach dem Release von 10.1.0.5, haben wir gar nicht gerne gesehen, denn bis anhin hat es immer geheissen, dass es noch mindestens bis 10.1.0.6, wenn nicht eher sogar bis 10.1.0.7 gehen würde.
Handkehrum kann ich ja verstehen, dass Oracle der 10gR1 Community möglichst schnell den Saft abdrehen will, und sie nach 10gR2 oder sogar 11g migrieren sollen. Denn Oracle 10gR1 spielt inzwischen mit rund 15% Verbreitung hinter 9i und 10gR2 nur noch die dritte Geige, und so möchte Oracle natürlich möglichst wenig Aufwand reinstecken, um bestehende Kunden auf dieser Exotenplattform zu unterstützen.

Aaron Newman, Gründer von von Application Security Inc., in einem Interview zum Thema Oracles Patching Policies:

You really need to refocus efforts away from new security features and onto how we fix these holes that have been around for years and years and port them to Oracle 8i or Oracle 9i or some of the other platforms that aren’t as critical. That’s what their problem is: They can patch problems quickly on 10g on Linux, but they take very, very long to back port that to Oracle 8i on the AIX platform and things like that. You have to support those people and that’s really the most critical thing I think they really need to address, rather than figuring out how to do a better auditing system.

Die grosse Anzahl Plattformen und Versionen ist sicher ein grosser Faktor bei der Reaktionszeit auf Bugs. Das Sicherheitsproblem aber einzig auf die Security Bugs zu reduzieren, wie es Newman tut, ist leider viel zu einfach. Auditing und Enterprise User Security oder Identity Management sind genauso wichtige Pfeiler in einer durchdachten Securitystrategie.
Langsam beginne ich Oracles Security-Kollegen zu verstehen, die mit manchen der Oracle-Hacker doch etwas Probleme haben.

Oracles Security Alert hat nicht nur bei uns zu grösseren Aufwänden geführt, am schlimmsten war aber die Drohung von NGSSoftware, am 31. November (nb: der November hat 30 Tage) genauere Informationen zu veröffentlichen, verbunden mit der Meinung vieler Leute bei uns, dass sich mit diesen Informationen Oracle Exploits programmieren lassen, welche ohne gültigen Oracle- oder wenigstens lokalen User auskommen. Der Dezember kam, aber keine Informationen von NGSS. Erst jetzt ist die Katze aus dem Sack: NGSSoftware Oracle Vulnerabilities. Einige der Vulnerabilities betreffen den External Procedures Listener, und seien ohne Authentisierung exploitable! Ich kann es nur immer wieder sagen: extproc muss unter Unix als nobody:nobody laufen (ab Oracle 10g der Default)!
Und weshalb hat David Litchfield die Information erst jetzt veröffentlicht? Niemand weiss es, aber offensichtlich sind die Jungs von NGSS schon wieder im Urlaub, denn die angegebenen Links zu den Informationen auf ihrer Homepage funktionieren nicht – bisher gibt’s nur das Mailarchiv als Referenz.

Oracle 10.1.0.3 für X86-64 auf SuSE 9.1 mit AMD64 ist trivial. Oracle 10.1.0.2 für X86 auf SuSE 9.1 mit AMD64 hat mehrere Klippen, die man erfolgreich umschiffen kann – aber schlussendlich geht’s trotzdem nicht. Das Software-Set ist schlichtwas unbrauchbar auf 64bit Linux.
Wenn ich früher rumgefragt hätte, wäre mir dieses Erlebnis erspart geblieben – jetzt vergess ich’s aber sicher nicht mehr!

Irgendwann find ich dann auch mal noch die Zeit, Oracle 10g auf unseren IBM Blades zu installieren: der DBA-Track des OTN sowie Werner Puschitz haben ja viele wertvolle Tipps.

Da gibt es Hersteller, die brauchen über ein Jahr, um ihre Software wenigstens im sogenannten Toleration Level für Oracle 10g anbieten zu können – haben aber gleichzeitig versprochen, dass sie schon früh am Beta-Programm von Oracle teilgenommen haben. Toleration Level heisst ja im Prinzip nur, dass ihre Software zwar gegen Oracle 10g funktioniert, aber eben nur mit den Features, die sie schon bei Oracle 9i unterstützt haben.
Dass solche Hersteller ihre Software über Jahre verkaufen können, gibt einem schon zu denken! Aber zum Glück gibt es Alternativen (die bei diesem Verhalten nicht mal unbedingt gleich gut sein müssen, Hauptsache sie liefern schneller).

So kommt es mir manchmal vor, was wir @work so treiben. Da unsere Oracle Datenbanken automatisch (d.h. skript-basiert) updatebar sein müssen, haben wir ein Perl-Framework geschrieben, das die ganze Datenbank-Administration per Kommandozeile ermöglicht. Inzwischen stecken bald 10 Jahre Arbeit drin, und der Code sieht auch entsprechend aus. Natürlich wird Code-Maintenance immer schwieriger…
Zur Zeit brennt es halt gerade im Upgrade-Modul, da das Teil sowohl die Migration von 8i auf 9i unterstützen muss, als auch Patchlevel-Upgrades z.B. von 9.2.0.2 auf 9.2.0.4. Dabei haben wir einige Annahmen getroffen, die sich nun als falsch erwiesen haben (mein Fehler – manchmal muss man halt die Details selbst nachlesen, anstatt sich auf andere Leute verlassen), und die nun in einer Express-Aktion korrigiert werden müssen. Mir graust es schon vor der nächsten Version, die dann zusätzlich noch Oracle 10g unterstützen muss. Erste Tests mit der 10g-Beta haben gezeigt, dass Oracle wieder mehr geändert hat als beim Upgrade von 8i auf 9i. Der nach einem kompletten Rewrite prinzipiell generisch ausgelegte Upgrade-Befehl kann dann wieder mit if (ORA_VERS >= 10) gepflastert werden wie damals beim Upgrade von 7 auf 8.