Glorf IT

Mit einer gewissen Häme nahm ich zur Kenntnis, dass die Piratenjäger angeklagt werden selber Patent-Piraten zu sein… Nicht, dass ich ein Fan von Patenten wäre, aber wer auf den Schutz des geistigen Eigentums pocht, sollte nicht nur sein eigenes meinen.

Heise-Online: US-Filmstudio soll patentierten Piraterie-Schutz unberechtigt genutzt haben

Heute weiß man echt nicht, welche Schlagzeile in Bezug auf SAP und Datenbanken interessanter ist:

SAP wirbt für seine In-Memory-Lösung

SAP haute heute eine Presseerklärung zum Thema "In-Memory-Technologie für blitzschnelle Datenverarbeitung und -analyse raus:

[Anmerkung vom Autor: Auf der SAP-Kundenkonferenz SAPPHIRE …] gab Sikka die Pläne der SAP für eine leistungsstarke BI-Anwendung bekannt, welche die Echtzeitanalyse von Live-Transaktionsdaten (in der SAP Business Suite und SAP R/3-Software) ermöglicht und einen "Turbolader" für SAP NetWeaver Business Warehouse (SAP NetWeaver BW) darstellt.

Aus der gleichen Quelle:

In nur 48 Stunden hat SAP eine parallele In-Memory-Datenbank an einem Standort eines ihrer Großkunden installiert. Laut Plattner wird sich die Implementierungszeit für einen durchschnittlichen Kunden sogar auf ungefähr zwei Stunden verkürzen. "Das Beste aber ist, dass Implementierungen ohne Änderungen an der Software des Kunden oder Einbußen an der Datenqualität durchgeführt werden. Der Kunde erhält die Schnelligkeit von In-Memory-Technologie und schützt gleichzeitig seine Investitionen und Daten", erklärte Plattner.

Der Vorteil von In-Memory-Technologie besteht laut Plattner darin, dass alle Anwender, einschließlich der Führungskräfte, dank der Schnelligkeit und Flexibilität der In-Memory-Technologie direkt auf SAP-Software zugreifen und Informationen abrufen können, die sie für ihre Entscheidungsfindung und Maßnahmen brauchen. Jegliche Fragen werden beantwortet – und das in weniger als einer Sekunde.

Leider wird nirgendwo erwähnt über welche Größenordnung von Geräten wir hier eigentlich reden: Wie viel RAM benötigen die Server, welches Betriebssystem etc. Wenn wir von Bilanzzahlen reden, dann sollte es möglich sein alle relevanten Buchungen der letzten drei Jahre im Hauptspeicher zu halten. Das dürften locker mal 100 GBytes sein. Dann ist die Frage, ob die verlinkten Daten, wie Kontobeschriftungen, Stamm-Daten der Geschäftspartner und dererlei mehr auch In-Memory sein sollen. Naja, es kann ja nicht mehr lange dauern bis auch solche Zahlen durchsickern…

Sybase-Übernahme

Offenbar sieht nicht nur Oracle in der Übernahme des Datenbanktraditionalisten Sybase durch SAP eine Gefahr. Auch IBM sieht sich zum Angriff genötigt und heuert eine Firma zur Migration der umstiegswilligen Sybase-Kunden an. Eine Chance, die man sich nicht entgehen lassen darf?
Hinweis: Man beachte das seltsame Bild zur Illustration des Umstiegs von Sybase auf IBM: darin wird der vergleichsweise einfache Migrationspfad von Sybase nach SQL Server 2000 von Microsoft beschrieben. Ich nehme an, sie haben eine 10 Jahre alte Grafik wiederverwendet – eventuell in der Annahme dass das ja keinen Unterschied mache: "DB/2 und SQL-Server, ist ja das gleiche?"

Wer kennt das nicht:

