Das ganze können wir folgendermassen lösen. Wir erstellen einen Notification Command Channel, erstellen einen Subscriber und eine Subscription (nur für neue Alerts) und führen dann ein Powershell Script aus, dass den entsprechenden Resolution Code setzt.

Das Script sieht folgendermassen aus:

Param (
	[string]$RMS = "RootManagementServer"
)
# Start the OpsMgr PSSnapin
Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin ;
Set-Location "OperationsManagerMonitoring::" -ErrorVariable errSnapin ;
New-ManagementGroupConnection -ConnectionString:$RMS -ErrorVariable errSnapin ;
set-location $RMS -ErrorVariable errSnapin ;

# Get all new (0) alerts where the MonitoringObjectFullName starts with Microsoft.SQLServer
$alerts = Get-Alert | ?{$_.ResolutionState -eq "0" -and $_.MonitoringObjectFullName -like "Microsoft.SQLServer*"}

foreach($alert in $alerts) {
	#Set the resolution state to DBA Group (15)
	$alert.ResolutionState = "15"
	$alert.Update("")
}

# Remove the OpsMgr PSSnapin
Remove-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client

Wir verbinden uns zuerst mit dem RMS und holen alle Alerts mit Resolutio State von 0 (NEW). Wir können hier auch noch dem MonitoringObjectFullName filtern, der mit Microsoft.SQLServer beginnt (alle Alerts vom SQL Server MP).
Bei diesen Alerts setzen wir den Resolution State dann auf die gewüschte Zahl.

Jetzt müssen wir SCOM noch so konfigurieren, dass dieses Script bei den neuen Alerts ausgeführt wird:

Neuen Notification Channel erstellen: Administration – Notifications – Channels – New Channel Namen und Beschreibung ausfüllen. Unter Settings bei Full Path den Pfad zur Powershell angeben. Bei Command Line Parameters das eigentliche Script aufführen
Dann einen Subscriber erstellen mit dem Channel Type “Command” und useren Channel, den wir vorher erstellt haben.
Nun mit einer Subscription das ganze zusammenfügen. Wir wählen unter Criteria nur die Alerts mit Resolution State 0 aus. Wir wollen ja, dass nur neue Alerts bearbeitet werden.
Als Subscriber und Channel die vorher erstellten auswählen und ohne Alert Aging erstellen

Nun wird bei jedem neuen Alert das Script ausgeführt und falls es ein Alert vom SQL MP ist der entsprechende Resolution State gesetzt. Natürlich können wir im Script auch noch weitere States für andere MPs setzen.

Die DBAs bekommen dann noch eine neue Alert View, bei der nur die Alerts mit dem State 15 angezeigt werden und sind happy, da sie die restlichen Alerts, die sie nicht interessieren nicht sehen.

The Integrated Remote Console is unavailable, it is already in use by a different client.

Kurze Umfrage ergibt aber, dass keiner via iLO auf dem Server ist. Die Session wurde irgendwo vergessen oder hängt. Unter “Remote Console – Settings – Settings” gibts den Punkt “Remote console Acquire”. diesen auf Enabled setzen und Einstellungen mit “Apply” übernehmen.

Nun bekommt man die Auswahl, ob man eine Session übernehmen will, falls eine bereits vorhanden ist.

Danach einfach im Group Policy Manager eine neue GPO erstellen oder eine bestehende bearbeiten. In

User Configration – Policies – Adminstrative Templates – Microsoft Office Excel 2007 – Excel Options – Save – Save Excel Files as

Die Option enablen und “Save Excel File as” “Excel 97-2003 Workbook (*.xls)” setzen

Für Word und Powerpoint den Wert im entsprechenden Administrative Template setzen.

Die GPO dann mit der gewünschten OU verlinken und die Optionen gelten für alle (oder einen Teil) der User.

Nach der Installation muss nur noch ein Konfigurationfile erstellt werden. Ein einfaches Konfigurationsfile sieht folgendermassen aus:

backup
vcip=VCHost
vcuser=vibe
vcpasswd=secret
sauser=vibe
sapasswd=supersecret
dsset=vmware_volume:172.30.129.100
verbose

Hier mache ich ein Backup, vcip ist die IP oder Hostname des Virtual Centers. Danach folgen der Virtual Center User und sein Passwort. sauser ist der Username der für den Login auf dem Netapp Filer verwendet werden. sapasswort sein Passwort. Mittels dsset sage ich VIBE, dass es von allen VMs, die mind. eine Disk auf dem vmware_volume (NetApp Volume) haben einen VMWare Snapshot macht, danach einen NetApp Snapshot des Volumes. Am Schluss werden die VMWare Snapshots wieder entfernt. Wenn wir dies in ein Textfile vibe-backup.cfg speichern können wir mit

vibe --config vibe-backup.cfg

den Backup Prozess starten. Falls das Volume noch gemirrored wird, können wir dies mit:

vibe --config vibe-backup.cfg --updatemir --miruser remoteuser --mirpasswd supersecret

machen. Dann wird nach dem Snapshot der Snapmirror vorgang auch noch mitgestartet.

