Donnerstag, 19. Juli 2012

Filter Preferences - Grundsätzliches

Wir haben in unseren Textblogs schon mehrfach über einige Texteinstellungen - die sogenannten Preferences - gesprochen.  Nun ist es an der Zeit, Grundlagen zu den Filter Preferencen zu legen. Filter Preferences sind, wie der Name schon verrät, dazu da den Text zum Indizieren zu filtern. Formatierte Dokumente werden zwar in nativer Format gespeichert; der Filter sorgt allerdings dafür, dass eine vorläufige Version in reinem (plain) Text oder HTML Version des Dokuments zur Verfügung steht, um dann die Wörter zum Indizieren zu erhalten.

Filter-Preferences werden mit dem CREATE INDEX oder ALTER INDEX Statement erzeugt. Man sollte sich dabei nicht auf System Preferencen verlassen, sondern den Filter immer beim Anlegen des Index mitangeben. Folgende Filter Typen existieren:

  • CHARSET_FILTER: Character Set Konvertierung
  • AUTO_FILTER: Für formatierte Dokumente
  • NULL_FILTER: Kein Filter ist erforderlich, nützlich für Plain Text, HTML und XML
  • MAIL_FILTER: Transformiert RFC-822 und RFC-2045 Nachrichten in indizierbaren Text
  • USER_FILTER: Externer Filter für benutzerdefinertes Filtern
  • PROCEDURE_FILTER: Benutzerdefiniertes Filtern definiert über eine Prozedur

Hier im Blog gebe ich Beispiele für NULL_FILTER, AUTO_FILTER und den USER_FILTER. Weitere Beispiele dazu finden sich im Handbuch.
Zuerst wird eine Tabelle erzeugt, die Dokumente im Format Powerpoint, PDF, HTML und ASCII enthält.

drop table filter_test; 
create table filter_test(id number primary key, docs blob);

Zum Laden verwende ich den SQL *Loader. Die CTL Datei sieht folgendermassen aus:
LOAD DATA
INFILE 'filter_load.dat'
INTO TABLE null_filter
FIELDS TERMINATED BY ','
(id SEQUENCE (MAX,1) ,
ext_fname FILLER CHAR(50),
docs LOBFILE(ext_fname) TERMINATED BY EOF)

Die filter_load.dat Datei hat folgende Inhalte.
snaps.sql
powerp.pptx
plain.txt
replay.html
one_page.pdf

Im ersten Beispiel wird ein Index mit Filter Preference NULL_FILTER erzeugt. Um zu überprüfen, ob im Index Create Prozeß keine Fehler passiert sind, schalte ich Logging ein und überprüfe den Index nach dem Anlegen mit CTX_USER_INDEX_ERRORS.
drop index filter_test_idx force;
execute CTXSYS.CTX_ADM.SET_PARAMETER ('LOG_DIRECTORY','/tmp'); 
exec CTX_OUTPUT.START_QUERY_LOG('filterlog');

create index filter_test_idx on filter_test ( docs )
indextype is ctxsys.context
parameters ('FILTER ctxsys.NULL_FILTER');

execute CTX_OUTPUT.END_QUERY_LOG;
SQL> select * from ctx_user_index_errors;
no rows selected

Nun wird das Ergebnis überprüft. Um einen Einruck von dem Inhalt der Ergebnismenge zu bekommen, verwende ich CTX_DOC.SNIPPED. Die REGEXP_REPLACE Funktion macht das Ergebnis lesbarer und eliminiert die überflüssigen Leerzeilen.

