Sünden der Vergangenheit, Part II

… of maybe 20.

2) SQL Server 2008

• Aufsetzen einer VM mit einem SQL Server 2008 (r2)
• Das letzte Servicepack draufbügeln
• Umbenennen, fixe IP vergeben

Nun muss man noch wissen, dass auch der aktuell laufende SQL 2000 schon einen Vorgänger hatte, nämlich einen SQL Server 6.5 … aus einer Zeit, wo man mit Sortierungen noch nicht gar so weit war. Wir sprechen hier über die Steinzeit, so ca. 1995.

Also tauchen wir mal in Stonehendge ein und buddeln ein wenig.

• Dumps aus dem SQL 2000 einlesen (dauert aber geht letztlich)
• Die Workstation stellt eine Verbindung her und fängt an mit dem Ding zu arbeiten, bis …

Meldung 468, Ebene 16, Status 9, Prozedur spMAWI_SelektierEinsVon1000Dingen, Zeile 46
Ein Sortierungskonflikt zwischen ‚Latin1_General_BIN‘ und ‚Latin1_General_CI_AS‘ im equal to-Vorgang kann nicht aufgelöst werden.

… und Dir fallen schlagartig sämtliche Sünden aus den vergangenen Jahrzehnten ein. Damals, weiland (wedeln mit der linken Hand Richtung Horizont) wenn Du temporäre Tabellen in SPs angelegt hattest, hattest Du munter sowas hier gemacht:

create table #tblMAWI_EinsVon100Dingen (
szArtNo nvarchar(6)
)

Nicht völlig falsch, nur dass Du Dich dabei auf die generelle Sortierung des Servers verlassen hattest. Und die ist heute standardmäßig halt nunmal eine andere als „damals“.

Tja was tun ?

• Variante a) den Server dazu zwingen eine andere Standardsortierung zu verwenden
• Variante b) rund 500 SPs durchGREPen und rund 200 finden wo create table-Konstrukte drin sind … und die alle frisch machen mittels
  create table #tblMAWI_EinsVon100Dingen (szArtNo nvarchar(6) collate Latin1_General_BIN)
  … und danach wieder einspielen

Variante a behebt das akute Problem, verschiebt die wahre Lösung aber letztlich auf den Zukunfts-Castagir. Und ob der dann noch Bock auf so was hat kann ich nicht sagen.

Variante b klingt schwer nach einer Arbeit für jemanden der Vater und Mutter erschlagen hat, ist aber trotzdem der richtigere Weg. Denn wer weiß schon was man sich in künftigen Versionen alles einfallen läßt bezüglich der Sortierung.

Na gut, Variante b) it will be. Deswegen mache ich den ganzen Scheiß ja im Vorfeld als Trockenübung, bevor ich die produktive Anlage in Grund und Boden fahre. Hängen ja nur paar hundert Arbeitsplätze dran.

Gut: Einen roadblock gefunden (es werden gefühlt ein Dutzend weitere kommen, entweder schon hier im 2008, oder auf dem Weg bis 2019, ANSI-SQL rettet Dich eben doch nicht immer)
Schlecht: Die Liste ist um eins kürzer geworden (SQL 20o8 läuft), aber dafür ist ein neuer Punkt dazugekommen (GREP, Sourcen ändern, einspielen)

Bin ich jetzt happy ? Hmm, die Jury tagt noch …

Nächster Punkt auf der Liste (frisch eingefügt) wird sein, noch mehr roadblocks im 2008er zu finden, bevor ich weiter mache.

Sünden der Vergangenheit

Manche Dinge kann man nicht durch Aussitzen beheben.

Nein, ich meine keine wichtigen Dinge – es geht um ganz einfaches IT-Zeug, hier z.B. die Vorbereitung einer Hochrüstung eines produktiven Datenbankservers von SQL 2000 -> SQL 2016/17/19.

„Na und ?? Da drück‘ ich auf nen Knopp und dann geht das“ denkt sich der Laie und liegt damit derart falsch. Denn, das was wir alle als geplante Obsolenz bei Geräten kennen, die einen Monat nach Ablauf der Garantie den Geist aufgeben – etwas ähnliches gibt es in der Softwarebranche. Nur nennen wir es dort Abwärtskompatibilität bzw. den Mangel an dieser.

Der Mangel ist nicht so schlimm, und ich verstehe (und begrüße) das Vorgehen aus technischer Sicht auch vollkommen. Nur, wenn es einen dann trifft, dann hast Du gewaltig viel Kacke am Hacken – denn Du latschst zwangsläufig auf Deinem Weg von A nach B in einen Satz Hundehaufen die wie Minenfelder auf dem Weg liegen.

Denn wenn Du Ewigkeiten die alten Versionen am Leben und produktiv lässt, dann machst Du einen Walzer – in diesem Fall:
SQL 2000 -> SQL 2008 (r2) -> SQL 2016

Didi – dada.

Und abschließend noch einen Mambo, um endlich auf dem Zielsystem SQL 2019 anzukommen.

Ich habe mir bereits die Karten gelegt – die Liste der offenen Punkte hat rund 15 Punkte.

1. Ganz simple Sache: Eine uralte alte Workstation muss den nagelneuen Server per TCP/IP erreichen können.

So eine an sich simple Sache hat mich gestern 17 Stunden gekostet (und ich denke schon Ahnung zu haben was man wie macht).

• VM aufsetzen mit dem Zielprodukt, SQL 2019 – rund 3 Stunden.
• VM anPINGen von der alten Workstation – 1 Minute.
• Alte Workstation anpingen vom neuen Server – arghhhhh! Geht nicht.

Nach einer stundenlagen Odysee durch Einstellungen, SMB-Protokolle, Router-Setups, Firewalls … ging es immer noch nicht.

Also back to basics, testen ob es ein generelles Problem sein könnte. Der Server ist brandneu, nicht verbastelt, also:

• den nagelneuen Server zurücksetzen auf den Installationszustand
• eine neue strunzdumme Workstation-VM aufsetzen – rund 1 Stunde.
• Server anpingen .. geht
• Von Server die Workstation anpingen – nanu ? Wieso geht das nicht ?
• Firewall aus
• SMB aus
• alles dreimal checken
• die allwissende Müllhalde gecheckt was es sein könnte – und dabei einen Haufen Scheiß gefunden der zwar geprüft werden wollte aber letztlich völlig am Thema vorbei ging
• Geht immer noch nicht – die Tischkante weist bereits deutliche Zahnabdrücke auf.
• Ursache: Du kannst den Scheiß zwar deaktivieren – Du musst die Kiste aber einmal booten ! Dauert ja nur wenige Sekunden … nur, nach einer Installationsorgie und Tests die sich von 9 bis 21 Uhr hingezogen hatten (nur unterbrochen von der Staubsaugerfee die ihr Lieblingsgerät intensiv geherzt hatte), kannst Du sowas durchaus mal vergessen zu tun.
• Und es ging. Sogar die ODBC-Verbindung zum Server ging (natürlich nur nachdem das Gewurschtl einen remote erreichbaren SQL-Server einzurichten viele Stunden zuvor bereits erledigt war)

Also habe ich gegen 00:02 wieder die alte Workstation hochgefahren, ihren nach einem Tag Rumgemurkse völlig verbastelten Installationszustand zurückgesetzt, und gegen 01:55 Uhr ging es tatsächlich.

…

Achso ja, die Punkte 2 bis 15 kommen noch. Yay.

Nächster Punkt auf der Liste ist also das Migrieren von SQL 2000 -> SQL 2008. Oh Mann.