Checkpoints
in [Oracle]
|
Prev: install Oracle Fusion Middleware 11g meet http 400 error
Next: Force drop of UNDO tablespace (with online segment) in 9.2.0.8?
From: Srivenu Kadiyala on 2 Oct 2009 16:10 I would go for atleast 500MB to give more breathing space for dbwr to checkpoint before the next log switch. Also whats the value of FAST_START_MTTR_TARGET? On several of the servers (10.2.0.4 on HP) i see that the parameter does not work as seemlessly as is specified in the doc. If i'm in your shoes, I would first set my log files to atleast 512 MB and if still facing the checkpoint issue, would start tinkering with FAST_START_MTTR_TARGET. regards srivenu
From: joel garry on 2 Oct 2009 16:25 On Oct 2, 1:10 pm, Srivenu Kadiyala <sriv...(a)hotmail.com> wrote: > I would go for atleast 500MB to give more breathing space for dbwr to > checkpoint before the next log switch. > Also whats the value of FAST_START_MTTR_TARGET? > On several of the servers (10.2.0.4 on HP) i see that the parameter > does not work as seemlessly as is specified in the doc. > If i'm in your shoes, I would first set my log files to atleast 512 MB > and if still facing the checkpoint issue, would start tinkering with > FAST_START_MTTR_TARGET. > regards > srivenu Rather than just pulling values out of your, um, hat, why not look at optimal_logfile_size from v$instance_recovery? See metalink Note: 274264.1 or the performance tuning guide. jg -- @home.com is bogus. Who is Diego and why is he flipping off Oracle aces off the coast of Africa? Hi, I'd like to share a Google Maps link with you. Link: http://maps.google.com/maps/ms?ie=UTF8&hl=en&om=1&source=embed&oe=UTF8&start=400&num=100&msa=0&msid=101461418394975592073.000439f71111bb8cdc3b5&ll=3.162456,-22.939453&spn=58.230056,79.013672&z=4
From: joel garry on 5 Oct 2009 14:12 On Oct 5, 10:02 am, Srivenu Kadiyala <sriv...(a)hotmail.com> wrote: > My suggestions were based on the data provided. > The redo generation around 5GB per hour during peak. So a 512 MB redo > log would cause a switch every 6 mins during peak. > FAST_START_MTTR_TARGET could be set at 120-180. > Monitoring stats like "physical writes" and "physical writes non > checkpoint" before and after the change should give an idea of the > extra checkpoint load put on the system due to this change. > regards > srivenu The information provided does not say that 5GB per hour is evenly spread across the hour. I still don't understand why you wouldn't simply start with the advisor. I'd add that scripts found randomly on the intertubes may be suspect. Wouldn't you want to use a script with a granularity of 6 minutes if you were aiming for that? Frankly, I was surprised at how accurate the advisor was for my system. jg -- @home.com is bogus. 2005: HP's Carly Fiorini folds struggling PC unit into profitable printer unit. HP board fired Carly, hired Mark Hurd, who separated the two units. PC unit slashed costs, became more efficient. Now, printer business is most profitable, but not keeping up with rest of HP's profitability. So now Hurd is combining the two units. In HP's fiscal quarter ended July 31, PCs produced $8.43 billion in revenue and $386 million in earnings, and accounted for 12 percent of HP's profits. Printer and ink generated revenue of $5.66 billion and $960 million in earnings, for 30 percent of overall profits. In 2004, printers and ink accounted for more than 70 percent of HP profits, while PCs were less than 5 percent. I don't understand how the PC business is the same as the printer business, and why a lower profitability unit should be in charge of a higher profitability unit, so I guess I'll never be running HP.
From: Srivenu Kadiyala on 5 Oct 2009 13:02
My suggestions were based on the data provided. The redo generation around 5GB per hour during peak. So a 512 MB redo log would cause a switch every 6 mins during peak. FAST_START_MTTR_TARGET could be set at 120-180. Monitoring stats like "physical writes" and "physical writes non checkpoint" before and after the change should give an idea of the extra checkpoint load put on the system due to this change. regards srivenu |