SQL> execute ctx_doc.set_key_type('ROWID');
SQL> select id, regexp_replace(ctx_doc.snippet 
('FILTER_TEST_IDX', rowid, 'plain or OLTP or replay or snapshot or SPA or
 REPLAY',starttag=>'###',endtag =>'###'),'\s+',' ') snippet
 from filter_test
 where contains ( docs, 'plain or OLTP or replay or snapshot or SPA or REPLAY') > 0; 
ID
----------
SNIPPET
--------------------------------------------------------------------------------
1
hh24:mi') from dba_hist_###snapshot### order by BEGIN_INTERVAL_TIME
3
dies ist ein ###plain### text
4
performance of a workload ###replay### against the performance of...The f
irst ###replay### would try to mimic the captured

Wie zu erwarten, enthält das Ergebnis die Dokumente snaps.sql (mit 1), plain.txt (mit 2) und replay.html (mit 3).
Nun verwenden wir den AUTO_FILTER. Das Vorgehen ist ähnlich wie oben, nur die FILTER Preference lautet nun AUTO_FILTER.
drop index filter_test_idx force; 
execute CTXSYS.CTX_ADM.SET_PARAMETER ('LOG_DIRECTORY','/tmp'); 
execute CTX_OUTPUT.START_QUERY_LOG('filterlog');

create index filter_test_idx on filter_test (docs)
indextype is ctxsys.context
parameters ('FILTER ctxsys.AUTO_FILTER');

execute CTX_OUTPUT.END_QUERY_LOG;
SQL> select * from ctx_user_index_errors;
no rows selected
Nun wird wieder das Ergebnis selektiert.
SQL> execute ctx_doc.set_key_type('ROWID');

SQL>select id, regexp_replace(ctx_doc.snippet
('FILTER_TEST_IDX', rowid, 'plain or OLTP or replay or snapshot or SPA or
 REPLAY',starttag=>'###',endtag =>'###'),'\s+',' ') snippet
 from filter_test
 where contains ( docs, 'plain or OLTP or replay or snapshot or SPA or REPLAY') > 0; 
ID
----------
SNIPPET
--------------------------------------------------------------------------------
1
hh24:mi') from dba_hist_###snapshot### order by BEGIN_INTERVAL_TIME
2
Sesssions und Calls ###OLTP###-Datenbanken mit ca.12.000...Siehe Enhancem
ent Request ?7523016: ###REPLAY### REPORTS ORA-933 ON SET ROLE
3
dies ist ein ###plain### text
4
performance of a workload ###replay### against the performance of...The f
irst ###replay### would try to mimic the captured
5
2) Before using the ###SPA### or Database Replay, understand...3) Perform
STS Capture for ###SPA### & workload capture for Database

Es werden nun alle Dokumente gefiltert, indiziert und gefunden. Möchte man einen Überblick über alle unterstützten Formate erhalten, kann man dies im Handbuch nachschlagen.

Nun kommen wir zum letzten Beispiel - einem USER_FILTER. Hierzu ist ein Programm notwendig, das beim Filtern für jede Zeile ausgeführt wird. Explizit wird nun eine Preference MY_FILTER mit einem speziellen Attribut erzeugt, das den Programmnamen festlegt - hier upper.pl
execute ctx_ddl.drop_preference('my_filter');
BEGIN
ctx_ddl.create_preference ('my_filter', 'user_filter');
ctx_ddl.set_attribute ('my_filter', 'command', 'upper.pl');
END;
/
PL/SQL procedure successfully completed.
Das Programm ist ein Perl-Programm, das den Text in Großbuchstaben konvertiert. Es muß unbedingt im Verzeichnis $ORACLE_HOME/ctx/bin zu finden sein.

#!/usr/bin/perl
open(IN, $ARGV[0]);
open(OUT, ">".$ARGV[1]);
while ()
{
tr/a-z/A-Z/;
print OUT;
}
close (IN);
close (OUT);

Nun wird der Index erzeugt.

drop index filter_test_idx force;

create index filter_test_idx on filter_test (docs) 
indextype is ctxsys.context
parameters ('filter my_filter');

SQL> select * from ctx_user_index_errors;
no rows selected

Das Ergebnis sieht dann folgendermassen aus.

SQL> select id, regexp_replace(ctx_doc.snippet
('FILTER_TEST_IDX', rowid, 'plain or OLTP or replay or snapshot or SPA or
REPLAY',starttag=>'###',endtag =>'###'),'\s+',' ') snippet
from filter_test
where contains ( docs, 'plain or OLTP or replay or snapshot or SPA or REPLAY') > 0;
ID
----------
SNIPPET
--------------------------------------------------------------------------------
4
CAPTURE VS. ###REPLAY###
...PERFORMANCE OF A WORKLOAD ###REPLAY### AGAINST THE PERFORMANCE
OF...CAPTURED SYSTEM, WHILE "###REPLAY###" REFERS TO THE
REPLAYED WORKLOAD.

Mittwoch, 6. Juni 2012

Name Matching (NDATA) mit einem Thesaurus "erweitern"

Zum Thema Oracle TEXT Name Matching hatten wir ja bereits einige Blog Postings. Heute möchte ich das Thema nochmal aufgreifen und besonders die Erweiterbarkeit mit einem Thesaurus vorstellen. Zunächst zur Ausgangssituation: Wir legen eine Tabelle an und füllen diese mit ein paar Namen:
create table tab_namen (
  id           number(10),
  vorname      varchar2(100),
  nachname     varchar2(100)
)
/

insert into tab_namen values (1, 'Carsten','Czarski');
insert into tab_namen values (2, 'Ulrike', 'Schwinn');
insert into tab_namen values (3, 'Max',    'Meier');
insert into tab_namen values (4, 'Moritz', 'Meyer');
insert into tab_namen values (5, 'Franz',  'Mayer');
insert into tab_namen values (6, 'Fritz',  'Maier');
Damit man einen Oracle TEXT Index anlegen kann, der auch alle Namen enthält, muss man nun mit einem Multicolumn-Datastore oder einem User-Datastore arbeiten. Da ich die Namen aber gerne per NDATA (Name Matching) und per "klassischer" Fuzzy-Suche (FUZZY-Operator) finden möchte, brauche ich einen User-Datastore (Blog-Posting). Also zuerst die PL/SQL-Prozedur anlegen ...
 create or replace procedure namen_uds_proc(
  rid  in            rowid,
  tlob in out nocopy varchar2
) is
  l_vorname  tab_namen.vorname%type;
  l_nachname tab_namen.nachname%type;
begin
  select vorname, nachname into l_vorname, l_nachname
  from tab_namen where rowid = rid;
  tlob := 
    '<VORNAME>'   || l_vorname                       || '</VORNAME>'  ||  
    '<NACHNAME>'  || l_nachname                      || '</NACHNAME>' ||  
    '<NAME>'      || l_vorname || ' ' || l_nachname  || '</NAME>';
end;
/
sho err
Die Prozedur als User Datastore registrieren ...

begin
  ctx_ddl.create_preference('names_ds', 'user_datastore');
  ctx_ddl.set_attribute('names_ds', 'procedure', 'namen_uds_proc');
end;
/
sho err
Mit dem Section Group-Objekt wird festgelegt, wie die einzelnen Sections (XML-Tags) von Oracle TEXT behandelt werden sollen ... VORNAME und NACHNAME werden normal behandelt; der zusammengesetzte "NAME" wird als NDATA-Section deklariert.
begin
  ctx_ddl.create_section_group('names_sg', 'xml_section_group');
  ctx_ddl.add_field_section('names_sg', 'VORNAME', 'VORNAME', false);
  ctx_ddl.add_field_section('names_sg', 'NACHNAME', 'NACHNAME', false);
  ctx_ddl.add_ndata_section('names_sg', 'NAME', 'NAME');
end;
/
Schließlich den Index anlegen ...
create index ft_names on tab_namen (nachname)
indextype is ctxsys.context
parameters('
  datastore     names_ds
  section group names_sg
  memory        100m
')
/
Und dann kann man abfragen - zuerst mit "Meier" ...
select * from tab_namen where contains(nachname, 'ndata(name, Meier)')>0
/

        ID VORNAME         NACHNAME
---------- --------------- ---------------
         3 Max             Meier
         4 Moritz          Meyer
         6 Fritz           Maier
Ups ... da fehlt doch einer ... der "Mayer" ist für den NDATA-Algorithmus wohl "zu weit" weg ... Probieren wir noch ein wenig mit dem "Czarski".
select * from tab_namen where contains(nachname, 'ndata(name, Czarsky)')>0
/

        ID VORNAME         NACHNAME
---------- --------------- -------------
         1 Carsten         Czarski

select * from tab_namen where contains(nachname, 'ndata(name, Tsarski)')>0
/

        ID VORNAME         NACHNAME
---------- --------------- -------------
         1 Carsten         Czarski

select * from tab_namen where contains(nachname, 'ndata(name, Tsarsky)')>0
/

Es wurden keine Zeilen ausgewählt
Funktioniert ganz gut, lässt aber doch noch Wünsche offen. Eine Ähnlichkeitssuche wird aber immer Wünsche offenlassen, gerade wenn sie nicht für eine bestimmte Sprache optimiert ist und global funktionieren soll. Die gute Nachricht ist aber, dass NDATA durch einen Thesaurus erweitert werden kann. In diesem Thesaurus können unterschiedliche Schreibweisen von Namen als Synonymbeziehungen hinterlegt und die Treffermenge von NDATA so erweitert werden. Und das Gute ist, dass NDATA dann auch zu den Synonymen ähnliche (!) Namen finden wird. Die Treffermenge wird also nicht nur um die Synonyme selbst, sondern auch um den Synonymen (nach NDATA) ähnliche Namen erweitert.
Wie man einen Thesaurus anlegt und pflegt, ist in diesem Blog-Posting beschrieben. Also erzeugen wir einen Thesaurus wie folgt ...
begin
  ctx_thes.create_thesaurus('namesthes');
  ctx_thes.create_relation('namesthes', 'meyer', 'SYN', 'maier');
  ctx_thes.create_relation('namesthes', 'meyer', 'SYN', 'meier');
  ctx_thes.create_relation('namesthes', 'meyer', 'SYN', 'mayer');
  ctx_thes.create_relation('namesthes', 'czarski', 'SYN', 'czarsky');
end;
/
Als nächstes müssen wir Oracle TEXT sagen, dass es den Thesaurus für NDATA nutzen soll - das geschieht mit einer Wordlist Preference.
begin
  ctx_ddl.create_preference('names_wl', 'BASIC_WORDLIST');
  ctx_ddl.set_attribute('names_wl', 'NDATA_ALTERNATE_SPELLING', 'FALSE');
  ctx_ddl.set_attribute('names_wl', 'NDATA_BASE_LETTER',        'TRUE');
  ctx_ddl.set_attribute('names_wl', 'NDATA_THESAURUS',          'namesthes');
end;
/
Und dann muss der Index gelöscht und neu angelegt werden ...
drop index ft_names
/

create index ft_names on tab_namen (nachname)
indextype is ctxsys.context
parameters('
  datastore     names_ds
  section group names_sg
  wordlist      names_wl
  memory        100m
')
/
Und dann probieren wir die Abfragen erneut ...
select * from tab_namen where contains(nachname, 'ndata(name, Mayer)')>0
/

        ID VORNAME         NACHNAME
---------- --------------- ---------------
         3 Max             Meier
         4 Moritz          Meyer
         5 Franz           Mayer
         6 Fritz           Maier

select * from tab_namen where contains(nachname, 'ndata(name, Tsarsky)')>0
/

        ID VORNAME         NACHNAME
---------- --------------- ---------------
         1 Carsten         Czarski
Voilá - man sieht, dass man die NDATA-Funktionalität sehr gut erweitern kann. Wenn man das von vorneherein in seinen Index einbaut, so kann man den Index aufgrund von Nutzerfeedback "lernen" lassen. Mit einem Namens-Thesaurus lässt sich die NDATA-Funktinalität auf jeden Fall sehr gut abrunden.

Freitag, 25. Mai 2012

Oracle TEXT Workshop im Mai in Düsseldorf und Stuttgart

Im Mai 2012 führten wir in Düsseldorf und Stuttgart einen Workshop zum Thema Oracle TEXT durch. Dort wurde Oracle TEXT und die Möglichkeiten im Detail vorgestellt.

Die Agenda
10:00 Beginn der Veranstaltung
Oracle TEXT: Ein Überblick
Konzepte und generelle Funktionsweise von Oracle TEXT, Einsatzszenarien
Umgang mit Oracle TEXT: Tipps & Tricks aus der Praxis
Einblick in die Wartung eines Textindex, wie formuliert man Oracle TEXT Abfragen richtig?
Welche grundsätzlichen Möglichkeiten habe ich?
Mittagspause
Überwachung und Wartung eines Oracle Text Index im Detail
Synchronisierungs- und Optimierungsintervalle, Strategien, Feststellung der Fragmentierung,
Hochverfügbarkeit mit Schattenindex-Technologie und mehr ...
"Textindex nach Art des Hauses": Konfiguration eines TEXT-Index
Lexer-Einstellungen, Stopwortlisten, Umgang mit Umlauten, Thesaurus und mehr ...
Oracle TEXT für alle Daten: User Datastore
Wie erzeugt man einen Oracle TEXT-Index auf mehrere Tabellen ...?
17:00: Ende der Veranstaltung

Die Folien des Workshops stehen ab sofort hier zum Download bereit.

http://apex.oracle.com/folien

Schlüsselwort: oracle-text-workshop

Dienstag, 13. März 2012

Nochmal USER_DATASTORE: Ein umfassendes Beispiel - Teil I

Da wir immer wieder gefragt werden, wie man einen User Datastore mit Oracle TEXT erstellt und auch sehr oft bemerken, dass ein User Datastore DIE Lösung für alle möglichen Suchszenarien ist, möchten wir dieses Blog-Posting nochmals dem User Datastore widmen. Das Beispiel heute ist etwas anspruchsvoller: Wir möchten eine Mitarbeitersuche im Oracle-Beispielschema HR umsetzen. Die zu indizierenden, suchrelevanten Daten sind über mehrere Tabellen verteilt (genau 7) - dennoch soll genau ein Index entstehen, über den ein Mitarbeiter anhand aller möglicher Suchkriterien gefunden werden kann.
  • Anhand des Namens, auch Ähnlichkeitssuche soll möglich sein
  • Anhand der Abteilung
  • Anhand des Ortes, des Landes, der Region
  • Anhand des Jobs
  • Anhand des Managers
Man kann sich schon vorstellen, dass die Lösung dieser Aufgabe mit "klassischem" SQL nicht besonders einfach ist. Aber Oracle TEXT passt hier genau. Zur Verdeutlichung nochmals eine Übersicht über die vorhandenen, zu indizierenden Tabellen.
Damit man die Physik der eigentlichen Datentabellen beliebig ändern kann, werden wir den Volltextindex komplett davon lösen. Es wird also eine eigene "Suchtabelle" angelegt, auf die später der Index erzeugt wird. Damit wir beim Anzeigen der Trefferliste nicht zu den eigentlichen Datentabellen joinen müssen, nehmen wir alle Informationen, die in der Trefferliste angezeigt werden sollen, hier mit auf. Wobei das "nur" die Daten sind, die potenziell in der Trefferliste dargestellt werden - in den Index werden noch mehr Daten aufgenommen.
create table employees_search(
  employee_id      number(6) primary key,
  FIRST_NAME       varchar2(20),
  LAST_NAME        varchar2(25),
  EMAIL            varchar2(25),
  PHONE_NUMBER     varchar2(20),
  JOB_TITLE        varchar2(35),
  DEPARTMENT_NAME  varchar2(30),
  POSTAL_CODE      varchar2(12),
  CITY             varchar2(30),
  COUNTRY_NAME     varchar2(40)
)
/

insert into employees_search(
  select 
    e.EMPLOYEE_ID,
    e.FIRST_NAME,
    e.LAST_NAME,
    e.EMAIL,
    e.PHONE_NUMBER,
    j.JOB_TITLE,
    d.department_name,
    l.postal_code,
    l.city,
    c.country_name
  from 
    employees e 
      join jobs j on (j.job_id = e.job_id)
      join departments d on (d.department_id = e.department_id)
      join locations l on (d.location_id = l.location_id)
      join countries c on (c.country_id = l.country_id)
)
/
Als nächstes wird die Prozedur erstellt, welche die zu indizierenden Daten aufbereitet. Oracle TEXT wird diese Prozedur später für jede Zeile der zu indizierenden Tabelle (EMPLOYEES_SEARCH) aufrufen und das, was die Prozedur zurückgibt, indizieren. Der PL/SQL-Code sollte dann die zu indizierenden Daten aus allen Tabellen "zusammensammeln" und dabei möglichst effizient arbeiten. Wir bedienen uns eines expliziten Cursors in einem Helper-Package. Da wir den Index auf die Tabelle EMPLOYEES_SEARCH erzeugen wollen, müssen wir mit dem Cursor, anhand einer ROWID aus dieser Tabelle, alle Daten zusammenstellen.
create or replace package emp_suche_uds_helper is
 cursor emp_suche_cur (emp_rid rowid) is
  select 
    e.EMPLOYEE_ID,
    e.FIRST_NAME || ' ' || e.LAST_NAME as full_name,
    e.EMAIL,
    e.PHONE_NUMBER,
    to_char(e.hire_date, 'YYYY-MM-DD') hire_date,
    m.first_name || ' ' ||m.last_name as mgr_full_name,
    j.JOB_TITLE,
    d.department_name,
    l.street_address,
    l.postal_code,
    l.city,
    l.state_province,
    c.country_name,
    r.region_name
  from 
    employees_search es 
      join employees e on (e.employee_id = es.employee_id) 
      join jobs j on (j.job_id = e.job_id)
      join departments d on (d.department_id = e.department_id)
      join locations l on (d.location_id = l.location_id)
      join countries c on (c.country_id = l.country_id)
      join regions r on (r.region_id = c.region_id)
      left outer join employees m on (m.employee_id = e.manager_id)
  where es.rowid = emp_rid;
end emp_suche_uds_helper;
/ 
sho err
Danach kommt die eigentliche Prozedur für den User Datastore. Beachtet bitte immer deren Signatur - die ist von Oracle TEXT vorgegeben:
  • Als erstes wird eine ROWID als IN-Parameter erwartet.
  • Der zweite Parameter muss IN OUT und vom Datentyp VARCHAR2, CLOB oder BLOB sein.
Der Code sieht dann wie folgt aus.
create or replace procedure emp_suche_uds_proc(
  rid         in rowid,
  tlob        in out nocopy varchar2
) is
  l_row emp_suche_uds_helper.emp_suche_cur%ROWTYPE;
begin
  if emp_suche_uds_helper.emp_suche_cur%ISOPEN then 
    close emp_suche_uds_helper.emp_suche_cur;
  end if;
 
  open emp_suche_uds_helper.emp_suche_cur(rid);
  fetch emp_suche_uds_helper.emp_suche_cur into l_row;
  tlob := 
    '<EMPLOYEE_ID>'      || l_row.employee_id     || '</EMPLOYEE_ID>'      ||
    '<FULL_NAME>'        || l_row.full_name       || '</FULL_NAME>'        ||
    '<ND_FULL_NAME>'     || l_row.full_name       || '</ND_FULL_NAME>'     ||
    '<EMAIL>'            || l_row.email           || '</EMAIL>'            ||
    '<PHONE_NUMBER>'     || l_row.phone_number    || '</PHONE_NUMBER>'     ||
    '<HIRE_DATE>'        || l_row.hire_date       || '</HIRE_DATE>'        ||
    '<MGR_FULL_NAME>'    || l_row.mgr_full_name   || '</MGR_FULL_NAME>'    ||
    '<ND_MGR_FULL_NAME>' || l_row.mgr_full_name   || '</ND_MGR_FULL_NAME>' ||
    '<JOB_TITLE>'        || l_row.job_title       || '</JOB_TITLE>'        ||
    '<DEPARTMENT_NAME>'  || l_row.department_name || '</DEPARTMENT_NAME>'  ||
    '<STREET_ADDRESS>'   || l_row.street_address  || '</STREET_ADDRESS>'   ||
    '<POSTAL_CODE>'      || l_row.postal_code     || '</POSTAL_CODE>'      ||
    '<CITY>'             || l_row.city            || '</CITY>'             ||
    '<STATE_PROVINCE>'   || l_row.state_province  || '</STATE_PROVINCE>'   ||
    '<COUNTRY_NAME>'     || l_row.country_name    || '</COUNTRY_NAME>'     ||
    '<REGION_NAME>'      || l_row.region_name     || '</REGION_NAME>';
  close emp_suche_uds_helper.emp_suche_cur;
end emp_suche_uds_proc;
/
sho err
Als nächstes sollte man die Prozedur mal testen - eine ROWID der Tabelle EMPLOYEES_SEARCH reingeben und es sollte ein XML-Dokument zurückkommen. Mit SQL*Plus sieht der Test dann so aus ...
SQL> var XML varchar2(4000);
SQL> exec emp_suche_uds_proc('AAArJdAAEAAAJx7AAA', :XML);
SQL> print

XML
--------------------------------------------------------------------------------
<EMPLOYEE_ID>198</EMPLOYEE_ID><FULL_NAME>Donald OConnell</FULL_NAME><ND_FULL_NAM
E>Donald OConnell</ND_FULL_NAME><EMAIL>DOCONNEL</EMAIL><PHONE_NUMBER>650.507.983
3</PHONE_NUMBER><HIRE_DATE>2007-06-21</HIRE_DATE><MGR_FULL_NAME>Kevin Mourgos</M
GR_FULL_NAME><ND_MGR_FULL_NAME>Kevin Mourgos</ND_MGR_FULL_NAME><JOB_TITLE>Shippi
ng Clerk</JOB_TITLE><DEPARTMENT_NAME>Shipping</DEPARTMENT_NAME><STREET_ADDRESS>2
011 Interiors Blvd</STREET_ADDRESS><POSTAL_CODE>99236</POSTAL_CODE><CITY>South S
an Francisco</CITY><STATE_PROVINCE>California</STATE_PROVINCE><COUNTRY_NAME>Unit
ed States of America</COUNTRY_NAME><REGION_NAME>Americas</REGION_NAME>

Puristen mögen einwenden, dass dies gar kein richtiges XML-Dokument ist - denn es fehlt das Root-Tag. Aber das ist Oracle TEXT egal: Ein Root-Tag braucht es nicht unbedingt, also verzichten wir darauf. Wenn die PL/SQL-Prozedur soweit funktioniert, können wir damit beginnen, sie im Oracle TEXT Dictionary zu registrieren. Dazu werden Preference-Objekte erzeugt. Wir beginnen mit der Datastore-Preference:
begin
  ctx_ddl.drop_preference(
    preference_name => 'employee_ds'
  );
end;
/
sho err

begin
  ctx_ddl.create_preference(
    preference_name => 'employee_ds',
    object_name     => 'user_datastore'
  );
  ctx_ddl.set_attribute(
    preference_name => 'employee_ds',
    attribute_name  => 'procedure',
    attribute_value => 'emp_suche_uds_proc'
  );
end;
/
sho err
Jetzt könnte man den Index schon erzeugen und über alle Attribute suchen. Allerdings wollen wir noch zwei Dinge zusätzlich:
  • Wir wollen auch gezielt nach bestimmten Attributen suchen, also nach Manager, Abteilung oder Adresse
  • Für den Employee- und den Managernamen gezielt das Feature "Name Search" einsetzen. Aus diesem Grund sind beide Namen im generieren XML auch zweimal enthalten (FULL_NAME und ND_FULL_NAME, MGR_FULL_NAME und ND_MGR_FULL_NAME).
  • Wir wollen für das HIREDATE die in Version 11 neu eingeführten SDATA-Sections nutzen. Damit wird es möglich, eine Datumssuche (<, >) über den Volltextindex zu machen.
begin
  ctx_ddl.drop_section_group(
    group_name    => 'employee_sg'
  );
end;
/

begin
  ctx_ddl.create_section_group(
     group_name      => 'employee_sg',
     group_type      => 'XML_SECTION_GROUP'
  );
  /*
   * Einfache "Field Sections" für die Suchelemente. Der letzte Parameter legt fest,
   * ob der Section-Name bei Suchen angegeben werden muss ("false") oder ob es auch
   * ohne geht ("true"). 
   */
  ctx_ddl.add_field_section('employee_sg', 'EMPLOYEE_ID',      'EMPLOYEE_ID',      false);
  ctx_ddl.add_field_section('employee_sg', 'FULL_NAME',        'FULL_NAME',        false);
  ctx_ddl.add_field_section('employee_sg', 'EMAIL',            'EMAIL',            false);
  ctx_ddl.add_field_section('employee_sg', 'PHONE_NUMBER',     'PHONE_NUMBER',     false);
  ctx_ddl.add_field_section('employee_sg', 'MGR_FULL_NAME',    'MGR_FULL_NAME',    false);
  ctx_ddl.add_field_section('employee_sg', 'JOB_TITLE',        'JOB_TITLE',        false);
  ctx_ddl.add_field_section('employee_sg', 'DEPARTMENT_NAME',  'DEPARTMENT_NAME',  false);
  ctx_ddl.add_field_section('employee_sg', 'STREET_ADDRESS',   'STREET_ADDRESS',   false);
  ctx_ddl.add_field_section('employee_sg', 'POSTAL_CODE',      'POSTAL_CODE',      false);
  ctx_ddl.add_field_section('employee_sg', 'CITY',             'CITY',             false);
  ctx_ddl.add_field_section('employee_sg', 'STATE_PROVINCE',   'STATE_PROVINCE',   false);
  ctx_ddl.add_field_section('employee_sg', 'COUNTRY_NAME',     'COUNTRY_NAME',     false);
  ctx_ddl.add_field_section('employee_sg', 'REGION_NAME',      'REGION_NAME',      false);
  /*
   * Auf das Hiredate soll die Suche auch mit ">" und "<" möglich sein, daher SDATA-Section 
   */
  ctx_ddl.add_sdata_section('employee_sg', 'HIRE_DATE',        'HIRE_DATE',        'DATE');
  /*
   * Zusätzliche NDATA-Sections für Namenssuche 
   */
  ctx_ddl.add_ndata_section('employee_sg', 'ND_MGR_FULL_NAME', 'ND_MGR_FULL_NAME');
  ctx_ddl.add_ndata_section('employee_sg', 'ND_FULL_NAME',     'ND_FULL_NAME'    );
end;
/
sho err
Es werden drei unterschiedliche Section-Typen innerhalb der Section Group employee_sg erzeugt. Eine Field Section ist der einfachste Typ: In einer solchen Section kann einfacher Text stehen, der normal indiziert wird. Untertags sind jedoch nicht erlaubt; geschachtelte Strukturen müssen als Zone-Sections deklariert werden - die brauchen aber etwas mehr Platz im Index. Wichtig beim Aufruf von ADD_FIELD_SECTION ist der letzte Parameter VISIBLE. Wird er auf "false" gesetzt, so muss die Section bei der Suche stets angebenen werden - es muss also immer "MILLER within (FULL_NAME)" gesucht werden. Steht er auf "true", kann man auch einfach nur nach "MILLER" suchen - letzteres macht den Index aber auch größer - man muss einfach anhand der Anforderungen entscheiden. Mehr zu Zone- und Field-Sections findet Ihr hier.
Für die Namenssuche haben wir, wie schon gesagt, zusätzliche XML-Tags erzeugt - für diese Tags werden eigene NDATA-Sections erzeugt. Diese machen die in 11.2 neu eingeführte Name Search möglich. Man kann also für eine Namenssuche entweder mit der "normalen" Fuzzy-Suche arbeiten, oder, wenn diese "nicht genug" findet, die spezielle Namenssuche anwerfen.
Als nächstes legen wir eine Wordlist-Preference an. Damit werden wir einige Einstellungen für Name Search vornehmen und allgemein Dinge wie die Reduktion von diakritischen Zeichen auf ihre Grundformen aktivieren. Ein Herr "Müller" wird also als "MULLER" in den Index geschrieben - man kann ihn dann entweder als Müller oder als Muller finden - letzteres ist wichtig, wenn international gearbeitet werden soll - schließlich ist nicht jede Tastatur mit deutschen Umlauten gesegnet. Im folgenden werden die dazu nötigen Wordlist und Lexer Preferences eingestellt.
begin
 ctx_ddl.drop_preference('employee_wl');
end;
/
sho err

begin
  ctx_ddl.create_preference('employee_wl', 'BASIC_WORDLIST');
  ctx_ddl.set_attribute('employee_wl', 'NDATA_ALTERNATE_SPELLING', 'TRUE');
  ctx_ddl.set_attribute('employee_wl', 'NDATA_BASE_LETTER',        'TRUE');
end;
/
sho err


begin
 ctx_ddl.drop_preference('employee_lx');
end;
/
sho err

begin
  ctx_ddl.create_preference('employee_lx', 'BASIC_LEXER');
  ctx_ddl.set_attribute('employee_lx', 'MIXED_CASE',       'NO');
  ctx_ddl.set_attribute('employee_lx', 'BASE_LETTER',      'YES');
  ctx_ddl.set_attribute('employee_lx', 'BASE_LETTER_TYPE', 'GENERIC');
end;
/
sho err
Mehr Informationen zu den verfügbaren Einstellungen findet sich in der Dokumentation:
Nun ist es geschafft. Wir können den Index (endlich) anlegen.
create index ft_employee_suche on employees_search(last_name)
indextype is ctxsys.context
parameters('
  datastore      employee_ds
  section group  employee_sg
  wordlist       employee_wl
  lexer          employee_lx
  stoplist       ctxsys.empty_stoplist
  memory 500M
')
/
Wenn der Index fertig ist, kann man suchen ... die SQL-Abfrage sieht immer etwa so aus ..
select employee_id, first_name, last_name from employees_search 
where contains(last_name, '{contains-query}') > 0
  • Suche nach einem "Accountant" namens "Higins" oder so ähnlich:
    ?Higins within (FULL_NAME) and ?Accountant within (JOB_TITLE)
  • Suche nach dem Team von einem Manager, dessen Name irgendwie auf "assuriz" endet (klassisch mit "Fuzzy" findet nichts):
    ?assuriz within (MGR_FULL_NAME)
  • Suche nach dem Team von einem Manager, dessen Name irgendwie auf "assuriz" endet (Name Search ist erfolgreich):
    NDATA(ND_MGR_FULL_NAME, assuriz)
  • Mit Name Search kann man Vor- und Nachnamen auch verdrehen:
    NDATA(FULL_NAME, Baer Hermann)
  • Alle Angestellten in Oxford, die nach dem 01.01.2008 eingestellt wurden:
    Oxford within (CITY) and SDATA(HIRE_DATE >= '2008-01-01')
Es sind beliebige Abfragen denkbar. Innerhalb von CONTAINS kann man ja mit AND, OR, NOT arbeiten und sich damit beliebig komplexe Abfrageausdrücke überlegen. Und das alles wird aus ein- und demselben Index bedient und zusätzlich hat man noch linguistische Features wie die Base-Letter Konvertierung (Ä -> A), Ähnlichkeits- und Namenssuche. Für Suchapplikationen (bspw. im Callcenter) kann Oracle TEXT so eine sehr mächtige Angelegenheit sein und durchaus auch mit spezieller Software mithalten. Und bei allem immer im Auge behalten: Oracle TEXT ist in der Datenbank "drin" und kostet nix extra!.
Es bleibt nun die Frage, was bei Datenänderungen (DML) an den zugrundeliegenden Tabellen passiert. Soviel vorab: Der bis hierher angelegte Index bekommt von etwaigen Änderungen überhaupt nichts mit. Um ihn zu aktualisieren, müsste man ihn neu bauen - und für manche Anwendungen würde das vielleicht auch in einem nächtlichen Wartungsfenster reichen. Andere Anwendungen brauchen eher einen ständig aktuellen Index - und wie man das macht, erfahrt Ihr im nächsten Blog-Posting.

Montag, 20. Februar 2012

Statistiken im Oracle Text Umfeld

Spätestens seit Oracle 10g besitzt das Sammeln von Statistiken bzw. die Relevanz von korrekten Statistiken einen hohen Stellenwert und stellt einen Garant für gute Performance dar. Um das Management für das Sammeln von Statistiken zu vereinfachen, führte Oracle daher mit 10g die sogenannten Maintenance Jobs ein, die meist in einem nächtlichen Job diese Aufgabe übernehmen.

Was bedeutet dies nun für den Oracle Text Index?
Zieht man das Handbuch Oracle Text Application Developer's Guide 11g Release 2 (11.2) zu rate, findet man im Abschnitt "Tuning Oracle Text" auf die Frage, ob man Statistiken sammeln sollte oder nicht, folgende nicht eindeutige Antwort dazu:
"Yes. Collecting statistics on your tables enables Oracle Text to do cost-based analysis. This helps Oracle Text choose the most efficient execution plan for your queries. If your queries are always pure text queries (no structured predicate and no joins), you should delete statistics on your Oracle Text index."

Noch einmal zur Erinnerung, wenn wir einen Text Index (z. B. TEXT_IDX) erzeugen, werden automatisch mindestens folgende Objekte erzeugt:
  • DR$TEXT_IDX$I: Token Tabelle
  • DR$TEXT_IDX$X: Index
  • DR$TEXT_IDX$K: DOCID (nach ROWID) Mapping Tabelle
  • DR$TEXT_IDX$N: Tabelle für Negativliste für alle gelöschten DOCIDs
  • DR$TEXT_IDX$R: ROWID (nach DOCID) Mapping Tabelle
Was bedeutet dies für die einzelnen Objekte des Textindex?
  1. Sollten Statistiken auf den einzelnen DR$ Objekten existieren?
    Die Antwort darauf lautet nein! Alle internen rekursiven Abfragen haben Hints (wie zum Beispiel /*+DYNAMIC_SAMPLING(0) INDEX(T "DR$TEST_IDX$X")*/) um einen festgelegten Ausführungsplan zu verwenden. Dieser Plan hat sich als bester Plan erwiesen. Statistiken auf den Objekten könnten zu einem veränderten und somit schlechteren Plan führen.
  2. Werden Statistiken im Maintenance Job für Oracle Text mitgepflegt?
    Auch hier lautet die Antwort nein. DBMS_STATS.GATHER_SCHEMA_STATS oder DBMS_STATS.GATHER_DATABASE_STATS analysiert keine internen Texttabellen und Indizes.

Um zu verifizieren, ob Ihre Umgebung die Regel 1) erfüllt, führen Sie einfach folgenden Test durch:
SQL> select table_name,last_analyzed 
     from user_tables where table_name like '%TEST_IDX%';

TABLE_NAME                     LAST_ANAL
------------------------------ ---------
DR$TEST_IDX$I
DR$TEST_IDX$R
DR$TEST_IDX$K
DR$TEST_IDX$N
Für die Indizes ergibt sich folgende Abfrage:
SQL> select index_name, user_stats, global_stats, last_analyzed
     from user_indexes where table_name like '%TEST_IDX%';

INDEX_NAME                     USE GLO LAST_ANAL
------------------------------ --- --- ---------
SYS_IOT_TOP_223146             NO  NO
DR$TEST_IDX$X                  NO  NO  
SYS_IL0000223143C00002$$       NO  NO
SYS_IOT_TOP_223141             NO  NO
SYS_IL0000223138C00006$$       NO  NO
Haben die Einträge in der Spalte LAST_ANALYZED den Wert "null", müssen Sie nichts unternehmen. Finden Sie Statistiken auf einem dieser Objekte, löschen Sie diese wie folgendes Beispiel zeigt.
SQL> select index_name, user_stats, global_stats, last_analyzed
     from user_indexes where table_name like '%TEST_IDX%';

INDEX_NAME                     USE GLO LAST_ANAL
------------------------------ --- --- ---------
SYS_IOT_TOP_223146             NO  NO
DR$TEST_IDX$X                  NO  NO  20-FEB-12
SYS_IL0000223143C00002$$       NO  NO
SYS_IOT_TOP_223141             NO  NO
SYS_IL0000223138C00006$$       NO  NO

SQL> execute dbms_stats.delete_index_stats('US','DR$TEST_IDX$X');

--- zur Kontrolle

SQL> select index_name, user_stats, global_stats, last_analyzed
     from user_indexes where table_name like '%TEST_IDX%';

INDEX_NAME                     USE GLO LAST_ANAL
------------------------------ --- --- ---------
SYS_IOT_TOP_223146             NO  NO
DR$TEST_IDX$X                  NO  NO
SYS_IL0000223143C00002$$       NO  NO
SYS_IOT_TOP_223141             NO  NO
SYS_IL0000223138C00006$$       NO  NO
Weitere Informationen zu dem Thema finden Sie auch in der öffentlichen My Oracle Support Note DOC ID 139979.1.

Dienstag, 24. Januar 2012

Neue Oracle Text Features

Häufig werden wir nach den neuen Features im Bereich Oracle Text gefragt. Besonders wichtig wird dies, wenn eine Migration ansteht. Wichtig zu wissen ist, dass in der Regel keine Veränderungen an den Applikationen vorgenommen werden müssen, sondern die Anwendungen ohne weitere Bearbeitung übernommen werden können. Einzige Ausnahme bildet vielleicht der Wechsel in der Filternutzung. Ab 11g Release 1 ist der INSO_FILTER Typ durch den AUTO_FILTER Typ ersetzt worden. Dies wird für die meisten Text Nutzer keinen großen Unterschied darstellen. Wer sicher gehen möchte, welches die genauen Unterschiede zwischen den beiden Filtern sind, kann im Oracle Text Application Developer's Guide 11g Release 2 (11.2) Handbuch unter New Filter (INSO_FILTER versus AUTO_FILTER) nachsehen. Ausserdem kann aus Kompatibilitätsgrunden in 11g immer noch den INSO_FILTER Typ verwendet werden.
Bei der Migration möchte man allerdings nicht nur die Funktionalität und Performance der Anwendungen aufrecht erhalten, sondern auch von Vereinfachungen bzw. Erweiterungen im neuen Release profitieren. Wo findet man diese Informationen? Die beste Quelle ist das Oracle Text Reference 11g Release 2 (11.2) Handbuch. Hier findet man folgende Link-Einträge zum Thema 11gR1 und 11gR2: Im folgenden Abschnitt wollen wir die wichtigsten Features noch einmal auflisten und die entsprechenden Blog-Einträge - falls vorhanden - dazu angeben.
In 11g Release 1 sind folgende Features eingeführt worden:
  1. Zero Downtime für Textanwendungen mit neuem inkrementellen Index-Feature und Online Index Creation bzw. Re-creation
  2. NOPOPULATE Option für ALTER INDEX Kommando zur Unterstützung der inkrementellen Indizierung
  3. Neue Oracle Text Manager Features im Oracle Enterprise Manager
  4. Support für Composite Domain Indextyp um die mixed-query Performance zu erhöhen
  5. SDATA Section Typ und SDATA Operator für die Bereichssuche von Metadata
  6. User definiertes Scoring Feature mit DEFINESCORE und DEFINEMERGE Operatoren
  7. Detailliertes Database Usage Tracking Feature für Oracle Text
In 11g Release 2 finden sich folgende Erweiterungen:
  1. Name Searching: Diese neue Funktion in Oracle TEXT ist speziell für die Suche nach Namen vorgesehen. Namen werden ja, insbesondere wenn Sie aus einem anderen Sprachraum kommen, recht häufig falsch geschrieben oder falsch verstanden. Eine exakte Suche hilft oft nicht weiter. Mit der FUZZY-Suche kann man zwar schon nach ähnlich geschriebenen Begriffen suchen, für eine umfassende Suche nach Namen reicht das jedoch vielfach nicht aus. Hier könnte das Name earching Feature weiterhelfen. Die Blogeinträge zu dem Thema finden sich unter
  2. Result set interface: Die Idee ist, vielfältige komplexe Abfragen für Ergebnismengen im Textumfeld, auf einen einzigen SQL Call zu reduzieren und damit Ressourcen zu sparen und die Performance zu erhöhen.

Montag, 21. November 2011

Tablespace und mehr: Storage-Klausel für den Oracle-TEXT Index

Nachdem uns jüngst die Frage erreichte, wie man den Tablespace für einen Oracle TEXT-Index festlegen
kann ... machen wir dazu gleich ein Posting: Im Gegensatz zu einem normalen Textindex kann man nicht
einfach eine TABLESPACE-Klausel an das CREATE INDEX-Kommando anhängen. Das folgende funktioniert also
nicht.
create index ft_dokument on dokumente_tab(dokument)
indextype is mdsys.context
tablespace TS_IDXDATA
/
Bei Oracle TEXT ist hier etwas mehr zu tun. Oracle TEXT erlaubt unglaublich viel Flexibilität, was
auf der anderen Seite natürlich immer Konfigurationsaufwand bedeutet. Aber zum Thema: Ein Oracle TEXT Index
besteht intern stets aus mindestens vier Tabellen: $I, $R, $K und $N. Je nachdem, welche zusätzlichen
Features aktiviert wurden, kommen noch Tabellen dazu. Und jede dieser Tabellen kann ihre eigene
Storage-Klausel bekommen. Wie immer bei Oracle TEXT wird auch hier mit den Preference-Objekten
gearbeitet - diese physikalischen Details werden in eine Storage Preference gespeichert (nicht zu
verwechseln mit der Datastore Preference, die beschreibt, wo die zu indizierenden Daten herkommen). Wir
wollen also unseren TEXT Index in den Tablespace TS_IDXDATA legen. Also brauchen alle Tabellen, die
Oracle TEXT unter der Haube erzeugt, eine entsprechende Storage-Klausel.
begin
  ctx_ddl.create_preference('mystore', 'BASIC_STORAGE');

  ctx_ddl.set_attribute('mystore', 'I_TABLE_CLAUSE', 'tablespace ts_idxdata '); 
  ctx_ddl.set_attribute('mystore', 'K_TABLE_CLAUSE', 'tablespace ts_idxdata '); 
  ctx_ddl.set_attribute('mystore', 'R_TABLE_CLAUSE', 'tablespace ts_idxdata LOB(DATA) STORE AS (CACHE)');
  ctx_ddl.set_attribute('mystore', 'N_TABLE_CLAUSE', 'tablespace ts_idxdata '); 
  ctx_ddl.set_attribute('mystore', 'I_INDEX_CLAUSE', 'tablespace ts_idxdata compress 2');
  ctx_ddl.set_attribute('mystore', 'P_TABLE_CLAUSE', 'tablespace ts_idxdata '); 
  ctx_ddl.set_attribute('mystore', 'S_TABLE_CLAUSE', 'tablespace ts_idxdata ');
end;
/
Wie man am Skript sehr schön sehen kann, werden hier die einzelnen Storage Klauseln für alle
an einem Textindex beteiligten Tabellen hinterlegt. Hier kann alles eingetragen werden, was auch
in die Storage-Klausel einer "normalen" Tabelle hineinkann. Wichtig sind allerdings die Einstellungen
LOB (DATA) STORE AS (CACHE) bei der R_TABLE_CLAUSE und COMPRESS 2 bei der I_INDEX_CLAUSE. Diese
Defaulteinstellungen sind sehr wichtig und es ist für die Performance ganz entscheidend, diese
bei eigenen Storage-Klauseln ebenfalls zu übernehmen. Hieran sollte man immer denken!
Die Nutzung der Storage Preference ist nun wieder einfach:
create index ft_dokument on dokumente_tab(dokument)
indextype is mdsys.context
parameters ('storage mystore')
/
Ansonsten gilt, wie gesagt: Es werden Standard-Storage-Klauseln für Tabellen hinterlegt. Neben dem
Tablespace selbst können also alle möglichen Details eingetragen werden. Am wichtigsten sind jedoch
wahrscheinlich in allen Fällen die Einstellungen zum Tablespace, zur Extent-Verwaltung oder zum Cache.
Weitere Details lassen sich in der Dokumentation nachlesen.

Beliebte Postings