Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Massive update troubles
"...the SAP requirements are slowly mutating...", "...the developers are still tweaking the process..."
If the developpers are still tweaking the process, and the requirements still evolving, it means that they are still in a test phase. If they are still in a test phase, they shouldn't use production files but test files...smaller files.
Don Jerman <djerman_at_dot.state.nc.us>@fatcity.com on 2002-08-01 17:14:40
Please respond to ORACLE-L_at_fatcity.com
Sent by: root_at_fatcity.com
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc:
I have a data conversion team working on our financial data, prepping it for load into SAP. My concept for the conversion process was to download the flat files, run programs written in C or Perl to transform the data, then use SQL*Loader to load them into relational tables for constraint testing and general analysis, prior to export to the SAP system.
At some point early on I lost control, and this mutated into: download the flat files, load them into Oracle, run stored procedures to transform the data through 2 or 3 stages to a new schema for SAP. Still ok, you're thinking.
But -- now we're running more than a couple hundred thousand rows
at the time, and the developers are still tweaking the process
(because the SAP requirements are slowly mutating -- another
issue). Frequently the developers will stop a long running query
with ALTER SESSION KILL -- this is working but often takes a very
long time to roll back. Well, there's the rub -- this is a PC
system, and the developers frequently want to make a tweak to
their program and re-run it. This puts a tremendous load on what
the PC isn't good at -- I/O.
So I wind up with a frantic developer on the phone "the Oracle server's locked up!" and sure enough, he's right -- there's so much going on in there you can't do anything that requires a disk access..... The evolved response is shutdown abort, startup mount, recover, open. This always works and always takes about 3 minutes. Naturally, I've moved them to their Very Own server, so that this doesn't disrupt other work.
Can anyone turn their diagonstic eyes on this situation and suggest a better method for me to either limit the damage or recover from the problem? Or even a good method for analyzing the problem, given that we haven't the downtime to wait for all processes to complete (once in this state, a weekend can pass without successfully ending whatever the database is doing).
(See attached file: djerman.vcf)
-- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bart Cortenbach INET: bart.cortenbach_at_bzcorp.ca Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-LReceived on Thu Aug 01 2002 - 17:23:28 CDT
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
- application/octet-stream attachment: djerman.vcf
![]() |
![]() |