Archiv für die Kategorie TOI

Brief introduction into External Tables

As an Oracle DBA, you will sooner or later encounter the task to deal with interface files (Flat Files) from some other application that you need to process in your Oracle Database. External Tables, introduced in 9i already, are usually the tool of choice for that and can be considered as the successor of the ancient SQL*Loader for that purpose.

An External Table is Metainformation that is stored in the Data Dictionary together with a pointer on the concrete Flat File, placed on the Database Server. We can access this External Table with the same SELECT statements as we would use against ordinary Tables. I have prepared a demonstration with the Flat File ulcase2.dat in the directory /home/oracle/interface on my server:

-bash-3.00$ pwd
/home/oracle/interface
-bash-3.00$ ls -al
total 16
drwxr-xr-x   2 oracle oinstall 4096 Oct 28 14:34 .
drwxrwxrwx  30 oracle oinstall 4096 Oct 28 14:11 ..
-rw-r--r--   1 oracle oinstall  372 Oct 28 14:11 ulcase2.dat
-bash-3.00$ cat ulcase2.dat
7782 CLARK      MANAGER   7839  2572.50          10
7839 KING       PRESIDENT       5500.00          10
7934 MILLER     CLERK     7782   920.00          10
7566 JONES      MANAGER   7839  3123.75          20
7499 ALLEN      SALESMAN  7698  1600.00   300.00 30
7654 MARTIN     SALESMAN  7698  1312.50  1400.00 30
7658 CHAN       ANALYST   7566  3450.00          20

This is just an ordinary ASCII file that we want to access from our Oracle Database:

SQL> grant dba to adam identified by adam;

Grant succeeded.

SQL> connect adam/adam
Connected.

That’s my demo user. Granting the role dba makes the demo easier – no need to grant create/read/write directory privileges especially. Next step is to create a directory as a Database Object, pointing to the OS directory:

SQL> create directory interface_dir as '/home/oracle/interface';

Directory created.

The same directories are needed when we use Data Pump to put Database Objects into binary files. Now here comes the External Table:

SQL> create table interface_table
(
 empno number(4),
 ename varchar2(10),
 job varchar2(9),
 mgr number(4),
 sal number(7,2),
 comm number(7,2),
 deptno number(2)
)
organization external
(
 type oracle_loader
 default directory interface_dir
 access parameters
 (
 records delimited by newline characterset we8iso8859p1
 badfile 'INTERFACE_DIR':'interface.bad'
 logfile 'interface.log_xt'
 fields ldrtrim
 (
 empno (1:4) integer external(4),
 ename (6:15) char(10),
 job (17:25) char(9),
 mgr (27:30) integer external(4),
 sal (32:39) integer external(8),
 comm (41:48) integer external(8),
 deptno (50:51) integer external(2)
 )
 )
 location
 (
 'ulcase2.dat'
 )
)
reject limit unlimited;
Table created.

This is no ordinary table made up by extents and blocks but merely a description of the Flat File:

SQL> select * from user_segments;

no rows selected

SQL> select table_name,tablespace_name from user_tables;

TABLE_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
INTERFACE_TABLE

Apart from that, we can access it with SELECT like an ordinary table:

SQL> select * from interface_table;

 EMPNO ENAME      JOB              MGR        SAL       COMM     DEPTNO
---------- ---------- --------- ---------- ---------- ---------- ----------
 7782 CLARK      MANAGER         7839     2572.5                    10
 7839 KING       PRESIDENT                  5500                    10
 7934 MILLER     CLERK           7782        920                    10
 7566 JONES      MANAGER         7839    3123.75                    20
 7499 ALLEN      SALESMAN        7698       1600        300         30
 7654 MARTIN     SALESMAN        7698     1312.5       1400         30
 7658 CHAN       ANALYST         7566       3450                    20

8 rows selected.

We can put functions into the query, can add where condition to filter the result set, can choose only some columns etc. That is why External Tables are much more flexible to use as the old SQL*Loader was.

But never the less, SQL*Loader is still useful today to teach us how to create External Tables 🙂 If you look into the Online Documentation of the 9i version, you can still find the SQL*Loader case studies there – that vanished in 10g and above. You see the most common cases of interface files there together with a SQL*Loader controlfile to load them.

If you call the SQL*Loader then with the parameter external_table=generate_only, it gives you the create statement for an External Table – a thing that is not so easy to derive from the External Table Online Documenation, unfortunately.

Another nice usage of External Tables is, that we can access the Alert Log file with them from inside the Database without having to logon to the Database Server:

SQL> show parameter background_dump_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- --------------------------------
background_dump_dest                 string      /u01/app/oracle/admin/orcl/bdump

SQL> create or replace directory bdump as '/u01/app/oracle/admin/orcl/bdump';

Directory created.

SQL> create table alert_log
 (line1 varchar2(4000))
 organization external
 (type oracle_loader
 default directory bdump
 access parameters
 (records delimited by newline fields missing field values are null)
 location ('alert_orcl.log')
 )
/  

Table created.

Conlusion: If you need to process Interface Files in your Oracle Database, take a closer look at External Tables for that purpose – the SQL*Loader is a little old fashioned compared to them

,

6 Kommentare

Advert: I will present at the DOAG Conference about 11g Data Guard New Features

The German Oracle User Group (DOAG) is staging their annual Conference. I will give a presentation on 19-NOV-2010 about 11g Data Guard New Features there. It will be in German Language and cover

  • Creation of Physical Standby Database without previous Backup
  • Embedding the Primary & Standby into Oracle Restart
  • Real-Time Query (Using Physical Standby for Reporting while Redo Apply is on)
  • Snapshot Standby (Using Physical Standby for Testing while still receiving Redo Protocol from Primary)
  • Fast-Start Failover in Maximum Performance Mode

