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.

Der erste Event hat die ID 1123:

The node lost communication with cluster node ‘xxx’ on network ‘Teaming’.

Danach der Event mit der ID 1122:

The node (re)established communication with cluster node ‘xxx’ on network ‘Teaming’.

Gemäss Microsoft ist der Heartbeat über ein Teaming Interface nicht supported. Siehe Microsoft KB254101.

Der Kunde hat ein normales Heartbeat Interface und hat auf dem Teaming auch noch internen Traffic ausgewählt. Aus Redundanzgründen. Das ist jetzt abgestellt. Es wird überlegt, ob ein weiteres Heartbeat Interface installiert wird.

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:

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.