relevante Indizes in MSSQL neu aufbauen

Hallo mal wieder,

wenn Tabellen häufig geändert werden, seien es Inserts oder Updates, kommt es immer mal vor, dass die Queries mit der Zeit immer langsamer werden, weil die Indizes auf den Tabellen nicht mehr optimal funktionieren. Speziell im Hinblick auf Reaktionszeit ist das echt unschön.

Eigentlich wollte ich eine regelmäßige Analyse der Indizes für Cutworks in den Aufgabenplaner packen, irgendwie habe ich das immer als relativ unwichtig regelmäßig nach hinten geschoben.
Kein Wunder also, dass der Shop immer langsamer und langsamer wurde.
Heute habe ich im Zuge eines Updates mal geschaut, wie das eigentlich noch ging, ich hatte mal vor relativ langer Zeit ein Script im Internet gefunden, es ausgeführt und dann wohl weggeworfen. Glücklicherweise bin ich durch kurze Google-Suche fündig geworden:

https://gallery.technet.microsoft.com/scriptcenter/Rebuild-and-Reorganize-7ff5624e

Als ich das auf dem Cutworks-Server mal durchlaufen lassen habe, ist mir fast schlecht geworden – ein Großteil der Indizes war extrem stark „fragmentiert“ und musste neu aufgebaut werden. Großen Dank an den Verfasser des entsprechenden technet-Eintrags, für das echt gut funktionierende T-SQL-Script.

 

Kurz vorm GAU bei der Windows 10-Aktualisierung

Hallo,

heute mal wieder eine kleine Anekdote aus dem typischen Alltag. Heute hatte ich einige Momente, die mich wirklich viel Nerven gekostet haben und wer ist daran Schuld – Microsoft!!!

Aktuell entwickle ich vorwiegend auf meinem Notebook, schließe das über ein paar Kabel in meinem Büro an die Monitore und Tastatur/Maus an, kann aber auch wenn ich mal Lust habe, zu Hause noch was machen. Die allgemeine Geschwindigkeit auf dem Teil ist zwar einen Tick langsamer als auf meinem Desktop-Rechner, trotzdem lässt es sich aufgrund der NVMe-SSD ziemlich gut arbeiten.

Heute morgen habe ich, bevor ich ins Büro bin, noch etwas Cutworks-Support gemacht. Anscheinend gab es mal wieder ein Windows-Update (März-Update) , beim Herunterfahren habe ich mich daher entschieden, Windows zu aktualisieren.
Dann im Büro hat er die Updates eingespielt und nach dem 2. Reboot, dann erst mal die Ernüchterung: Grub startete nicht mehr, ging also in den rescue-Modus und präsentierte mir folgenden Bildschirm:

WTF?? Super, das Update hat wohl die komplette GRUB-Installation geschrottet. Also als erstes habe ich dann mal das Manjaro-Live-System gebootet – ein Krampf auf meinem Notebook, weil der Boot standardmäßig bei der MHWD-Initialisierung hängenbleibt,  aber nach dem Auskramen einiger Linux-Kernel-Parameter irgendwann ging es dann doch. Dann habe ich nach typischer Anleitung folgendes gemacht:

sudo mount /dev/nvme0n1p3 /mnt
sudo mount --rebind /proc /mnt/proc
sudo mount --rebind /sys /mnt/sys
sudo mount --rebind /dev /mnt/dev
sudo chroot /mnt

Damit hatte ich zumindest meine Linux-Installation mal gechrootet. Anschließend habe ich versucht den Grub-Bootloader zu aktualisieren:

sudo update-grub

Das hat irgendwie ziemlich lange gedauert, irgendwann war er dann doch fertig und ich habe das chroot verlassen und den Rechner neu gebootet. Und siehe da – ES HAT SICH NICHTS GEÄNDERT.

Irgendwie bin ich an diesem Punkt schon kurz vorm Verzweifeln gewesen.
Da ich die Linux-Installation auf meinem Notebook nicht wirklich oft nutze, dazu habe ich ja meinen Desktop, wollte ich zumindest erst einmal wieder Windows zum Laufen bekommen. Also den Windows-Installations-Stick eingelegt, in die Problembehandlung gegangen und dann auf der Kommandozeile die folgenden Befehle eingegeben:

bootrec /fixmbr
bootrec /fixboot

Der letzte Befehl hat einfach mal folgendes gebracht:

element nicht gefunden

