SSL – Das täglich Brot des Essel Krypt

Ein Erfahrungsbericht – SSL erklärt von einem der es Wissen muss

So ein neuer eingebildeter Applikationsserver names Tom Katze möchte ein Zertifikat erwerben, damit er glaubwürdig wird. Ist ja seiner Meinung nach unabdingbar, schließlich liefert der feine Herr Katze unglaublich wichtige (wichtige ist wichtig) Business Daten und das natürlich auch in wenigen Millisekunden an meinen Schwager Brauser aus. Ach, wie oft hörte ich ihn fluchen über den guten alten Datos Bank und sein Behäbigkeit, dabei ist er das eigentliche Arbeitstier. Nun aber das ist eine andere Geschichte und ich schweife ab.

Tom rief mich also gestern an und sagte:

“Guten Tag Herr Essel Krypt. Ich benötige schnellstens ein Zertifikat, um mich auszuweisen und abhörsicher mit Brauser unglaublich wichtige Dinge zu besprechen!”

“Ok!”, sagte ich. “Dann denk’ dir mal ein geheimes Passwort aus Tom.”

“Habe ich eben getan. Was nun?”

“Wie lautet es denn?”

“Businesskasper!” Stille füllte die Leitung. “Ehm… Moment mal…”

“Nun bitte ein geheimes, Tom, das ist dein privater Schlüssel.”

“Habe ich. Diesmal behalte ich es für mich.”

“Nun Tom, verschlüssele deinen Namen und deine Adressinformationen mit diesem Passwort. Das Ergebnis, den CSR, sendest du an Captain Authority, kurz CA. Der verschlüsselt das ganze noch mit seinem Passwort. Was du zurück bekommst ist dein Zertifikat, Tom.”

“Würden Sie mich bitte nicht Tom nennen Herr Krypt!?”, sagte dann Herr Katze. Weiter sprach er, “Ich habe nun mein Zertifikat. Ja, da steht es drauf, meine Adresse und mein Name, unterzeichnet von Captain Authority.”

“Der unterzeichnet mittlerweile auch alles…”, fiel mir dazu nur ein. Aber das habe ich doch nicht laut gesagt, hab’ ich? Anscheinend schon…

“Was fällt Ihnen eigentlich ein!” hörte ich seine empörte Stimme fragen. Frei heraus überhörte ich die Aussage einfach. “Dein Zertifikat ist öffentlich, Tom. Sende es an alle mit denen du sicher quatschen möchtest. Brauser benötigt nicht mehr.”

“Was macht denn Brauser mit meinem Zertifikat?”

“Die initiale Nachricht, die er an dich sendet verschlüsselt er mit deinem Zertifikat. Dein Zertifikat stellt deinen öffentlichen Schlüssel dar und es passt nur genau zu deinem geheimen Passwort, dem privaten Schlüssel.”, erklärte ich ausführlich.

“Aha, und was bringt das? Ich kenne mich mit so technischen Sachen nicht aus.”, spricht Herr Katze näselnd.

“Um die spätere sichere Verbindung einfach zu halten, müsst ihr euch auf ein gemeinsames Sitzungspasswort einigen. Das ist wie mit dem Passwort, dass du benötigst, um mit Datos Bank zu quatschen…”

“Erinnern Sie mich nicht an diesen Tekki! Dabei fällt mir ein, dass ich noch Aufgaben aus dem letzten Meeting für ihn…”, unterbricht er mich.

“Dieses Sitzungspasswort”, fuhr ich fort, “verschlüsselt Brauser mit deinem Zertifikat und schickt dir das Ergebnis zu. Nun bist du der einzige, der dieses verschlüsselte Sitzungspasswort wieder auslesen kann, denn nur dein geheimer Schlüssel macht das Gewirr wieder lesbar. Kein anderer könnte das.”

“Verstehe…”, sagte er mit vernehmbarem Unverständnis.

“Diesen Schlüsselaustausch nennt man asynchronen Schlüsselaustausch. Habt ihr euch nun auf ein Sitzungspasswort geeinigt, so kommuniziert ihr dann nur noch über dieses. Das nennt man dann synchrone Kommunikation.”

“Wie auch immer. Funktioniert das nun mit dem sicheren kommunizieren mit Brauser?”, fragte Herr Katze genervt.

“Ja, du kannst starten.”, sagt ich noch, bevor ich lächelnd den Hörer auflegte.

Die neuesten Leiden des alten Datos

Ein methodisches Vorgehen zur Oracle Performanceanalyse aus Sicht des alten Datos Bank.

Mein Name ist Datos Bank und ich bin alt. Naja, und dick. Meine Tabellen geraten aus der Form, meine CPU muss immens viel logischen I/O pumpen und häufige und viele ungesunde physische Reads sind längst keine Seltenheit mehr.