Zuerst schalten wir NDMP mit ndmpd on ein. Danach können wir mit ndmpd status sehen, dass NDMP auch wirklich läuft:

Nun stellen wir noch ein, dass wir mittels Username und Passwort auf NDMP zugreifen wollen:

Wir müssen sicherstellen, dass NDMP Version 4 verwendet wird:

Falls dies noch nicht der Fall ist können wir dies explizit setzen:

Nun können wir den Filer als NDMP Host hinzufügen. Dazu gehen wir in der BackupExec Konsole auf Tools -> Device and Media Operations -> Add NDMP Server

Im neu erscheinenden Fenster geben wir den Hostname oder IP des NetApp Filers an und den Account mit dem BackupExec sich verbinden soll:

Das war’s auch schon. Nun können wir bei Backups oder Backup Selection Lists den NetApp Filer auswählen und Volumes, Qtrees oder einzelne Files sichern:

Gemäss VMWare Doku muss ich nur Hardware Virtualisierung (in meinem Fall Intel VT) und Execute Protection (eXecute Disable (XD)) aktivieren. Das geht zum Glück via iLO. Nach dem Login auf das Webinterface kann man unter dem Tab “Remote Console” die “Serial Remote Console” starten. Damit kommt man auf den RBSU prompt, bei dem man folgende commands eingeben kann um die Settings zu ändern:

rbsu>

SET CONFIG NO-EXECUTE MEMORY PROTECTION 1

rbsu>

SET CONFIG INTEL(R) VIRTUALIZATION TECHNOLOGY 1

rbsu>

Nach einem EXIT kommt die Meldung, dass ein Neustart (Power Cycle ) notwendig ist. Nach dem Reset kann ich dann im VC auch die EVC Option anwählen.

Und wieder eine Fahrt ins Datacenter gespart.

Bisher gab es mehrere Ansätze.

1. UPPER verwenden
Es wird bei der WHERE Klausel ein UPPER() verwendet. Das wurde früher oft gemacht und funktioniert auch bei (allen) älteren Versionen.

SELECT
*
FROM
SCOTT.EMP
WHERE UPPER(ENAME) = UPPER(&1);

Das Problem hierbei ist aber, dass ein normaler Index nicht verwendet wird. Seit 8i gibt es aber einen sogenannten “function-based index”. Damit diese verwendet werden können muss folgendes erfüllt sein:

• Das System Privileg “query rewrite” auf dem eigenen Schema
• Das System Privileg “global query” auf Tabellen in anderen Schemas
• Damit der Optimizer function based indexes erkennt mü¨ssen folgende Session oder System Variablen gesetzt sein:
  QUERY_REWRITE_ENABLED=TRUE
  QUERY_REWRITE_INTEGRITY=TRUSTED
• Der Cost Based Optimizer muss verwendet werden

Der Index wird dann folgendermassen erstellt:

CREATE INDEX UPPER_ENAME_IX on ENAME ( UPPER(ENAME) ) ;

Dieser Index wird dann aber nur für CASE INSENSITIVE Suchen verwendet, nicht für CASE SENSITIVE. Dazu müssten noch ein Index erstellt werden.

2. REGEXP_LIKE

Seit Version 10g gibt es regular expressions mit denen das Problem auch gelöst werden kanne.

SELECT *

FROM EMP

WHERE REGEXP_LIKE(ename,’James’,'i’);

3. NLS_SORT & NLS_COMP

ALTER SESSION SET NLS_COMP=ANSI;

ALTER SESSION SET NLS_SORT=BINARY_CI;

SELECT ENAME FROM EMP WHERE ENAME = ‘James’;

Diese hat den Vorteil, dass existierende Indices verwendet werden und keine zusätliche Entwicklung notwendig wird.

ABER, …..

Dies funktioniert nicht mit LIKE. Bei LIKE kann ab 10gR2

NLS_COMP=LINGUISTIC;

verwendet werden. Dann klappts auch mit dem LIKE.

Ein neues Projekt ist ein Update meines Honeynets. Zuerst wirds wahrscheinlich ein Update zu honeyd geben.

Updates und neue Artikel sollten jetzt in kürzeren Abständen folgen. Hab ich mir ganz fest vorgenommen

“Monstly Anything”, wie ich auf den Namen kam? Nun zuerst war die Idee ein Blog zum Thema SQL zu erstellen. Das sollte dann Mostly SQL heissen. Aber bereits das erste Posting, dass mir in den Sinn kam bezog sich nicht auf das Thema SQL sondern zu VMWare. Dann kamen noch andere IT Themen auf und “Monstly SQL” wäre dann eher unpassend gewesen. Somit hab ich den ersten Teil des Titels behalten und SQL durch Anything ersetzt. Das soll nun aber nicht ein Freipass sein, um über alles und nichts zu schreiben. Es werden vorallem Artikel zum Thema IT mit den Schwerpunkten VMWare, SQL, Storage und Security sein.

Ich freu mich auf eure Kommentare und mache mich an den ersten richtigen Artikel

Gruss,

Marc