Glorf.it

Glorf IT

Bedenkliches aus dem IT-Alltag

18. Mai 2010 um 23:34

zauberhafte Glühbirne

Ganz schon viel Arbeit. Aber wenn es funktioniert, dann ist es sicher recht witzig.

18. Mai 2010 um 19:58

Kreuzworträtsel mal anders

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

17. Mai 2010 um 22:12

Programm des .NET Day Franken steht fest

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.

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… 😉

17. Mai 2010 um 19:03

Wie eindeutig ist eine IP-Adresse?

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.

16. Mai 2010 um 23:27

Frühere Schwächen des Sybase SQL-Servers

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…

16. Mai 2010 um 19:40

Traceflag, falls Server nicht mehr reagiert

Mit dem SQL Server 2008 und dem SP3 für SQL Server 2005 hat Microsoft den Fehler beseitigt, der auf CPUs mit Stromsparfunktionen regelmäßig zu Timingproblemen führte. Die Meldungen sahen dann etwa so aus:

CPU time stamp frequency has changed from 191469 to 1794177 ticks per millisecond. The new frequency will be used

Das war nicht wirklich schlimm, die dauernden Fehlermeldungen in der Ereignisanzeige nervten aber ausgesprochen. Betroffen waren nur Performancemessungen. Auch wir bekamen regelmäßig beunruhigte Nachfragen seitens unserer Kunden zu diesen Fehlermeldungen. Details zum behobenen Problem stehen in KB931279: der SQL Server 2005 entnimmt seit SP3 die Zeiten nicht der dem CPU-Counter (RDTSC), sondern ähnlich wie die Multimedia-Time. Details zu den genauen Unterschieden beschreibt Bob Dorr (Microsoft) im Artikel "How It Works: SQL Server No Longer Uses RDTSC For Timings in SQL 2008 and SQL 2005 Service Pack 3 (SP3)".

Risiken und Nebenwirkungen

Manchmal haben Änderungen in der Software Risiken und Nebenwirkungen, die man so nicht erwarten würden. So ging es Microsoft an dieser Stelle offenbar. Ein netter Kollege machte mich auf den kürzlich dazu erschienen Artikel von HP aufmerksam:

ProLiant servers that have multiple processor cores and that are running Microsoft SQL Server 2005 SP3 or SQL Server 2008 may stop responding when under a heavy I/O processing load. If Automatic Server Recovery (ASR) is enabled on these servers, the server may reboot when the server stops responding.

SQL Server 2005 SP3 and SQL Server 2008 use mmtimer (Multimedia) timer rather than the RDTSC timer, which changes the clock granularity (to 1ms). This change may result in clock-drift or an unresponsive server if the server uses enhanced power management technologies that change CPU frequencies.

Weitere Details siehe HP Customer Advisory c02110402. Ich persönlich denke, dass es nicht nur HP-Server treffen kann, sondern auch andere Server mit "enhanced power management technologies that change CPU frequencies". Ich hörte noch von keinem konkreten Problem in meinem Umfeld, aber kann jetzt gezielt nach solchen Symptomen Ausschau halten.

Abhilfe

Das als Abhilfe vorgeschlagene, undokumentierte Trace-Flag 8038 scheint nur Auswirkungen auf die Tracing-Ausgaben und Timing-Features zu haben, die SQL-Zeitfunktionern arbeiten wie gehabt auf Basis von 14ms-Ticks. Hat jemand schon Erfahrungen mit diesem Traceflag gesammelt?

15. Mai 2010 um 22:24

Vom SQL Server benötigte .Net-Runtimes

Ich muss zugeben, dass ich da tatsächlich schon den Überblick verloren habe: Jede SQL-Server-Version benötigt eine andere .net-Runtime. Meistens kommt ja die richtige Version gleich mit, was aber vor Installationsproblemen nicht schützt.

Daher hat Microsoft nun eine Übersicht erstellt in der man die Unterschiede genau nachlesen kann: "KB2027770 – Understanding the .NET Framework requirements for various versions of SQL Server"

15. Mai 2010 um 21:14

Roboter parkt rückwärts mit Power-Slide ein

Im dem Golem-Artikel "Junior parkt ein wie James Bond " wird beschrieben, wie ein roboter-gesteuertes Auto rasant einparkt:

Das Auto nimmt rückwärts Anlauf und platziert sich mit quietschenden Reifen und einer 180-Grad-Drehung in einer Parklücke.
Das hätte James Bond kaum besser hinbekommen: Mit einer Geschwindigkeit von etwa 40 km/h rast das Auto heran, bremst, reißt das Steuer herum und rutscht gekonnt in einer 180-Grad-Drehung in eine Parklücke. Nur: Dieses Auto ist ein VW und kein Aston Martin, und der Fahrer ist kein Mensch, sondern ein Roboter.