Menschen machen Sport, um abzunehmen. Und was kann ich tun? Ich friste in klimatisch perfekten Bedingungen mein Dasein, nur um dicker und dicker zu werden. Ich werde im Sekundentakt gefüttert. Mein Serverbetriebssystem SuSanna lacht mich schon aus, weil ich so einen großen Temp-Tablspace habe. Aber, wenn sie wüßte was ich so alles Joinen und Sortieren muss… Keiner achtet auf mich.

Nunja, seit kurzem verweigere ich mich. Ich brauche Aufmerksamkeit. Um die zu bekommen, liefere ich meine Arbeitsergebnisse einfach nicht mehr so schnell ab. Und siehe da, es scheint zu funktionieren.

1. Mein dicker Tabellenbauch

Man fragt mich nun auf einmal, wie groß denn meine Tabellen seien. Macht ja auch Sinn. Die größten bekommen auf einmal Indizes, die eigentlich schon lange notwendig waren. Ich fühle mich geschmeichelt, als sogar die erste sehr große Tabelle partitioniert wird. Oh, und lokale Indexe werden erstellt. Ich fühle mich gleich viel besser – leichter, übersichtlicher.

2. Meine Statements

Mein Hersteller untersucht mich andauernd auf Herz und Nieren. Ich gebe die Untersuchungsergebnisse auch gern bekannt. Hier ist mein AWR Report möchte ich manchmal gerne sagen. Aber ich kann ja leider nicht sprechen.

Ich habe aber bemerkt, dass die Statements, die mir am schwersten im Magen liegen optimiert werden. Uh, da war sogar eines mit Subquery Factoring überarbeitet. Ja, das ist schon besser. So bekomme ich es auch in den Speicher und ich brauche den Temp-Tablespace nicht. Somit kann dieser auch wieder verringert werden und SuSanna lacht mich nicht mehr aus.

3. Fremde Schlüssel

Manchmal fällt es mir halt schwer komplexe Zusammenhänge schnell auszudrücken. Ich beschwere mich dann immer im AWR Report durch TM Contention Wait Events. Nun, es scheint zu funktionieren – der fetteste Foreign Key hatte auf einmal auch einen freundlichen Index. Wieder kann ich mir logisches I/O sparen.

4. Versteher des Ausführungsplans

Ich bin doch eigentlich nicht schwer zu verstehen. Ich bin ja keine Menschenfrau. Was mir weh tut ist viel logischer I/O. Ein Ausführungsplan zeigt es: Suche doch nach dem Kürzel cr, zu sehen in jeder Zeile des Plans. Dieser Wert multipliziert mit meiner Block Size ergibt den logischen I/O, den ich bei der Ausführung eines Statements verarbeiten muss. Puh, das kann manchmal ungeahnte Größen annehmen. Und der Mensch wundert sich dann, warum ich solange brauche, um eine Antwort zu liefern.

Naja, und natürlich die Zeit.  Generell korreliert sie mit dem logischen I/O. Nun, wenn man den am tiefsten eingerückten Eintrag sucht, mit dem höchsten logischen I/O bzw. Zeit, dann hat man meistens auch schon das Problem entdeckt. Nun löse es! Durch Umstellen des Statements oder Indizes oder Konfigurationseinstellungen.

Achso, wenn du Full Table Scans entdeckst, dann meine ich das nicht böse. Das ist oft pure Absicht. FTS sind schnell! Eine Tabelle kann ich parallel einlesen. Einen Index dagegen leider nicht und wenn man bedenkt, dass ein Index oft die Größe einer Tabelle erreicht und auch überragt…

Performance – die Antwortzeit und der Lasttest

Irgendwie scheint es bei Performancemaßnahmen ein Axiom zu geben das in etwas so lauten könnte:

Ein Lasttest, mit welchem die Maßnahmen zur Performanceverbesserung überprüft werden sollen, bestätigt selten die zuvor getroffene Annahme.

Anders ausgedrückt: Das was man sich ausgedacht hatte, funktioniert nicht, weil man etwas anderes nicht bedacht hatte. Die Folge ist meist, man muß erneut starten und das Problem überdenken, ehe man auf eine korrekte Lösung kommt. Man bedenke aber die Folgen einer  “Ist doch klar” – Analyse ohne die Messüberprüfung der abgeleiteten “Ist doch klar”-Maßnahmen. Am Ende steht meist Verwirrung und ein nicht ganz “Ist doch klar”-Systemverhalten.

Oft gehört sind Aufträge an Entwickler einer Software, diese nun einfach schnell zu machen oder an den Datenbankadministrator nun die Performance durch einen Konfigurationsparamter mal eben zu steigern.

Das auch das Lasttesten, also das Überprüfen von Performancemaßnahmen, verwirrend sein kann, möchte ich im Folgenden beleuchten.