Nach dem Reboot das gleiche Problem wie vorher. Irgendwie ist mir langsam sehr mulmig im Bauch geworden – die Verzweifelung wurde immer größer.
Also wieder den Windows-Installations-Stick angeschaut und in der Kommandozeile diskpart gestartet.
Der Befehl list partitions zeigte mir dann merkwürdigerweise, dass meine Windows-Partition mit einmal Laufwerk D zugeordnet war, der Daten-Partition auf meiner zweiten Festplatte dann komischerweise C.

Moment….

Also ins Bios gewechselt und die Boot-Reihenfolge der Festplatten geändert. Trotzdem war Grub immer noch der Auffassung: unknown filesystem.
Nach dem erneuten Boot in den Windows-Installations-Stick und Ausführung von diversen Rettungs-Mechanismen, die allesamt mit „Kann nicht ausgeführt werden“ endeten, erreichten meine Wut und Frustration auf Microsoft ungeahne Maße. Als letzten Versuch habe ich dann noch einmal:

bootrec /fixmbr

aufgerufen, der komischerweise mit „access denied“ bzw. „Zugriff verweigert“ endete. Total frustriert schaltete ich den Rechner wieder aus, um möglicherweise noch einmal von Seiten Linux etwas zu machen und wie durch ein Wunder bootete trotz „access denied-Fehler“ bei der MBR-Reparatur das System plötzlich wieder.

Das war echt die schlimmste und nervenaufreibendste Stunde seit langem. Irgendwie scheint das Windows-Update dazu geführt zu haben, dass meine Festplatten getauscht oder aber die NVMe plötzlich kurzzeitig nicht mehr erkannt wurde und dementsprechend die Daten-SSD zur Haupt-Festplatte wurde. Entsprechend konnte dann der Grub (der von der alten Installation wohl noch auf der Daten-SSD war) natürlich kein System mehr erkennen.

Nun läuft es zum Glück wieder. Ich werde wohl mal in Kürze mein Notebook wechseln, irgendwie bereitet das MSI immer mehr Ärger, es hat mir schon eine M2-SSD und eine normale SSD geschrottet, ich befürchte, dass, obwohl die Komponenten relativ neu sind, das Notebook schon wieder dabei ist, die langsam SSD’s zu schrotten.
Nie wieder MSI-Notebooks!!!

Etwas gutes hat aber diese Lektion: Ich habe mich nun endgültig entschlossen, auf meinem Desktop Windows 10 nur in einer VM laufen zu lassen. Dass Windows ein Dual-Boot-System „schrottet“ und man Schwierigkeiten hat, es wieder zu Laufen zu bekommen, ist mir heute nicht das erste mal passiert. Daher ist die VM die bessere Variante.

Virtualbox in Linux mit USB-Zugriff

Hallo,

wie im vorherigen Beitrag bereits geschrieben, bin ich dabei meinen Büro-PC komplett auf Manjaro Linux umzustellen, ohne Dual-Boot ins Windows. Für gelegentliche Windows-Arbeiten werde ich Windows einfach in einer Virtualbox (oder vielleicht auch in KVM???) laufen lassen.

Da ich bisher eigentlich Virtualbox ganz gut fand und ich das mal für verschiedene Tests von Ubuntu und Tails auf meiner Manjaro-Installation bereits am Laufen habe, habe ich erst einmal das genutzt. Ich habe zwei Windows 10 – Installationssticks rumliegen und war eigentlich der Meinung, dass man von denen auch die Installation durchführen kann. Dazu wollte ich aber erst einmal den USB-Zugriff einrichten, was leider nicht sofort funktionierte. Beim Versuch, die USB-Geräte im Gast-System anzeigen zu lassen, war die Liste leider leer.

Für die Installation der vollen USB-Unterstützung (USB3.0), installiert Euch erst einmal das Oracle VM VirtualBox Extension Pack. Das könnt ihr direkt auf der Virtualbox-Seite in den Downloads herunterladen. https://www.virtualbox.org/wiki/Downloads
Nach der Installation steht zwar USB3.0 zur Auswahl zur Verfügung, allerdings ist es essentiell, dass ihr Eurem Nutzer auch die vboxusers-Rolle zuzuweist.

Das macht ihr am besten so:

  
  sudo usermod -a -G vboxusers username

Loggt Euch nach Ausführung des Befehls einmal aus und wieder ein, dann sollte der Zugriff auf den USB-Stick aus Virtualbox möglich sein.

