RE: RAMDISK redo, was: Please a parameter to disable undo, like_disable_logging

Excellent point, Carel-Jan,

Consider Platypus's QikDATA: If, after testing like Carel-Jan on a just for fun basis, you calculate the speed increase would justify about $16,000 USD and if you can fit your online logs in 2GB. Lose power? No problem. On board batteries are sufficient to make independent copies of the entire contents of the RAM to separate on board disk drives. (I don't work for them.) Of course pci bus speed is a tad slower than actual RAM, but not much in the context versus spinning rust, and you don't pollute your array cache. Since there is no physical seek, there is very little degradation when ARCH comes to visit as long as you're under the pci bus rate, so you don't have to ping pong logs. If do exceed your bus rate, I guess you need another separate card and another pci bus controller. This is just one example hunk of hardware, I think Imperial makes some too. They may have scsi interfaces by now, too. If you're in this ballpark of redo processing requirement it is definitely worth a look. If rate of writing redo is *not* your pacing component and if cache pollution from writing redo is *not* significant, then things are unlikely to get faster when you try the test Carel-Jan has suggested. And unless you're memory constrained to begin with, so that allocating ramdisk causes significant additional paging/swapping issues, the test is pretty cheap and pretty pure.

One thing that may be masked is if you currently have bad queries that are overdriving your array cache, things may speed up by allowing more of the repeatedly read objects to stay in cache (since the redo stream is no longer writing through array cache.) That is the only false positive I've detected so far with this test. (False positive meaning the system got faster from adding ramdisk for redo, but writing redo was not really the pacing item.) As usual, if you can find and improve the SQL or plans in that case cheaper than buying the SSD, it is a better solution.

The other detail is that if you really want to avoid array cache pollution, then you dedicate a non-array-cache mirrored pair or stripeset of disk drives to receiving the data from ARCH. Then your burst capcity for redo is the speed and size of the ramdisk and your maximum sustained rate of redo is the single user write rate to the pair of drives (minus a bit for reduction to two-user rate when you're running tape jobs or copies to offsite disk from the online arch area. Two user seek collisions for large sequential reads competing with large sequential writes tend to be mitigated by the cache on each drive. If you're spinning up a whole farm of tape drives to run off your archive area, then you'll likely overdrive the i/o model this analysis relies on for the duration of the tape sessions, so the amount of on-line redo you have would need to handle that problem or else your sustained rate during the tape jobs will degrade to the multiuser high collision rate at which ARCH can write.) The other plausible solution to this problem is to ping-pong the ARCH destination, so that the archive location to which you apply your tape farm is read only when the tapes are reading.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Carel-Jan Engel Sent: Wednesday, October 06, 2004 8:43 AM To: oracle-l_at_freelists.org
Subject: RAMDISK redo, was: Please a parameter to disable undo, like_disable_logging

NOTE: I _KNOW_ what the risks are.
Just for fun, I created a ramdisk on Linux, and put my online redologs there. They are copied there on system startup by an rc-script. A graceful system shutdown saves them back to HDD just before the powershut.

Not exactly what you asked for, but speeding things up quite well. I must give the credit of this to Casey Dyke, who put his redo on /tmp on Solaris some day, to speed up a huge load. tmp on Solaris is more or less ramdisk. He posted about this here. It's quite easy on linux as well. Tweak your boot parameters a little, to create ramdisk devices that are big enough, create the filesystem, mount and there you go.

By the way, this is some form of backing up your online redologs ;-)

Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===
On Wed, 2004-10-06 at 01:18, Juan Carlos Reyes Pacheco wrote:

> Hi, I searched but I didn't find it, please do you know some parameter
like
> _disable_logging (disables logging),
> to disable undo.
>
> SELECT KSPPINM, KSPPSTVL
> FROM X$KSPPI A, X$KSPPSV B
> WHERE A.INDX=B.INDX AND SUBSTR(KSPPINM,1,1) = '_'
> and upper(KSPPINM) like '%UNDO%' ;
>
> This is only to speed my test database, thanks.
>
> Juan Carlos Reyes Pacheco
> OCP
> --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l