Das hätte ich sicher nicht so gut hinbekommen:

Respekt!

15. Mai 2010 um 19:40

R2 sprachlich gebunden

Mein Kollege Robert machte mich darauf aufmerksam, dass er Schwierigkeiten bei der Installation der deutschen Version des neuen SQL Servers 2008 R2 hatte:

SQL Server setup media does not support the language of the OS or does not have ENU localized files. Use the matching language-specific SQL Server media or change the OS locale through control panel.

Die Lösung ist bei Microsoft-Connect beschrieben: Man muss bei seinem Windows "Deutsch (Deutschland)" (de-de) als Sprachformat eingestellt haben. "de-at" verursacht hingegen einen Fehler.

13. Mai 2010 um 11:10

SAP: In-Memory um jeden Preis?

Als ich heute las, dass SAP die Firma Sybase übernehmen möchte, fiel mir als erstes der frühere Konflikt zwischen SAP und Sybase ein: Weil Sybase sich weigerte Satz-Sperren einzuführen, gab SAP die Devise aus, dass deren Kunden keine Sybase-Datenbanken nutzen konnten. Microsoft hingegen schon. Dabei unterstütze der damalige MS SQL Server 6.5 genauso wenig Seiten-Sperren. Microsoft beschrieb einfach, wie die Kunden das System so konfigurieren konnten, dass auf einer Seite nur ein Datensatz stand. Und deswegen wurde damals der Einsatz des Microsoft SQL Servers empfohlen.

Aber auf den zweiten Blick macht der Ankauf viel Sinn: Neben den bekannten und begehrten Technologien im mobilen Umfeld, kann SAP den In-Memory-Bereich nach vorne bringen. Auf der deutschen Webseite von Sybase steht:

Wir machen dies zur Realität. Die neue In-Memory (hauptspeicherbasierte) Datenbank Sybase ASE 15.5 bietet:

* Schnellste Transaktionsverarbeitung
* Einfache Integration
* Kostenersparnis

> Sie müssen uns nicht glauben. Sie können es selbst herausfinden: Download der kostenfreie Testversion.

Aber auch für Sybase bietet der Kauf eine Perspektive: Nachdem Sybase im etablierten Markt in die Bedeutungslosigkeit versank und ihren SQL Server nur noch in Nischen platzieren konnte, können sie mit dem entsprechenden Engagement und der Weiterentwicklung des Sybase SQL Servers (heißt jetzt "Adaptive Server Enterprise") als vierter großer Anbieter durchaus zurück in die Charts kommen. Sybase erbrachte in den letzten Jahren im Wesentlichen durch den Sybase iAnywhere Innovationen und Umsatz. Das System kam durch den Zukauf des Watcom SQL Servers (Powersoft) zu Sybase und wechselte dann mehrfach den Namen: Watcom SQL Server, SQL Anywhere, Adaptive Server Anywhere und nun iAnywhere. Und das System ist wirklich gut und ist der Grund warum Microsoft die Compact Edition verschenken muss.

Leider wurde der Sybase SQL Server in all den Jahren wegen des Umsatzeinbruches in dem Bereich kaum weiter entwickelt. Hier täuscht die Versionsnummer 15.5: er sprang direkt von Version 12.5 auf Version 15… 😉 Sybase unterschätze den Bedarf im kleinen und mittleren Segment: Wegen der umständlichen Handhabung und der andauernden Konfigurationsorgien konnte er sich nicht mehr behaupten. Ach ja: und die Tools waren das Grauen schlecht hin. Dabei hatte er schon früh einige gute Innovationen, die Microsoft auch heute noch nicht bietet, z.B. die Pufferpools: Man kann einzelnen Datenbereichen feste Puffer-Bereiche zuweisen, sogar mit unterschiedlichen Seitengrößen. Dann können deren Seiten nicht von anderen aus anderen Pufferpools verdrängt werden. Das ist echt klasse. Um etwas Vergleichbares zu erreichen, müsste man bei Microsoft schon mehrere parallele Instanzen aufbauen. Ich habe das Sybase-System leider aus den Augen verloren, aber ich vermute, dass die neue In-Memory-Technologie nichts anderes ist als dass es einen riesigen Pufferpool für eine feste Datenbank gibt, die komplett in den Speicher passt. Sybase schreibt dazu:

In-memory databases are ASE databases that have zero disk footprint and reside completely in memory. Sybase is the first relational database server vendor to provide a fully integrated in-memory database capability within a traditional disk-based database server.