Obwohl ich die Prozedur ausgeführt und auch den USB-Stick einhängen konnte, funktionierte aber die Installation von Windows 10 über diesen Stick nicht. Anscheinend lässt Virtualbox eine Installation über Boot-Sticks nicht zu.
Am Ende erstellte ich mir über das Media Creation Tool von Microsoft eine neue ISO-Datei und band diese als CDRom in Virtualbox ein. Das funktionierte dann glücklicherweise.

Demnächst gehts weiter…

Das Problem mit dem MBR

Hallo,

da die SSD’s gerade ziemlich günstig sind und auf meinem Office-PC sowieso das eine oder andere Mal meine 60GB Linux-Partition bereits mehrfach komplett ausgelastet war, habe ich mir mal eine 1TB SSD zugelegt.
Um nicht alles neu installieren zu müssen, habe ich die alte Platte einfach geklont natürlich unter linux mit dem dd-Befehl – was einfach nur fantastisch funktioniert hat.
Ich hatte vor kurzem den Rechner meines Vaters mit Windows-Software versucht zu klonen, was aber jedesmal bei knapp 90% einfach stehen geblieben ist – nachdem ich dann ein Linux-Live-System gebootet und die Platte einfach mit dd geklont habe, lief das komplett stressfrei.

Aber zurück zu meiner Platte. Nach dem Klonen wollte ich dann einfach noch zwei Partitionen anlegen, eine Partition für Linux zum Erweitern meines Home-Verzeichnisses und eine Windows-Partition für andere Sachen.

Leider musste ich dabei feststellen, dass ich beim Aufsetzen der alten Platte diese im MBR-Format erstellt hatte, das Problem am MBR ist, dass man dort nur maximal 4 Partitionen anlegen kann. Und die waren durch 3 Windows-Partitionen, nämlich die 100MB-Boot-Partition, einer Partition für C und eine für D belegt. Wäre ich damals intelligent gewesen, hätte ich eine erweiterte Partition mit einem logischen Laufwerk für Windows D: und einem logischen Laufwerk für Linux angelegt.
So ging das leider nicht, und das einzige was ich eigentlich machen konnte, war, die Linux-Partition um die 500GB dazugewonnenen Platz zu erweitern. Alles andere hätte zum Datenverlust und zwei Tagen Neuinstallation meines Systems geführt.

Was für ein Dilemma.

Obwohl ich auf dem Rechner größtenteils unter Linux unterwegs bin, brauche trotzdem manchmal die Windows-Partition zum Nachstellen von Fehlern meiner Laserfeed-Software bzw. zum Entwickeln von neuen Windows-C++-Anwendungen.

Was mich zum nächsten Dilemma führt – nämlich, dass auf dem Rechner noch ein Windows 7 (zum Glück Professional) läuft, bei dem in knapp einem Jahr der Support ablaufen wird. Das wäre jetzt nicht unbedingt ein Problem, das jetzt akut wäre, leider ist aber die (100-500MB automatisch angelegte) Boot-Partition für Windows 7 zu klein, so dass nun kein Update mehr richtig funktioniert. Echt blöde Situtation.

Glücklicherweise habe ich es inzwischen geschafft, meine Qt-Programme auch auf einem anderen Rechner als meinem Büro-PC zum Laufen zu bringen, so dass ich eigentlich die Entwicklung komplett auf mein Notebook auslagern oder aber eine Neuinstallation ohne größere Probleme durchführen könnte.

So habe ich überlegt, wie ich aus dem Dilemma herauskomme, ohne jetzt die ganze Platte komplett neu aufsetzen zu müssen.

Dabei sind mir folgende Möglichkeiten gekommen:

  1. Möglichkeit: Alles beim Alten lassen – ohne Windows-Updates, etc. – sicherlich der momentan einfachste Weg, aber speziell im Hinblick auf die Windows-Installation SEHR unsicher
  2. Möglichkeit: die drei Windows-Partitionen komplett platt machen, 2 neue anlegen (Boot und C-Partition).  Die inzwischen große Linux-Partition kann ich ja wieder verkleinern und anschließend den freien Platz für eine erweiterte Partition nutzen. Dort kann ich dann entsprechend die neuen Windows- und Linux-Partitionen anlegen. Hier geht mir zumindest nur das Windows-System flöten, d.h. das müsste ich neu aufsetzen, für ein Wechsel auf Windows 10 müsste ich das sowieso machen.
  3. Es gibt wohl einige Tools, mit denen man von MBR auf GPT umstellen kann, ohne einen vollständigen Datenverlust zu haben. Diese kosten aber Geld. Bisher habe ich gescheut, den Aufwand zu treiben, so eine Software zu kaufen um dann feststellen zu müssen, dass sie nicht korrekt funktioniert. Nein danke.
  4. Möglichkeit: Abschaffen des Dual-Boot-Systems, Löschen der kompletten Windows-Partitionen und Umwandlung der Partitionen in EINE Linux-Partition. Windows wird dann nur noch in einer VM gestartet, wenn ich die denn benötige.

