Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Oracle / Oracle Server / December 2005

Tip: Looking for answers? Try searching our database.

Log switch during import

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Gerard Lacroix - 29 Dec 2005 16:53 GMT
Hi.
Sorry for another newbie question.
The log switches were too frequent during normal operation, so I
resized my redo files from 30 M to 100 M each (three groups).
Everything worked fine then, but during a 1 million rows import, the
time between switches went down to 1 minute, even less sometimes.
I know the log switches should occur more frequently during the import,
but isn't it to low ?
Should I change the redo configuration before this kind of tasks ?

Thanks.

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
PL/SQL Release 9.2.0.6.0 - Production
CORE    9.2.0.6.0       Production
TNS for 32-bit Windows: Version 9.2.0.6.0 - Production
NLSRTL Version 9.2.0.6.0 - Production
Frank van Bortel - 29 Dec 2005 18:06 GMT
> Hi.
> Sorry for another newbie question.
[quoted text clipped - 15 lines]
> TNS for 32-bit Windows: Version 9.2.0.6.0 - Production
> NLSRTL Version 9.2.0.6.0 - Production

Does it bother you?
Does it cause delays?
Is someone complaining?

A rule-of-thumb is to have one log switch every hour
at normal operations.
Imports are not 'normal' operating conditions, so unless
you can answer one of the questions above with a yes,
I'd say leave it.
Remember, a rule-of-thumb is as valid as the other one.
Signature

Regards,
Frank van Bortel

Top-posting is one way to shut me up...

Mark D Powell - 29 Dec 2005 20:29 GMT
Gerald, in the absence of Oracle Data Guard or other high availability
options that feed off the redo log stream you generally want the total
number of archived redo logs generated per day to be somewhere between
24 to 48 similar to what Frank suggested.  If you ever have to do a
fully manual recovery where you have to feed in each and every log name
you will know one reason why.  But mostly you do not want multiple
checkpoints to overlap, that is, you really do not want a new log
switch and checkpoint to start if the prior checkpoint has not
finished.  Nor do you want to fill all the online redo logs to fill
before the oldest log has been achieved to disk.  Both of these
problems result in warning error messages being written to the alert
log.  If your alter log is clean you are probably Ok with the rapid
switches if the total number of archived redo logs being generated is
not too high and if the number of times per day where you observe this
condition in the alert log is limited.  That is you may need to size
the redo logs based on a peak processing time to prevent the problems
mentioned above even if it results in less total logs than would be
ideal.

HTH -- Mark D Powell --
Frank van Bortel - 30 Dec 2005 08:43 GMT
> you will know one reason why.  But mostly you do not want multiple
> checkpoints to overlap, that is, you really do not want a new log
[quoted text clipped - 3 lines]
> problems result in warning error messages being written to the alert
> log.  

Right! Forgot to point that out.

Very important stuff! Check for
"Checkpoint not complete"
in your alert log file (alert[SID].log).

If you find any of these, you most certainly want to
increase the size of your redo logs, or create more
log members.
Signature

Regards,
Frank van Bortel

Top-posting is one way to shut me up...

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.