Wer nun aber denkt, dass Sybase schon fast tot ist, der irrt sich, denn die Sybase-Aktie konnte sich in den Jahren auch beachtlich erholen und das Unternehmen steht so gut da wie schon lange nicht mehr. Eine sehr gute Ausgangsbasis. Sogar im Data-Warehouse-Bereich hätte SAP damit eine gute eigene Lösung anzubieten. Hoffentlich übernehmen sie sich bei dem Kauf nicht. Das fände ich schade. Eine Belebung des Datenbank-Marktes kann uns Kunden nur nutzen. Ich denke ich werde mal eine Wunschliste machen, was mir damals am Sybase SQL Server fehlte. Wer weiß vielleicht haben sie an manchen Stellen etwas getan oder werden es unter SAP tun…

Update: Wie die In-Memory-Datenbanken genau funktionieren, wird in einem Whitepaper beschrieben. Es ist tatsächlich nur ein spezieller Pufferpool:

inmemory_storage cache is no different from regular named caches. sp_cacheconfig with the new cache type nmemory_storage will create the named cache for hosting the in-memory database with NONE as the buffer placement strategy. The following example creates the named cache imdb_cache for the in-memory database:
1> sp_cacheconfig ‘imdb_cache’, ‘300M’, ‘inmemory_storage’
2> go
The change is completed. The option is dynamic and ASE need not be rebooted for he change to take effect.

Das ist eine schlaue Nutzung/Weiterentwicklung einer schon vorhandenen und bewährten Technologie.

11. Mai 2010 um 23:31

lokale Gruppenrichtlinien anzeigen

Wer gerne mal lokal mit den Gruppenrichtlinien rumspielt oder den Verdacht hat, dass mit den Gruppenrichtlinien etwas nicht stimmt, der kann ab Vista beruhigt aufatmen. Hier kann man mittels des Kommandozeilen-Werkzeugs GPRESULT einen Bericht in HTML oder XML erstellen lassen.

HTML-Seite zur Anzeige im Browser:
gpresult /F /H "%TEMP%\gp.htm"

XML-Dokument zur Weiterverarbeitung mittels XSLT oder XQuery:
gpresult /F /X "%TEMP%\gp.xml"

Weitere Tipps gibts bei Ask the Directory Services Team.

10. Mai 2010 um 21:10

In-Memory-Datenbanken

Via Silikon.de erfuhr ich heute Neues zu dem neuen SAP-Lieblingsthema "In-Memory-Datenbanken". In dem Video "Hasso Plattner interviewt Hasso Plattner" wird im Vorfeld der Sapphire (16. – 19.5.2010) beschrieben, wie sich Prof. Plattner die In-Memory-Datenbanken vorstellt.

Aber bevor ich auf den Inhalt eingehe, muss ich das Video kommentieren, dass ich echt klasse finde: Ein auf typisch amerikanisch gestylter Journalisten-Hasso befragt einen lockeren Fachmann. Im Hintergrund ein Bild a la Warhol mit vielen Hasso-Köpfen. Mittendrin ist der Journalist von den langen Ausführungen so gelangweilt, dass er mit einem Rubiks-Cube rumspielt. Selten war Werbung so unterhaltsam.

OK, vor etlichen Wochen schauten wir uns mal PowerPivot von Microsoft an und waren schwer beeindruckt. Hier wird ja auch die In-Memory-Technik verwendet. Daher glaube ich schon, dass hier viel Potenzial liegt. Leider kenne ich den "Business Objects Explorer" nicht, das ist offenbar das bislang einzige In-Memory-Produkt von SAP.

Interessant in dem Silicon-Artikel ist auch die Beschreibung zu GemStone (frisch von VMWare gekauft):

VMware will mit dieser Technologie das Cloud Computing leistungsfähiger machen. Denn GemStone bietet mit GemFire Enterprise ein Produkt an, das eine komplette Datenbank einer Cloud-Anwendung in den Arbeitsspeicher lädt, wodurch die Anwendungen deutlich schneller Daten schreiben und lesen können.

Die Informationen werden in einer Art Middleware, die auch auf verteilten Umgebungen laufen kann, zwischengespeichert und in bestimmten Abständen in traditionelle Datenbanken zurückgeschrieben. GemFire wurde bislang vor allem von Finanzinstituten verwendet. Der Vorteil für die Anwender ist, dass auch regional verteile Niederlassungen diese Technologie simultan nutzen können.

Das klingt doch schon recht konkret. Mal sehen wie lange es dauert, bis man das in normalen Anwendungen nutzen kann…