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]"
Freitag, 29. Juni 2012
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
Escape Charactes in Oracle und DB2
Will man in SQL einen Ähnlichkeitsvergleich durchführen, so kommt meist der "LIKE" Operator zum Einsatz. Hierbei sind "_" und "%" die Sonderzeichen die für genau ein bzw. beliebig viele Zeichen stehen können.
Beispiel:
Das Beispiel sucht in der Tabelle key_val_tab nach allen Zeilen in denen der Wert der Spalte key mit einem beliebigen Zeichen beginnt, gefolgt von "test" auf das beliebig viele Zeichen folgen.
Was aber, wenn man nach _test (beginnt mit: Unterstrich-test) filtern will?
Man muss aus dem Sonderzeichen "_" ein "normales" Zeichen machen.
Hierfür werden allgemein sogenannte Escape Charactes genutzt, die das auf sie folgende Zeichen vom Sonderzeichen zum normalen Textzeichen machen.
Der bekannteste Escape Character ist das "\".
Vesucht man:
ist der Erfolg leider nicht eingetreten.
Warum?
Oracle und DB2 kennen kein Standard/Default Escape Zeichen.
Das ist jedoch keine Schwäche im System sondern ein Zeichen von besonderer Flexibilität.
DB2 und Oracle kennen nämlich sehr wohl Escape Zeichen, nur muss man dem System das jeweilige Zeichen bekannt geben.
Dies geschieht durch Anhängen eines "escape '<hier steht das Escape Zeichen>'".
Man kann also beliebige Escape Characters definieren, abhängig davon wie der zu durchsuchende Textinhalt aufgebaut ist.
In einer Umgebung in der zum Beispiel Windos-Pfade (z.B. c:\windos\temp) abgespeichert werden macht die Nutzung von "\" als Escape Charakter wenig Spass, da er permanent selber auftritt.
Hier würde man auf ein anderes Zeichen (z.B. "#") setzen.
Das obige Beispiel würde korrekt so aussehen:
Ohne es selber getestet zu haben: MS-SQL scheint identisch zu Oracle und DB2 zu arbeiten.
Beispiel:
select * from key_val_tab where key like '_test%';
Das Beispiel sucht in der Tabelle key_val_tab nach allen Zeilen in denen der Wert der Spalte key mit einem beliebigen Zeichen beginnt, gefolgt von "test" auf das beliebig viele Zeichen folgen.
Was aber, wenn man nach _test (beginnt mit: Unterstrich-test) filtern will?
Man muss aus dem Sonderzeichen "_" ein "normales" Zeichen machen.
Hierfür werden allgemein sogenannte Escape Charactes genutzt, die das auf sie folgende Zeichen vom Sonderzeichen zum normalen Textzeichen machen.
Der bekannteste Escape Character ist das "\".
Vesucht man:
select * from key_val_tab where key like '\_test%';
ist der Erfolg leider nicht eingetreten.
Warum?
Oracle und DB2 kennen kein Standard/Default Escape Zeichen.
Das ist jedoch keine Schwäche im System sondern ein Zeichen von besonderer Flexibilität.
DB2 und Oracle kennen nämlich sehr wohl Escape Zeichen, nur muss man dem System das jeweilige Zeichen bekannt geben.
Dies geschieht durch Anhängen eines "escape '<hier steht das Escape Zeichen>'".
Man kann also beliebige Escape Characters definieren, abhängig davon wie der zu durchsuchende Textinhalt aufgebaut ist.
In einer Umgebung in der zum Beispiel Windos-Pfade (z.B. c:\windos\temp) abgespeichert werden macht die Nutzung von "\" als Escape Charakter wenig Spass, da er permanent selber auftritt.
Hier würde man auf ein anderes Zeichen (z.B. "#") setzen.
Das obige Beispiel würde korrekt so aussehen:
select * from key_val_tab where key like '\_test%' escape '\';
Ohne es selber getestet zu haben: MS-SQL scheint identisch zu Oracle und DB2 zu arbeiten.
Montag, 21. November 2011
Windows: Benutzerpasswort entfernen
Will man einem Benutzer das Passwort ganz entfernen so hilft der Befehl
netplwiz
netplwiz
WoW: Pilgerfest - Truthahnator Erfolg
Beim Weltereignis "Pilgerfest" in World of Warcaft (WoW) muss man für den Erfolg "Truthahnator" 40 Wilde Truthähne nacheinander erlegen, ohne dass der Abstand zwischen zwei Truthähnen mehr als 30 Sekunden beträgt.
Für alle verzweifelten Truthahnator-Jäger hier ein kleines Makro das mir das Leben einfacher macht.
/target Wilder Truthahn
/startattack
/cast Eislanze
/script SetRaidTarget("target",8);
Das Makro visiert den nächsten Truhthahn an, startet den Kampf mit ihm (falls man schon davor steht oder sofort ein automatischer Schuss losgeht auch nicht schlecht), schiesst eine Eislanze los (alle die zufällig kein Magier sind tragen hier einen anderen Sofortzauber ein der auf Entfernung geht - und wenn es "werfen" oder "schiessen" ist).
Da man meist ein etwas weiter entferntes Tier nicht gut sieht wird am Schluss noch ein Totenkopf-Symbos drüber gesetzt - den sieht man sogar durch Hügel und Bäume.
Ich hoffe das Makro hilft euch so viel weiter wie mir.
Viele Truthähne findet man in der Regel in möglichst großer Entfernung vom Quest-Knotenpunkt, da dort nur weniger Spieler auftauchen.
Für alle verzweifelten Truthahnator-Jäger hier ein kleines Makro das mir das Leben einfacher macht.
/target Wilder Truthahn
/startattack
/cast Eislanze
/script SetRaidTarget("target",8);
Das Makro visiert den nächsten Truhthahn an, startet den Kampf mit ihm (falls man schon davor steht oder sofort ein automatischer Schuss losgeht auch nicht schlecht), schiesst eine Eislanze los (alle die zufällig kein Magier sind tragen hier einen anderen Sofortzauber ein der auf Entfernung geht - und wenn es "werfen" oder "schiessen" ist).
Da man meist ein etwas weiter entferntes Tier nicht gut sieht wird am Schluss noch ein Totenkopf-Symbos drüber gesetzt - den sieht man sogar durch Hügel und Bäume.
Ich hoffe das Makro hilft euch so viel weiter wie mir.
Viele Truthähne findet man in der Regel in möglichst großer Entfernung vom Quest-Knotenpunkt, da dort nur weniger Spieler auftauchen.
Mittwoch, 16. November 2011
Oracle: Rename Tempfile
Irgendwann muss es leider immer doch mal sein: man muss Datendateien in einer Oracle Datenbank im Dateisystem umziehen.
Kein Problem, hierfür gibt es den allseits bekannten und beliebten Befehl:
Das Ganze funktioniert prima einfach wenn man die DB im Mountstatus hat und vorher alle Dateien an den neuen Zielort kopiert hat (move kommt für einen an Sicherheit denkenden Admin nicht in Frage, also Original stehen lassen und kopieren - aufräumen erst wenns wirklich funktioniert :-) ). Alternativ gehts auch, wenn man einzelne Tablespaces offline nimmt, den Copy und Rename durchführt und den Tablespace wieder online nimmt.
Wenn es nun aber um den Temp-Tablespace geht scheiden sich die Geister.
Man liest oft, dass es nicht so geht wie bei Tablespace Datendateien und dann alternative Lösungen wie etwa zusätzliche Tempfiles, Neuanlage Temp-Tablespace usw.
All diese Lösungen funktionieren und haben ihre Vorteile.
Da ich aber die Datenbank eh im Mount Status habe (auch Undo und System müssen umgezogen werden) interessierte es mich, ob es nicht doch auch beim Temptablespace so ginge - wäre doch praktisch eine Vorgehensweise durchziehen zu können.
Und siehe da: es funktioniert (zumindest ab 10.2 -> Doku).
Spannend ist das nicht - aber praktisch.
Interessant ist nun, dass man das Ziel auch zu kopieren vergessen kann... es taucht von selbst an der neuen Stelle auf.
Hat man zwei Tempfiles im Temptablespace, so kann man diese alternierend Offline nehmen, kopieren, umbenennen und wieder online nehmen.
Auch das hat einwandfrei funktioniert.
Kein Problem, hierfür gibt es den allseits bekannten und beliebten Befehl:
alter database rename file 'von Quelle' to 'Ziel'
Das Ganze funktioniert prima einfach wenn man die DB im Mountstatus hat und vorher alle Dateien an den neuen Zielort kopiert hat (move kommt für einen an Sicherheit denkenden Admin nicht in Frage, also Original stehen lassen und kopieren - aufräumen erst wenns wirklich funktioniert :-) ). Alternativ gehts auch, wenn man einzelne Tablespaces offline nimmt, den Copy und Rename durchführt und den Tablespace wieder online nimmt.
Wenn es nun aber um den Temp-Tablespace geht scheiden sich die Geister.
Man liest oft, dass es nicht so geht wie bei Tablespace Datendateien und dann alternative Lösungen wie etwa zusätzliche Tempfiles, Neuanlage Temp-Tablespace usw.
All diese Lösungen funktionieren und haben ihre Vorteile.
Da ich aber die Datenbank eh im Mount Status habe (auch Undo und System müssen umgezogen werden) interessierte es mich, ob es nicht doch auch beim Temptablespace so ginge - wäre doch praktisch eine Vorgehensweise durchziehen zu können.
Und siehe da: es funktioniert (zumindest ab 10.2 -> Doku).
SQL> startup mount ... SQL> alter database rename file
'/mein/verzeichnis/temp01.dbf' to
'/mein/verzeichnis/unterverzeichnis/temp01.dbf'; database altered SQL> alter database open ...
Spannend ist das nicht - aber praktisch.
Interessant ist nun, dass man das Ziel auch zu kopieren vergessen kann... es taucht von selbst an der neuen Stelle auf.
Hat man zwei Tempfiles im Temptablespace, so kann man diese alternierend Offline nehmen, kopieren, umbenennen und wieder online nehmen.
Auch das hat einwandfrei funktioniert.
Abonnieren
Posts (Atom)