Die Fritz Box kann auch zum Mitschnitt von Netzwerk-Datenverkehr verwendet werden.
Hierzu muss man auf die spezielle URL http://fritz.box//html/capture.html gehen und sich anmelden.
Dort kann man einen Netzwerk-Trace im Wireshark Format erzeugen lassen.
Sammlung (für mich) interessanter Informationen. Voraussichtlich sehr Oracle-lastig, mit Einschlägen aus der Fantasy und Rollenspielrichtung und Fotografie und Bildbearbeitung und ...
Sonntag, 28. Oktober 2012
Windows Patch KB 2656351 und KB 2600217 werden immer wieder zur Installation aufgeführt
Windows meldet die Patches KB 2656351 und KB 2600217 permanent als wichtig und noch zu installierend.
Es handelt sich um Patches für das .Net-Framework.
Das Framework selbst scheint noch einwandfrei zu funktioneren, aber scheinbar sind irgendwelche Rahmenbedingungen für den Patch nicht mehr so, dass er sauber installert und dies auch entsprechend einträgt.
Ein Eintrag bei Microsoft bringt einen auf die richtige Lösung:
Das Microsoft Dot-Net-Cleanup-Tool herunterladen (dotnetfx_cleanup_tool.zip) und entpacken
Mit dem Cleanup-Tool die Dot-Net Frameworks löschen lassen
Windows Update aufrufen und die dort vorgeschlagenen Komponenten nachinstallieren lassen
Mir hat es geholfen.
Interessant ist auch ein Hintergrundartikel bei Tecchannel über das Cleanup-Tool.
Es handelt sich um Patches für das .Net-Framework.
Das Framework selbst scheint noch einwandfrei zu funktioneren, aber scheinbar sind irgendwelche Rahmenbedingungen für den Patch nicht mehr so, dass er sauber installert und dies auch entsprechend einträgt.
Ein Eintrag bei Microsoft bringt einen auf die richtige Lösung:
Das Microsoft Dot-Net-Cleanup-Tool herunterladen (dotnetfx_cleanup_tool.zip) und entpacken
Mit dem Cleanup-Tool die Dot-Net Frameworks löschen lassen
Windows Update aufrufen und die dort vorgeschlagenen Komponenten nachinstallieren lassen
Mir hat es geholfen.
Interessant ist auch ein Hintergrundartikel bei Tecchannel über das Cleanup-Tool.
Freitag, 12. Oktober 2012
Windows zeigt nur noch Kästchen statt Buchstaben
Extremabkürzung: Font-Cache löschen ist meine Lösung
Windows Patchday.
In den allermeisten Fällen geht das problemlos von Statten.
Patches einspielen, eventueller Reboot.
Sache erledigt.
Bisher hatte ich auch meist Glück.
Doch diese Woche hat es mich und meine Frau erwischt.
Mittwochs daheim privat gepatcht.
Donnerstags die Rechner angeschaltet.
Windows startet einwandfrei.
Windows funktioniert prima.
Nur leider haben sämtliche Microsoft Programme (Windows selbst und Office) nun ein Problem mit der Darstellung von Schriften in Menüs und technischen Dialogen.
Auch das Suchfeld im Startmenü, die Beschriftung in der Systemsteuerung, usw. gehören dazu.
Auf gut Deutsch: mit dem System ist nicht mehr richtig zu arbeiten.
Also nichts wie los mit der Analyse:
Betroffen sind zwei identische Rechner mit identischer Installation und Konfiguration.
Es scheint also ein nachvollziehbares Problem zu sein und kein dummer einmaliger Zufall.
Betroffen scheint genau eine Schriftart zu sein, die Windows 7 besonders gerne verwendet.
Die Google-Suche ergibt Segoe als Namen der aktuellen Windows 7 Systemschriftart.
Einige kreative Suchen weiter weiss ich, dass am 09.10.2012 ein Windows Update (KB2729094) mit einem Update genau dieser Schrift verteilt wurde.
Eine Deinstallation des Updates über den Punkt "Installierte Updates" (aufpassen, die Updates sind in Kategorien unterteil, die getrennt voneinander sortiert werden) bringt leider auch keinen Erfolg.
Windows will penetrant dieses wichtige Update wieder einspielen - also wieder rauf damit.
Zurücksetzen der Schriftarteneinstellungen auf Standard bringt auch nichts - immer noch Kästchen als Buchstaben an vielen Stellen im System.
Googeln nach dem Problem führt irgendwie nicht auf die richtige Spur.
Es gibt zwar viele spannende Fragen, wenige gute Anworten, aber die bringen alle nichts.
Bringt aber nichts, da werden wohl wirklich nur für den Systemstart relevante Dateien bereinigt.
Man solle prüfen ob die Tastatur auf Japanisch eingestellt ist ...
Lustige Idee, aber hilft nicht.
Helfen würde wahrscheinlich eine Umstellung der Benutzen Schriftart in allen Dialogen des Systems auf eine andere Schrift als Segoe, aber das will ich nicht - die Schrift finde ich an sich doch sehr angenehm.
Jedenfalls sehe ich, dass alle Segoe Schriftschnitte vom Problem betroffen sind.
Nun komme ich ins Grübeln und rekapituliere:
Das Font-Rendering-System funktioniert bei allen anderen Schriften.
Was passiert eigentlich beim Font-Rendering?
Soviel ich weiss, wird die Schrift bei Bedarf gerendert in der jeweils notwendigen Schriftgröße.
Da dieser Vorgang relativ aufwendig ist wird der Fertige Buchstabe (Glyphe) im Font-Cache
zwischengespeichert für weiter Verwendung.
Bei Bedarf nach einem der vorgerenderten Zeichen wird sich aus dem Font-Cache bedient.
AHAAAAAAA!
FONT-CACHE!
Der Nebel lichtet sich.
Was passiert wenn beim Schriften-Update vergessen wird den Font-Cache zu löschen/aktualisieren?
Hmmmm... vielleicht undefinierte Zeichen, die dann als Kästchen ausgegeben werden?
Also lösche ich den Font-Cache indem ich die Datei
Diese enthält den Font-Cache.
Bei jedem Neustart wird sie - wenn nicht schon vorhanden - frisch angelegt und bei Bedarf befüllt.
Und das ist dann auch die Lösung des Problems - man muss den Font Cache löschen, damit er neu mit korrekten Glyphen gefüllt wird.
Vollkommen triviale Ursache, vollkommen triviale Lösung - nur finden muss man sie.
Vielleicht kann ich mit diesem Eintrag jemandem weiterhelfen damit er nicht so lange suchen muss wie ich.
Windows Patchday.
In den allermeisten Fällen geht das problemlos von Statten.
Patches einspielen, eventueller Reboot.
Sache erledigt.
Bisher hatte ich auch meist Glück.
Doch diese Woche hat es mich und meine Frau erwischt.
Mittwochs daheim privat gepatcht.
Donnerstags die Rechner angeschaltet.
Windows startet einwandfrei.
Windows funktioniert prima.
Nur leider haben sämtliche Microsoft Programme (Windows selbst und Office) nun ein Problem mit der Darstellung von Schriften in Menüs und technischen Dialogen.
Auch das Suchfeld im Startmenü, die Beschriftung in der Systemsteuerung, usw. gehören dazu.
Auf gut Deutsch: mit dem System ist nicht mehr richtig zu arbeiten.
Also nichts wie los mit der Analyse:
Betroffen sind zwei identische Rechner mit identischer Installation und Konfiguration.
Es scheint also ein nachvollziehbares Problem zu sein und kein dummer einmaliger Zufall.
Betroffen scheint genau eine Schriftart zu sein, die Windows 7 besonders gerne verwendet.
Die Google-Suche ergibt Segoe als Namen der aktuellen Windows 7 Systemschriftart.
Einige kreative Suchen weiter weiss ich, dass am 09.10.2012 ein Windows Update (KB2729094) mit einem Update genau dieser Schrift verteilt wurde.
Eine Deinstallation des Updates über den Punkt "Installierte Updates" (aufpassen, die Updates sind in Kategorien unterteil, die getrennt voneinander sortiert werden) bringt leider auch keinen Erfolg.
Windows will penetrant dieses wichtige Update wieder einspielen - also wieder rauf damit.
Zurücksetzen der Schriftarteneinstellungen auf Standard bringt auch nichts - immer noch Kästchen als Buchstaben an vielen Stellen im System.
Googeln nach dem Problem führt irgendwie nicht auf die richtige Spur.
Es gibt zwar viele spannende Fragen, wenige gute Anworten, aber die bringen alle nichts.
Eine Systemreparatur mit
sfc /scannow
wird empfohlen.Bringt aber nichts, da werden wohl wirklich nur für den Systemstart relevante Dateien bereinigt.
Man solle prüfen ob die Tastatur auf Japanisch eingestellt ist ...
Lustige Idee, aber hilft nicht.
Helfen würde wahrscheinlich eine Umstellung der Benutzen Schriftart in allen Dialogen des Systems auf eine andere Schrift als Segoe, aber das will ich nicht - die Schrift finde ich an sich doch sehr angenehm.
Jedenfalls sehe ich, dass alle Segoe Schriftschnitte vom Problem betroffen sind.
Nun komme ich ins Grübeln und rekapituliere:
- Ein Schriftenupdate wurde installiert
- Die betroffene Schhrift wird nicht mehr angezeigt an vielen Stellen, an manchen (da wo es größer und/oder farbig ist) doch
- mit anderen Schriften würde es funktionieren
- Deinstallation und Reinstallation des Schriftenupdates helfen nicht
Das Font-Rendering-System funktioniert bei allen anderen Schriften.
Was passiert eigentlich beim Font-Rendering?
Soviel ich weiss, wird die Schrift bei Bedarf gerendert in der jeweils notwendigen Schriftgröße.
Da dieser Vorgang relativ aufwendig ist wird der Fertige Buchstabe (Glyphe) im Font-Cache
zwischengespeichert für weiter Verwendung.
Bei Bedarf nach einem der vorgerenderten Zeichen wird sich aus dem Font-Cache bedient.
AHAAAAAAA!
FONT-CACHE!
Der Nebel lichtet sich.
Was passiert wenn beim Schriften-Update vergessen wird den Font-Cache zu löschen/aktualisieren?
Hmmmm... vielleicht undefinierte Zeichen, die dann als Kästchen ausgegeben werden?
Also lösche ich den Font-Cache indem ich die Datei
c:\Windows\System32\FNTCACHE.DAT
umbenenne (bezieht sich auch Windows 7).Diese enthält den Font-Cache.
Bei jedem Neustart wird sie - wenn nicht schon vorhanden - frisch angelegt und bei Bedarf befüllt.
Und das ist dann auch die Lösung des Problems - man muss den Font Cache löschen, damit er neu mit korrekten Glyphen gefüllt wird.
Vollkommen triviale Ursache, vollkommen triviale Lösung - nur finden muss man sie.
Vielleicht kann ich mit diesem Eintrag jemandem weiterhelfen damit er nicht so lange suchen muss wie ich.
Dienstag, 21. August 2012
Solaris TCP-Einstellungen auslesen
Ab und zu interessiert es auch den DB-Admin, wie die TCP Parameter für "sein" Betriebssystem gesetzt sind.
In Solaris geht das über den Befehl "ndd".
Mit /usr/sbin/ndd -get kann man die Einstellungen auslesen, mit /usr/sbin/ndd -set kann man sie neu setzen - wenn man dazu berechtigt ist.
Eine Liste aller Parameter liefert:
Will man den TCP_IP_ABORT_INTERVAL-Parameter abfragen, so nutzt man:
/usr/sbin/ndd -get /dev/tcp tcp_ip_abort_interval
In Solaris geht das über den Befehl "ndd".
Mit /usr/sbin/ndd -get kann man die Einstellungen auslesen, mit /usr/sbin/ndd -set kann man sie neu setzen - wenn man dazu berechtigt ist.
Eine Liste aller Parameter liefert:
/usr/sbin/ndd -get /dev/tcp ?
Will man den TCP_IP_ABORT_INTERVAL-Parameter abfragen, so nutzt man:
/usr/sbin/ndd -get /dev/tcp tcp_ip_abort_interval
Freitag, 29. Juni 2012
Oracle RAC: Interface nach Hardwareänderung im CRS ändern
Die Oracle Clusterware (CRS) speichert nicht nur die für die Kommunikation genutzten IP-Adressen, sondern auch die dazu gehörenden Netzwerk Interfaces.
Ändert nun eines dieser Interfaces seinen Namen (zum Beispiel wegen Hardwaretausch), so ist es notwendig der Clusterware die Veränderung mitzuteilen.
Dies geschieht mit dem Befehl $ORA_CRS_HOME/bin/oifcfg.
Da keine direkte Änderung unterstützt wird muss man das bisher genutzte Interface löschen und dann das neue frisch anlegen.
Das offizielle Vorgehen ist in der Oracle Support Note 283684.1 beschrieben: "How to Modify Public or Private Network Information in Oracle Clusterware [ID 283684.1]"
Dies geschieht mit dem Befehl $ORA_CRS_HOME/bin/oifcfg.
Da keine direkte Änderung unterstützt wird muss man das bisher genutzte Interface löschen und dann das neue frisch anlegen.
Das offizielle Vorgehen ist in der Oracle Support Note 283684.1 beschrieben: "How to Modify Public or Private Network Information in Oracle Clusterware [ID 283684.1]"
Donnerstag, 28. Juni 2012
RAC VIP Failover und Failback aktivieren
Seit der Oracle RAC Version 10.2.0.4 wird im Fehlerfall die VIP eines "kranken" Knotens auf den gesunden Partner verlagert, aber per Default nicht wieder automatisch zurück verlagert.
Will man erreichen, dass die VIP automatisch wieder zurück wechselt, wenn der Original-Knoten wieder verfügbar ist, so muss man in der $ORACLE_HOME/bin/racgwrap eine Zeile durch entfernen des Kommentarzeichen aktivieren.
Beispiel Solaris, Oracle 10.2.0.5
Zeile 50 ist im Default auskommentiert und erlaubt im aktivem Zustand den VIP Failback.
Das Ganze ist mit Vorsicht zu genießen, da beim zyklischen Prüfen (alle 10 Minuten) ob die VIP zurück verlagert werden kann diese inaktiv gesetzt werden muss, was zu Timeout-Situationen bei Verbindungsversuchen führen kann.
Das ganze ist auch im Oracle Support System im Artikel
10g/11gR1: VIP does not relocate back to the home node even after the public network problem is resolved [ID 805969.1] beschrieben.
Will man erreichen, dass die VIP automatisch wieder zurück wechselt, wenn der Original-Knoten wieder verfügbar ist, so muss man in der $ORACLE_HOME/bin/racgwrap eine Zeile durch entfernen des Kommentarzeichen aktivieren.
Beispiel Solaris, Oracle 10.2.0.5
45 # Set ORA_RACG_VIP_FAILBACK to enable VIP failback on INST check action
46 # It only affects INST resource running from the same ORACLE_HOME as racgwrap
47 #
48 # uncomment out ORA_RACG_VIP_FAILBACK to enable VIP failback
49 #
50 ORA_RACG_VIP_FAILBACK=1 && export ORA_RACG_VIP_FAILBACK
Zeile 50 ist im Default auskommentiert und erlaubt im aktivem Zustand den VIP Failback.
Das Ganze ist mit Vorsicht zu genießen, da beim zyklischen Prüfen (alle 10 Minuten) ob die VIP zurück verlagert werden kann diese inaktiv gesetzt werden muss, was zu Timeout-Situationen bei Verbindungsversuchen führen kann.
Das ganze ist auch im Oracle Support System im Artikel
10g/11gR1: VIP does not relocate back to the home node even after the public network problem is resolved [ID 805969.1] beschrieben.
Freitag, 13. April 2012
WoW Mists of Pandaria: Probleme mit dem Beta-Launcher
Die WoW Beta zu Mists of Pandaria wird aktuell weit gestreut verteilt.
Beim Download kommt es immer wieder zu zwei Problemen für die ich eine Lösung gefunden habe.
Beid Probleme konnte ich mit zwei Schritten bereinigen:
Beim Download kommt es immer wieder zu zwei Problemen für die ich eine Lösung gefunden habe.
- "Updating Setup Files" hängt für immer
- Launcher startet, hängt aber bei der Überprüfung für immer
Beid Probleme konnte ich mit zwei Schritten bereinigen:
- Launcher/Downloader beenden (sonst sind Verzeichnisse gesperrt)
- das Verzeichnis Battle.net unter c:\ApplicationData löschen
- den Prozess Agent.exe (sollte er noch laufen) beenden
Abonnieren
Posts (Atom)