Date: Mon, 25 Nov 2002 17:45:56 -0500
Reply-To: Richard Graham <richardwgraham@earthlink.net>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Richard Graham <richardwgraham@EARTHLINK.NET>
Organization: Glencairn Consulting Group
Subject: Re: SAS/UNIX Work Area
Content-Type: text/plain; charset="iso-8859-1"
Jules,
I cannot make an assessment regarding the behavior; however, you might want
to consider loading the data from SAS into a set of staging tables in
Oracle. After all data are loaded, you could then conduct some evaluations
of the data just loaded (i.e., check that what is loaded into the staging
tables is what is expected for one, do other checks for bogus records,
etc.). If everything in NOT OK, then processing would cease. If all is
well, then execute some SQL pass-thru code that moves the data into the
production tables from the staging tables.
I just recently implemented a SAS/Oracle data repository (can't call it a
warehouse due to governmental politics) that utilizes this methodology.
Originally, the load procedure utilized the SAS DBLOAD procedure. One
problem with this procedure is that it can handle only 8-char variable
names, so I found that every variable had to be renamed prior to loading
then renamed on the DBLOAD procedure. It was a fairly fast implementation;
however, I recently re-wrote that part of code to implement a SAS call to
Oracle's SQL Loader. I got twice the speed of loading relative to the SAS
DBLOAD procedure. By the way, I'm loading 200K to 300K records per night.
Under the original implementation, the process was running consistently in
about an hour. Now with the new implementation, the process runs in about
30 minutes.
Just some ideas for you to ponder.
Richard W. Graham
Glencairn Consulting Group
----- Original Message -----
From: "Bosch, Jules [PRDUS Non J&J]" <JBosch1@PRDUS.JNJ.COM>
To: <SAS-L@LISTSERV.VT.EDU>
Sent: Monday, November 25, 2002 3:16 PM
Subject: SAS/UNIX Work Area
> Dear All,
>
> We ran some SAS (V8.2) application tests on Nov 14 in a UNIX test
directory.
> We purposely created bogus records to force the tests to fail and they
did.
> When the application fails the SAS process stops and locked ORACLE tables
> remain locked and no update is attempted. This is good.
>
> On Friday Nov 22, the processing of our SAS application was directed to
> another UNIX work area on the same server. Now, however, the bogus
records
> do not force errors, as they did on Nov 14, and the ORACLE tables are
> unlocked and overlaid with bogus data. This is bad. Of course, the SAS
> code in play has not changed since Nov 14.
>
> So, is it possible that the second SAS work area could be different in
some
> way from the original SAS work area such that the described untoward
> behavior could occur? I can't think of any other change that has taken
> place that would cause this problem.
>
> Any thoughts would be greatly appreciated.
>
> Jules Bosch
>
| 
