Next: Loading SYSLOG into a
Up: The Cuddletech SAs Guide
Previous: Regarding PERL
Contents
You might wonder, why in this guide do I want to talk about the SQL*Loader...
I mean, isn't this an SA centric paper? Why care about DBA utilities.
Well, I discuss the programming interfaces and SQL*Loader for two reasons.
First, as an SA the DBAs are gonna bug you when they break, and we
know more about general programming and parsing techniques than the DBAs do
(hopefully). Secondly, as an SA I'm really concerned about recovering the database
if the system gets dumped/destroyed for some reason. I don't really care
about recovering a table or an index, thats stuff the DBAs can handle using
their normal backups via RMAN hooked into our awsome NetBackup server.
In order to look at recovery systems in the following chapters we need to actually
put data in the databases so that we can verify we actually did recover the
database properly. Thus, PL/SQL and SQL*Loader in particular are good ways
to automate some additions to the database so we can later recover databases with
some feeling that we really got it all back. Sitting around doing SQL INSERTs
all day ain't my idea of fun.
SQL*Loader is essentially a fatty parser. It can take delimited input data files
and parse and sort them into the tables we want them in. This is useful
for taking output data from some other system (a firewall log? apache logs?
offsite tape report?) and loading it into Oracle tables. So, basically, it is
what it sounds like.
You can interface with SQL*Loader using the sqlldr command line utility
or using PL/SQL. Obviously you first need to start by seting up a table for the
data to go. Next you'll create a SQL*Loader control file. The control file describes
the data, how to load it and to where to put it. Then we can actually go and
run the loader on our data and put it in the database.
Subsections
Next: Loading SYSLOG into a
Up: The Cuddletech SAs Guide
Previous: Regarding PERL
Contents
2005-02-10