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
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.
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:
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.