Der Weltraum, unendliche Weiten. Wir schreiben das Jahr 2200. Dies sind die Abenteuer des Raumschiffs Enterprise, das mit seiner 400 Mann starken Besatzung 5 Jahre unterwegs ist, um fremde Galaxien zu erforschen, neues Leben und neue Zivilisationen. Viele Lichtjahre von der Erde entfernt dringt die Enterprise in Galaxien vor, die nie ein Mensch zuvor gesehen hat.

In den Nürnberger U-Bahnhöfen zeigen die großen Werbeflächen abwechselnd Werbung, Nachrichten und nutzloses Wissen. Das heutige habe ich mir gemerkt:
Am 27.5.1972, also heute vor 38 Jahren, wurde die erste Enterprise-Folge im deutschen Fernsehen ausgestrahlt. Ich hatte echt gedacht, die wäre früher ausgestrahlt worden. Immerhin wurde sie in den USA ab 1966 gedreht. Aber freilich fand ich bei TV Wunschliste eine Bestätigung. Dort entnahm ich auch obige Einleitung der Serie.

Also, beam mich hoch, Scotty!

PS: Mein ehemaliger Chef hat sein System so konfiguriert, dass bei bestimmten Mails das star-trekische Com-Signal abgespielt wird. Keine Ahnung wo er es her hat, aber bei trekkieguy.com findet man es unter den Namen "Comm 02". Echt cool.

Mein Kollege Robert schickte mir den Tipp, dass es bei Quest das eBook mit dem blödsinnigen Namen "Did You Know? It’s Easy to Simplify SQL Server Management" kostenlos gibt. Leider besteht eine Registrierungspflicht. Ich gab brav eine echte Mail-Adresse an, aber es gab nur eine Bestätigungsmail für mich zur Info. Ich hätte auch eine ausgedachte oder eine von jemand anderem missbrauchen können. Mal schauen, ob ich an die Adresse nun Spam bekomme.

Ich habe das Buch mal überflogen: Es war ganz nett. Viele Grundlagen, viele Tipps. Ich halte es daher für Leute, die schon Grundkenntnisse haben und tiefer einsteigen wollen für lesenswert. Das ist nichts für Neueinsteiger, aber auch nicht für Experten. An dem Buch haben bekannte Experten mitgearbeitet, z.B. Kevin Kline. Alleine schon wegen ihm müssten eigentlich alle Quest-Software kaufen…

Die Hinweise auf weiterführende Literatur am Ende jedes Kapitels haben mir gleich gefallen. Dadurch wurde ich beispielsweise auf die SqlServerPedia aufmerksam. Konkret beeindruckte mich die Seite Index Selectivity and Column Order als gute Einsteiger-Lektüre zu dem Thema Index-Nutzung.

Wir wohnen ganz in der Nähe eines Kindergartens. Immer wenn ich etwas später zur Arbeit fahre, dann sehe ich, wie Eltern Ihre Kinder dorthin bringen. Sehr viele kommen mit dem PKW. Fast alle fahren mit deutlich überhöhter Geschwindigkeit in der 30er-Zone und viele halten im Halteverbot neben dem Kindergarten (dort soll frei bleiben, damit die Kinder beim Straße überqueren gut gesehen werden).

Jedes mal bin ich dankbar, dass unsere Kinder nicht in diesen Kindergarten gingen. Ich weiß echt nicht, ob ich die Kleinen alleine dorthin losziehen lassen würde. Damals wohnten wir noch wo anders und sie mussten recht weit gehen, sogar über eine Ampel an einer der Hauptverkehrsadern. Das klappte prima und ich machte mir keine Sorgen. Aber das hier ist echt eine andere Nummer…
Als positiver Mensch könnte man den Eltern vielleicht zu Gute halten, ihnen sei nicht bewusst, dass da ein Kindergarten ist. Aber wie könnten sie das auf dem Weg dahin vergessen?

In den letzten Jahren wurde mir immer stärker deutlich, dass die sogenannten Soft-Skills viel dazu beitragen können Diskussionen effektiv und konstruktiv zu gestalten. Leider erlebe ich immer wieder, dass gestandene Entwickler ihre guten Gedanken nicht so transportieren können, dass deren Chefs sie verstehen. Das liegt nicht immer nur daran, dass die Kommunikation an ganz grundlegenden Dingen scheitert. Manchmal sind es gerade die Feinheiten im Verständnis der Dinge.

