this feature is applicable only to normal or high redundancy and not external redundancy :(. On Mon, Aug 18, 2014 at 4:11 AM, K Gopalakrishnan <kaygopal@xxxxxxxxx> wrote: > All-- > > Starting from 12.1 , ASM "Even Read" feature automatically sends the read > request to least loaded disk groups. So if the OP's objective is to > distribute evenly , then the functionality is already in the kernel. > > -Gopal > > > > > On Sun, Aug 17, 2014 at 7:43 PM, Mark W. Farnham <mwf@xxxxxxxx> wrote: > >> yeah, ping ponging online redo groups was standard operating procedure >> back in the day. >> >> >> >> I think the person asking has members on disks with dramatically >> differing loads, so he wants arch to use the member on the less busy drive. >> >> >> >> *From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto: >> oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Jeremiah Wilton >> *Sent:* Sunday, August 17, 2014 4:12 PM >> *To:* Mark W. Farnham; xiangdongzou@xxxxxxxxx; 'agonenil'; 'ORACLE-L' >> >> *Subject:* RE: Optimized redo log access >> >> >> >> Amihay pointed out that I probably meant group instead of member. >> >> >> >> >> >> JW >> >> >> >> >> >> Sent from my Verizon Wireless 4G LTE smartphone >> >> >> >> -------- Original message -------- >> >> From: Jeremiah Wilton >> >> Date:08/17/2014 12:19 PM (GMT-08:00) >> >> To: "Mark W. Farnham" , xiangdongzou@xxxxxxxxx, 'agonenil' , 'ORACLE-L' >> >> Subject: RE: Optimized redo log access >> >> >> >> Back when it mattered which disk device we accessed for a specific >> operation, this was pretty easy to achieve. >> >> >> >> You just alternate disk(s) by member. For instance, if you have two >> dedicated disks for online logs, member 1 would be on disk A and member 2 >> on disk B. That way when we switch from member 1 to member 2, the archiver >> reads from disk 1 while we write to the online log on disk 2. You can see >> easily how we could even do this and keep multiplexing with 4 disks. >> >> >> >> I doubt that you get much benefit trying to do this kind of thing on >> modern storage. >> >> >> >> Jeremiah >> >> >> >> Sent from my Verizon Wireless 4G LTE smartphone >> >> >> >> -------- Original message -------- >> >> From: "Mark W. Farnham" >> >> Date:08/17/2014 6:13 AM (GMT-08:00) >> >> To: xiangdongzou@xxxxxxxxx, 'agonenil' , 'ORACLE-L' >> >> Subject: RE: Optimized redo log access >> >> >> >> I also do not know a way to make the archiver read a preferred member. >> >> However, you may be able to get the read from a preferred physical disk >> depending on your volume manager. >> >> In ASM this would be by setting (or your preference being the default) >> the asm preferred read failure group as shown in this example from the >> manual so that your preferred read is the first one: >> >> alter system set asm_preferred_read_failure_groups = >> 'DG2.DG2_0000','DG3.DG3_0000' >> >> In some other volume managers there are possibilities for influencing or >> controlling the preferred read of a volume constructed from plexes on >> different physical media. >> >> The starting point recommendation for multiple members is they should be >> on media of similar capabilities and load, so the archiver (unless they >> slipped it in when I wasn’t paying attention) does not directly have a >> toggle for preference by member.) >> >> Good luck. (Of course feeding arch is the reason some folks put redo on >> SSD, while benchmarkers run around “debunking” the idea of redo on SSD >> because they can show it does not speed up writes to compared to isolated >> physical HD volumes when they compare to flash SSD [not battery backed DRAM >> SSD] with arch turned off.) Removing arch reads from your diskfarm by >> relocating redo to SSD will in fact “deheat” your disk farm and remove the >> competition for seeks for writes and bandwidth for arch reads. Since redo >> is usually small relative to the database disk farm, this may be cost >> effective, depending on your situation. >> >> mwf >> >> *From:* oracle-l-bounce@xxxxxxxxxxxxx [ >> mailto:oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx>] *On >> Behalf Of *xiangdongzou >> *Sent:* Sunday, August 17, 2014 5:27 AM >> *To:* agonenil; ORACLE-L >> *Subject:* 回复: Optimized redo log access >> >> >> >> archiver process can't read only special member.Oracle decicde which >> >> member shoulde read. >> >> >> >> 2014-08-17 >> ------------------------------ >> >> *I AM AN ORACLE FANS!* >> >> *Skype:Frank.oracle* >> >> *Email:xiangdongzou@xxxxxxxxx <Email%3Axiangdongzou@xxxxxxxxx>* >> ------------------------------ >> >> *发件人:*amihay gonen <agonenil@xxxxxxxxx> >> >> *发送时间:*2014-08-17 16:51 >> >> *主题:*Optimized redo log access >> >> *收件人:*"ORACLE-L"<oracle-l@xxxxxxxxxxxxx> >> >> *抄送:* >> >> >> >> Hi , I've system that have multiplex redo log (2 members per group) and >> multiplex destinations . >> >> >> >> Due to performance consideration I would like to configuration the >> archiver process to read only from one member (to reduce load on the >> specific device). >> >> >> >> I'm not aware of such option to tell oracle which member to read . >> >> Does anyone know if it is possible ? >> >> >> >> Amihay . >> >> >> >> >> > >