International agierende Unternehmen arbeiten sehr oft mit Multibyte Zeichensätzen (Unicode), um unterschiedlichste Zeichensymbole in der Datenbank abbilden zu können. Mit Data Masking bietet Oracle die Möglichkeit, sensible Daten z.B. für Test- und Entwicklungsumgebungen zu anonymisieren. Die Konfiguration von Data Masking geschieht über die graphische Oberfläche von Enterprise Manager Grid Control. Um eine Maskierung oder Anonymisierung von Daten in Multibyte Zeichensätzen erfolgreich und korrekt durchzuführen muss auch die Umgebung von Grid Control entsprechend aufgesetzt sein.

Im Folgenden wird an Hand eines Beispiels beschrieben, wie die Grid Control sowie die Agent-Umgebungen für die Maskierung von Daten mit Data Masking konfiguriert werden müssen.

Wir gehen davon aus, dass der Zeichensatz unserer Zieldatenbank UTF-8 ist. In dieser Datenbank werden in einem CRM-System internationale Kundendaten gespeichert. Der Zeichensatz UTF-8 ist in der Lage alle für unser Beispiel relevanten Zeichensymbole korrekt zu speichern. Ursprünglich war das Grid Control Repository mit dem Zeichensatz WE8MSWIN1252 angelegt, was dazu führte, dass bestimmte Zeichen bei den Bedingungen (Conditions) eingegeben werden konnten, jedoch nicht korrekt im Grid Control Repository gespeichert werden konnten.

Bei der Eingabe wurde beispielsweise ein spezielles Zeichen verwendet, das im folgenden Screenshot zu sehen ist.


Für eine größere Ansicht auf das Bild klicken.

Speicherte man die Masking Definition jedoch ab und bearbeitete diese später weiter, wurde aus dem im Screenshot dargestellten Sonderzeichen ganz einfach ein 'L', und damit veränderte sich der Name zu 'Lazy'. Beim Export der Masking Definition sowie beim Generieren des Masking Skriptes gingen alle Sonderzeichen, die vom Zeichensatz des Grid Control Repositories nicht unterstützt wurden, verloren. In der Konsequenz führte das dazu, dass das Maskieren der Daten nicht wie gewünscht durchgeführt wurde.

Beim erneuten Bearbeiten der Data Masking Definition ging das Sonderzeichen verloren, wie folgender Screenshot zeigt.


Für eine größere Ansicht auf das Bild klicken.

Der Lösungsansatz

Um dieses Problem zu lösen sind folgende Schritte erforderlich:

1. Stoppen des Oracle Management Server (OMS) und Agent Prozesses auf dem OMS-Host:

emctl stop oms
emctl stop agent

2. Definieren der Environment Variablen:

setenv NLS_LANG AMERICAN_AMERICA.UTF8
setenv LANG en_US.UTF-8
setenv LC_ALL en_US.UTF-8

3. Prüfen der Parameter

# Anzeigen von LC_ALL 
locale

# Anzeigen der anderen Parameter 
printenv|grep LANG

4. Ändern des Grid Control Repository Database Character Set mit Hilfe von SQL*Plus

shutdown immediate;
startup mount;
alter system enable restricted session;
alter system set job_queue_processes=0 scope=memory;
alter system set aq_tm_processes=0 scope=memory;
alter database open;
alter system enable restricted session;
alter database character set internal_use internal_convert UTF8;
alter database national character set internal_use internal_convert AL16UTF16;
shutdown immediate;
startup;
set pagesize 1000
col parameter form a21
col value form a21
select substr(parameter,1,20),substr(value,1,20) from nls_database_parameters;
exit;

5. Starten des OMS und des Agent Prozesses

emctl start agent
emctl start oms

1. Stoppen des Agent Prozesses auf dem Host der Zieldatenbank

emctl stop agent

2. Definieren der Environment Variablen

setenv NLS_LANG AMERICAN_AMERICA.UTF8
setenv LANG en_US.UTF-8
setenv LC_ALL en_US.UTF-8

3. Prüfen der Parameter

# Anzeigen von LC_ALL
locale

# Anzeigen der anderen Parameter
printenv|grep LANG

4. Starten des Agent Prozesses auf dem Host der Zieldatenbank

emctl start agent

ps -ef| grep agent
#Notieren Sie die agent_process_id
ps -aexwww | grep agent-process_id

ps -ef| grep server
#Notieren Sie die server_process_id
ps -aexwww | grep server_process_id

Zurück zum Anfang des Artikels

Zurück zur Community-Seite