Natürlich ist es ein Klischee, dass Entwickler sich nicht ausdrücken können, aber es stimmt, dass diese Skills weder in der Ausbildung/Studium, noch im Arbeitsalltag geübt werden. Oft genug war ich auf Schulungen in denen Kollegen saßen, die die Schulung als Strafe empfanden: "Mein Chef hat mich hier her geschickt. Er findet wohl ich habe Probleme mit der Kommunikation!" Dennoch nahmen die meisten wenigstens ein wenig mit, je nachdem wie gut der Referent die Anti-Stimmung aufbrechen konnte.

Anders ist es bei dem Artikel "Techies Talking to Non-Techies". Hier wird ein gemeinsamer Feind adressiert: die Ahnungslosen (wenigstens in Bezug auf Technik). Seien es die vom Vertrieb, vom Marketing oder die Auftraggeber. Die beschrieben Tipps sind zwar recht pauschal, aber meiner Ansicht nach dennoch nützlich, um über den Tellerrand zu schauen und sein Gegenüber zu verstehen.

Das ist meine heutige Lese-Empfehlung.

Weil ich gerade meine TSQL-Fortgeschrittenen-Schulung auf SQL-PASS-Tauglichkeit checke, kam mir der Artikel über die Performance von Common-Table-Expressions (CTE) gerade recht. Meine eigenen Recherchen ergaben auch, dass bei echt rekursiven Abfragen die Performance der CTEs mit zunehmender Datenmenge gegenüber einer "ausgeschriebenen" Lösung (mittels UNION) verliert. Das hatte ich so nicht erwartet, vor allem, wenn man sich die Zugriffspläne zum Vergleich anschaut. Aber wenn man statt dessen auf den nötigen I/O schaut, dann wird die Ursache schnell klar.

Daher ist das meine heute Lese-Empfehlung.

Im SQL Server Magazine hatte ich gerade angefangen den Artikel "Optimizing TOP N Per Group Queries" von Itzik Ben-Gan zu lesen. Dann stellte ich fest, dass er auch online frei verfügbar und in voller Länge bereit steht. Daher ist das meine heutige Lese-Empfehlung.

In dem Artikel beschäftigt er sich wieder mit einem kniffeligen Thema. Anders als in früheren Ausgaben wird das Thema aber abschließend behandelt. Das finde ich richtig gut. Es kam leider auch schon vor, dass er das gleiche Thema auf drei Ausgaben aufteilte. Das bedeutete konkret 3 Monate lang immer das gleiche mit anderen Lösungen und am Ende wusste man dann die Beste der drei. Das hat mich schon etwas genervt.

Als Lösungen untersucht Itzik:

• ROW_NUMBER zur Ermittlung der "Gruppenbesten"
• APPLY zur Ermittlung der besten pro Gruppe
• String-Concatenation zur Ermittlung des Besten pro Gruppe (sehr kreativ)

Hier kommt auch recht deutlich raus, dass es selten echte Daumenregeln gibt, sondern immer die konkrete Situation berücksichtigen muss: Welche Indexe sind vorhanden, wie sehen die Daten aus, …

Das englische Kreuzworträtsel aus Japan fand ich mal ganz nett: gamedesign.jp

Nun ist es so weit: Die Agenda für den ersten .NET Day Franken steht fest. Ich wusste ja schon, dass es eine nette Veranstaltung wird, aber das Programm verblüfft mich dann doch.

• Die Keynote hält Damir Tomicic, den ich sicher nicht weiter vorstellen muss.
• Christian Weyer erzählt etwas zu "Distributed .NET in Action – End-to-End Anwendungsarchitektur illustriert" und "Was Sie schon immer über WCF wissen wollten aber nie zu fragen wagten".
• Constantin Klein berichtet über WCF RIA Services, er ist übrigens Leiter der .NET User Group Frankfurt
• Golo Rodel widmet sich C# 4.0, er ist MVP für C#.