Every Topic will be accompanied by Live Demonstrations on the Command Line. You may enroll online here.

, ,

Hinterlasse einen Kommentar

Voting Disk and OCR in 11gR2: Some changes

Having just delivered an Oracle Database 11gR2 RAC Admin course, I’d like to point out some remarkable changes in the way we handle now the important Clusterware components Voting Disk and Oracle Cluster Registry (OCR): Amazingly, we can now store the two inside of an Automatic Storage Management (ASM) Disk Group, which was not possible in 10g.

The OCR is striped and mirrored (if we have a redundancy other than external), similar as ordinary Database Files are. So we can now leverage the mirroring capabilities of ASM to mirror the OCR also, without having to use multiple RAW devices for that purpose only. The Voting Disk (or Voting File, as it is now also referred to) is not striped but put as a whole on ASM Disks – if we use a redundancy of normal on the Diskgroup, 3 Voting Files are placed, each on one ASM Disk into a different failgroup. Therefore, you need to have at least 3 failgroups for that diskgroup, like on this picture:

ASM Diskgroup that contains Voting Files and OCR

This is a concern, if our ASM Diskgroups consist of only 2 ASM Disks respectively only 2 failgroups like with Extended RAC! Therefore, the new quorum failgroup clause was introduced:

create diskgroup data normal redundancy
 failgroup fg1 disk 'ORCL:ASMDISK1'
 failgroup fg2 disk 'ORCL:ASMDISK2'
 quorum failgroup fg3 disk 'ORCL:ASMDISK3'
 attribute 'compatible.asm' = '11.2.0.0.0';

The failgroup fg3 above needs only one small Disk (300 MB should be on the safe side here, since the Voting File is only about 280 MB in size) to keep one Mirror of the Voting File. fg1 and fg2 will contain each one Voting File and all the other stripes of the Database Area as well, but fg3 will only get that one Voting File.

[root@uhesse1 ~]#  /u01/app/11.2.0/grid/bin/crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   511de6e64e354f9bbf4be318fc928c28 (ORCL:ASMDISK1) [DATA]
 2. ONLINE   2f1973ed4be84f50bffc2475949b428f (ORCL:ASMDISK2) [DATA]
 3. ONLINE   5ed44fb7e79c4f79bfaf09b402ba70df (ORCL:ASMDISK3) [DATA]

Another important change regarding the Voting File is that it is no longer supported to take a manual backup of it with dd. Instead, the Voting File gets backed up automatically into the OCR. As a New Feature, you can now do a manual backup of the OCR any time you like, without having to wait until that is done automatically – which is also still done:

[root@uhesse1 ~]# /u01/app/11.2.0/grid/bin/ocrconfig -showbackup

uhesse1     2010/10/06 09:37:30     /u01/app/11.2.0/grid/cdata/cluhesse/backup00.ocr
uhesse1     2010/10/06 05:37:29     /u01/app/11.2.0/grid/cdata/cluhesse/backup01.ocr
uhesse1     2010/10/06 01:37:27     /u01/app/11.2.0/grid/cdata/cluhesse/backup02.ocr
uhesse1     2010/10/05 01:37:21     /u01/app/11.2.0/grid/cdata/cluhesse/day.ocr
uhesse1     2010/10/04 13:37:19     /u01/app/11.2.0/grid/cdata/cluhesse/week.ocr

Above are the automatic backups of the OCR as in earlier versions. Now the manual backup:

[root@uhesse1 ~]# /u01/app/11.2.0/grid/bin/ocrconfig -manualbackup
uhesse1     2010/10/06 13:07:03     /u01/app/11.2.0/grid/cdata/cluhesse/backup_20101006_130703.ocr

I got a manual backup on the default location on my master node. We can define another backup location for the automatic backups as well as for the manual backups – preferrable on a Shared Device that is accessible by all the nodes (which is not the case with /home/oracle, unfortunately 🙂 ):

[root@uhesse1 ~]# /u01/app/11.2.0/grid/bin/ocrconfig -backuploc /home/oracle
[root@uhesse1 ~]# /u01/app/11.2.0/grid/bin/ocrconfig -manualbackup
uhesse1     2010/10/06 13:10:50     /home/oracle/backup_20101006_131050.ocr
uhesse1     2010/10/06 13:07:03     /u01/app/11.2.0/grid/cdata/cluhesse/backup_20101006_130703.ocr

[root@uhesse1 ~]# /u01/app/11.2.0/grid/bin/ocrconfig -showbackup
uhesse1     2010/10/06 09:37:30     /u01/app/11.2.0/grid/cdata/cluhesse/backup00.ocr
uhesse1     2010/10/06 05:37:29     /u01/app/11.2.0/grid/cdata/cluhesse/backup01.ocr
uhesse1     2010/10/06 01:37:27     /u01/app/11.2.0/grid/cdata/cluhesse/backup02.ocr
uhesse1     2010/10/05 01:37:21     /u01/app/11.2.0/grid/cdata/cluhesse/day.ocr
uhesse1     2010/10/04 13:37:19     /u01/app/11.2.0/grid/cdata/cluhesse/week.ocr
uhesse1     2010/10/06 13:10:50     /home/oracle/backup_20101006_131050.ocr
uhesse1     2010/10/06 13:07:03     /u01/app/11.2.0/grid/cdata/cluhesse/backup_20101006_130703.ocr

Conclusion: The way to handle Voting Disk and OCR has changed significantly – they can be kept inside of an ASM Diskgroup especially.

, ,

88 Kommentare