Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: bypass rollback for large insert statements
There is none. There is an undocumented init.ora to disable the redo log, but that has the disadavantage *all* redologging is disabled and you're on your own, as support won't help you, when things go wrong.
It also would completely violate the transactional model.
If you are experiencing problems you need to either
a) enlarge your rollback segments
or
b) create one large rollback segment assigning your transaction to that
rollback segment
or
c) divide your transaction into smaller ones.
If you experience performance problems the following remarks can be made
- quite likely you need to verify the alert log for messages like
'checkpoint not complete' or 'cannot allocate log, archival required'. Both
will block the complete database.
You'll need to make sure the redolog files are large enough and you have
enough of them (4 minimum) so you have checkpoints once in 15 mins. You can
verify that by checking v$log_history
- most likely the mass insert will screw up the structure of your indexes on
that particular table. Index changes *are* logged (both in rollback segments
and in redolog files), so in extreme cases you might consider dropping your
indexes and recreating them (or rebuilding them) after the operation.
Regards,
Sybrand Bakker, Oracle DBA
"jim shorts" <jim.short_at_byteme.com> wrote in message
news:39535DE8.AFFE842C_at_byteme.com...
> I have an application that is updating a very large Oracle 7.3.4
> database. at the end of the application are some insert statements that
> affect about 100K rows of data. i've tested the statements and I'm sure
> they complete successfully. I'm trying to find out if their is a clause
> I can add to the insert statements that will bypass the rollback
> segments and just update the database. For example:
> insert into tablename (col1, col2, col3) values (data, data+1, data)
> norollback;
>
> any input would be greatly appreciated. thanks.
>
Received on Fri Jun 23 2000 - 00:00:00 CDT