Das wird ganz sicher ein sehr interessanter Tag! Thomas erzählte mir, dass er aktuell daran arbeite die harte Teilnehmergrenze gemeinsam mit dem Hotel nach oben zu korrigieren. Wer unbedingt dabei sein möchte, der sollte sich bald anmelden… 😉

Durch den Artikel "IP-Adressen nur mit sicherem Routing eindeutig" bei Heise-Online wurde ich darauf aufmerksam, dass eine IP-Adresse überhaupt nicht beweiskräftig ist. Alle aktuellen Maßnahmen zur Strafverfolgung basieren aber genau darauf. Sowohl die Vorratsdatenspeicherung als auch die Verfolgung von Upload-Sündern.

In dem Artikel wird beschrieben, wie an die Öffentlichkeit kam, dass man eine IP-Adresse "durch gefälschte BGP-Routen" entführen kann. Wie ein paar Wochen passierte genau das versehentlich:

Der kleinere chinesische Internet-Provider IDC China hat sich Berichten zufolge durch einen Konfigurationsfehler eines BGP-Routers kurzzeitig für das Routing zu rund 37.000 IP-Netzen zuständig erklärt. Über das Border-Gateway-Protocol signalisieren sich Router, für welche Netze (autonome Systeme, AS) sie zuständig sind und welche anderen Netze sie erreichen können.

Hauptsächlich soll der chinesische Provider Routen zu Netzen (BGP Prefixes) verkündet haben, die zu anderen Providern in den USA und China gehören. Zu den propagierten Netzen sollen auch die von Dell, CNN, Apple, www.amazon.de, www.rapidshare.com und www.geocities.jp gehört haben.

Die Frage wie wahrscheinlich es ist, dass genau das bereits passierte ist Einschätzungssache. Je weniger Aufwand es ist, desto wahrscheinlicher dürfte es sein. Was braucht es also dazu?

• Einen Internetprovider (ein Kleiner reicht, es muss nicht der eigene sein)
• mit einem falsch konfigurierten BGP-Router.

Dabei muss der Provider noch nicht mal ein Böser sein. Es reicht schon menschliches Versagen des Personals aus. Wenn jemand ein krummes Ding im Internet drehen will, dann könnte er auch in der Lage sein sich in einen Router eines kleinen Providers reinzuhacken und ihn zu konfigurieren. So lange nicht eine große Anzahl von IP-Bereichen "übernommen" wird, sondern nur ein kleiner Bereich, z.B. mit dem Ziel seine echte IP-Adresse zu verschleiern, dürfte das wohl keiner bemerken. Daher stufe ich das als "machbar" ein. Das schockt mich jetzt.

Haben auch andere Probleme mit Routern die Konsequenz, dass es zu Fehlern bei der IP-Adressen-Zuordnung kommen kan? Die scheinen ja gar nicht so selten zu sein.

Mit der aktuell erschienen Version versucht Sybase offenbar nun verlorenen Boden gut zu machen. Nach so vielen Jahren Stillstand würde ich einen großen Wurf erwarten, aber es kam doch nur eine Minor Version heraus: 15.5

• Version 11.0: 1995
• Version 11.5: 1997
• Version 11.9: 1998
• Version 12.0: 1999
• Version 12.5: 2001
• Version 15.0: 2005
• Version 15.5: 2010

Zuletzt schaute ich die Version 12.0 an und kehrte dem Sybase SQL Server dann enttäuscht den Rücken. Wenn es jetzt mit dem Sybase SQL Server durch den geplanten Kauf durch SAP wieder bergauf geht, dann könnte daraus eine Alternative zum Microsoft SQL-Server erwachsen, dessen Preise mit dem R2 nun erst wieder erhöht wurden. Ohne die Aktion hätte ich die Version 15.5 vermutlich auch einfach ignoriert… Aber wer weiß, vielleicht krempelt SAP den Laden ja mal richtig um. Das würde mir gefallen.