Momentan spiele ich echt mit dem Gedanken, den letzten Schritt zu machen, auch wenn ich in der VM möglicherweise einige Performance-Einbußen hinnehmen muss. Trotzdem erscheint es mir als die beste der Varianten, da ich zu 70-80% der Zeit sowieso im Linux bin. Wenn ich denn mal unbedingt ein (echtes) Windows-System brauche, kann ich ja auch mein Notebook nutzen. Für Office und ein bisschen Qt und ggf. Eclipse sollte auch eine VM ausreichend sein. Außerdem hätte ich so den Vorteil

Ich werde Euch auf dem Laufenden halten, wie das weiter geht und welche Stolpersteine es da gibt.

Böser Fehler – Hostname umstellen

Hallo Leute,

irgendwie nenne ich meine Rechner ja gern nach Mathematikern – bin ich ja mehr oder weniger einer – zumindest habe ich vor etlichen Jahren Wirtschaftsmathematik studiert. Auch wenn ich damit nicht mehr viel am Hut habe und lieber Software erstelle, verleugne ich meine Herkunft nicht.  Aber nun zur eigentlichen Sache.

Bei meinem Notebook ist vor einiger Zeit die SSD kaputt gegangen, merkwürdigerweise konnte man auf die Daten aus einem Linux-System noch zugreifen, wenn auch nur im RAW-Modus, aber zumindest konnte ich so einige Sachen noch retten.

Bei der Neuinstallation meines Notebooks habe ich aber irgendwie verpasst, den Rechner gleich richtig zu benennen. Jetzt, da ich ein paar Dinge neu installiere (z.B. ein neues Office) und meinen privaten Microsoft Live-Account vom Notebook runter werfe und stattdessen einen „geschäftlichen Account“ eingerichtet habe, habe ich auch gleich mal den Hostnamen meines Notebooks umbenannt – eben nach einem Mathematiker.

Auf dem Notebook läuft auch ein Oracle XE, was ich für mein Laserfeed zum Testen und auch für mein neuestes Projekt – die Materialzeugnisverwaltung zum Entwickeln brauche.

Nach dem Neustart nach der Umbenennung, dann der Schreck – meine Materialzeugnisverwaltung konnte sich  nicht mehr mit der Datenbank verbinden – Fehlercode: 12541.

Nach kurzem Googlen, habe ich dann gefunden, dass es etwas mit dem TNSListener zu tun hat. Ein SQLPlus ging komischerweise problemlos. Nachdem ich dann aber mal in die Dienste geschaut habe, musste ich feststellen, dass der TNSListener down war.

Nach dem Start des Listeners ist er immer sofort wieder heruntergefahren. Mist.
Dann kramte ich aber ein wenig Restwissen aus meiner Oracle-Admin-Zeit bei Apoll aus meinem Hirn hervor und hab mir mal die TNSNAMES.ora und die Listener.ora (beide im network\admin-Ordner) angeschaut. Dort stand natürlich noch der alte Hostname drin:

LISTENER.ORA:

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
      (ADDRESS = (PROTOCOL = TCP)(HOST = ALTERHOSTNAME)(PORT = 1521))
    )
  )

TNSNAMES.ORA:

XE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = ALTERHOSTNAME)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XE)
    )
  )

Nach der Änderung des ALTERHOSTNAME in meinen neuen Hostnamen startete auch wieder der Listener und ich konnte mich wieder mit der Datenbank verbinden.
Puh – Glück gehabt.

Also bedenkt das am besten bei der Umbenennung von Hostnamen. Eine Alternative stellt natürlich auch ein Eintrag in der ETC/HOSTS dar, aber ich denke, mit Anpassung der Listener.ora ist das besser.