Daher sammele ich mal hier, was mich damals am Sybase Adaptive Server Enterprise enttäuschte. Vielleicht hat sich mit der Version 15.5 hier ja schon etwas getan oder mit SAP geht wirklich etwas voran?
Wer immer hier Erfahrungen beitragen kann, der ist eingeladen das mit Kommentaren zu tun.

• Die Installation war in Java implementiert, kompliziert und fehleranfällig. Man musste echt viel tun. Daher haben wir damals auf einem Referenzsystem installiert und dann den SQL-Server durch Copy und Paste auf die Systeme unserer Kunden aufgebracht. Zum Glück schrieben sie nur wenig in die Registry. Für die Installation war so viel Insiderwissen nötig, das wäre für unsere Kunden niemals tragbar gewesen.
• Die Werkzeuge waren ebenfalls in Java geschrieben: was damals ein Synonym zu "langsam" war. Heute – also 10 Jahre später – sind die Rechner ja zum Glück so schnell, dass das kein Problem mehr sein sollte, oder etwa doch?
• Datenbanken musste man von Hand vergrößern. Es musste sich tatsächlich ein Support-Mitarbeiter per Fernwartung aufschalten und die Datenbank vergrößern, wenn die Grenze erreicht war. Das war einer der Killer und Motor für den Umstieg auf Microsoft. Unsere Kunden haben halt keinen Admin.
• Auch die TempDB wuchs nicht dynamisch. Es kam deswegen regelmäßig vor, dass Datentrafos wegen der TempDB abbrachen. Das war in der Praxis das häufigste Problem.
• Man konnte nicht einfach eine Datenbank verschieben. Wenn es bspw. ein Problem gab, dann konnte man nicht einfach die Datenbank-Dateien von den Kunden reinholen und anschauen. Die Datenbank dann an einen anderen SQL-Server dran zu bringen, war eine größere Wissenschaft, wenn man nicht die Details zu den Devices (Verteilung und Reihenfolge des Anlegens) mitgeliefert bekam. Das war echt krank und ebenfalls ein Killer für uns.
• Jeden Kleinkram musste man konfigurieren: Man musste angeben wie viele parallele Connections erlaubt waren. Dafür wurde der nötige Speicher vorallokiert. Kam dann eine Connection mehr, dann wurde die abgewiesen. Es gab keinerlei Dynamik: Was konfiguriert war, wurde an Speicher benötigt, man musste das Maximum rausfinden und dann einstellen. Das galt für alle wichtigen Dinge: jede Puffergröße wurde manuell eingestellt. Megalästig und für unsere Kunden der Horror.
• Damals begannen wir ODBC zu nutzen. Die mitgelieferten ODBC-Treiber kamen nicht von Sybase, sondern von einem Dritthersteller. Sie waren schlecht. Dito mit OLEDB. Als wir mit .net anfingen und bei Sybase wegen Konnektoren nachfragten, wussten die Entwickler über dem Teich noch nicht mal was ADO.net war und vertrösteten uns darauf, dass sie sich das anschauen würden, wenn das auf dem Markt etabliert sei.
• Die Fehlerbehandlung mit Abfragen von @@ERROR war krude, umständlich und fing nicht alle Fehler ab.
• Die Zeit-Datentypen und -Funktionen waren umständlich und ungenau. Leider war das bei Microsoft ja bis kürzlich auch noch so.
• Das Backup war umständlich. Man musste immer zuerst ein Dump-Device anlegen. Ein Backup direkt in eine Datei ging nicht. Dementsprechend umständlich war die Rücksicherung bzw. das Neuaufsetzen eines alten Systems.
• Der Upgrade einer Version auf die nächste war sehr schwierig und fehleranfällig. eine automatischer Upgrade in place war mit vielen Unwägbarkeiten verbunden.

Ergänzungen und Aktualisierungen sind willkommen…