Re: Lots and lots of redo logs
I guess this test was in response to a claim that 'you have to put your log files on the inner/outer/middle section of the disc for best response time.' I think this demonstrates that there are never any easy answers - and rarely any conclusive tests other than real-life. One thing you might want to check is whether the average 'redo write size' increases as the writes move through the redo logs (in the second case). You MIGHT be demonstrating that the original hypothesis is true, you MIGHT be demonstrating that in this case LGWR becomes self-balancing - as the disc access speed increases because it buffers more data and does bigger writes, so that the slower seek time is hidden by a side-effect of a larger write. BTW - this is not a fair test of normal OLTP activity - some experiments I've been doing recently suggest that inside a PL/SQL loop the COMMIT does not cause a log file sync - if you check your redo synch writes and redo writes statistics, you may find that redo synch writes is extremely small (possibly 1, possibly 1 per log file) and you redo writes will almost certainly be less than the 15,000,000 commits you issued. I'm still working on the 'commit is not a sync' thing, but it really does seem that in pl/sql a 'commit is complete' BEFORE lgwr has written to disc. Jonathan Lewis http://www.jlcomp.demon.co.uk Host to The Co-Operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html Author of: Practical Oracle 8i: Building Efficient Databases Screen saver or Life saver: http://www.ud.com Use spare CPU to assist in cancer research. -Original Message- To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Date: 18 September 2001 23:11 | |Out of curiosity and as a test I scrubbed my 16Mb RAID1 array and set it up |again with 5 x 50Mb redo groups. I ran the following script to generate |lots of redo: | |begin | for i in 1..1500 loop | insert into test_table values (mod(i,10)); | delete from test_table where anumber = (mod(i+1,10)); | commit; | end loop; |end; | |ARCHIVELOG mode was on and the archive destination (on another disk) was |initially empty. |There were 239 log switches and the test completed in 2 hours 56 minutes. | |I then added a further 250 50Mb redo groups, cleared the archive |destination and ran the test again. Again it completed in exactly 2 hours |56 minutes, this time 240 log switches (difference of 1, I guess due to |whereabouts in the first log it was when the test started). | |v$session_wait shows permanent log file parallel write for LGWR while the |test runs. | |Any suggestions why I failed to see any slow down when I (almost) filled |the disk with redo groups? (This server wasn't doing anything else and the |time of the test). The RAID1 array had a Linux ext2 filesystem on it and I |had disabled the write cache. | -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
BTW - this is not a fair test of normal OLTP activity - some experiments I've been doing recently suggest that inside a PL/SQL loop the COMMIT does not cause a log file sync - if you check your redo synch writes and redo writes statistics, you may find that redo synch writes is extremely small (possibly 1, possibly 1 per log file) and you redo writes will almost certainly be less than the 15,000,000 commits you issued. I'm still working on the 'commit is not a sync' thing, but it really does seem that in pl/sql a 'commit is complete' BEFORE lgwr has written to disc. Jonathan, please, keep us in touch with the results (if any) Regards, Ed -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Shevtsov, Eduard INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
Out of curiosity and as a test I scrubbed my 16Mb RAID1 array and set it up again with 5 x 50Mb redo groups. I ran the following script to generate lots of redo: begin for i in 1..1500 loop insert into test_table values (mod(i,10)); delete from test_table where anumber = (mod(i+1,10)); commit; end loop; end; ARCHIVELOG mode was on and the archive destination (on another disk) was initially empty. There were 239 log switches and the test completed in 2 hours 56 minutes. I then added a further 250 50Mb redo groups, cleared the archive destination and ran the test again. Again it completed in exactly 2 hours 56 minutes, this time 240 log switches (difference of 1, I guess due to whereabouts in the first log it was when the test started). v$session_wait shows permanent log file parallel write for LGWR while the test runs. Any suggestions why I failed to see any slow down when I (almost) filled the disk with redo groups? (This server wasn't doing anything else and the time of the test). The RAID1 array had a Linux ext2 filesystem on it and I had disabled the write cache. Thanks again, - Bill. At 08:40 14/09/01 -0800, you wrote: !! Please do not post Off Topic to this List !! Generally IDE shows this problem much more than scsi, but on IDE you can see as much as 50% performance degrading, I haven't really tested the difference. If you put the logs on, then fill the rests of the disks with a empty file of that size, you can make sure that the end of the disk is filled with junk and the logs will never pull blocks from that area. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 12:15 PM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! How big a performance issue is the location of the log file on disk? Even if I create the minimum of 2 archive log groups, how can I be sure the controller hasn't put these on the outer platters anyway? Since these are log files then the writes will be sequential anyway (does that make a difference?) - showing my hardware ignorance here! As you said: But in my opinion here is my priorities. 1. Recoverability 2. Performance I would have thought that having lots of archive log groups (normally) not overwritten for a few days in addition to properly archived logs would boost my recoverability with negligible impact on performance. (Incidentally the MAXLOGFILES maximum value is 255, on Linux anyway). Thanks - Bill. At 07:10 14/09/01 -0800, you wrote: !! Please do not post Off Topic to this List !! It is very common for people to see all that free space and want to fill it. Avoid the desire, fill it with a blank file. Disks are cheap and if you store things on the outer platters performance will suffer. Redo logs and other things in oracle waste disk space as drives get bigger, it is unavoidable. But using the space for something totally defeats the purpose of good configurations. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 10:35 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Hi Thanks. That's a very good point. I agree that ARCHIVELOG mode will be needed. However, I still have this big disk just for redo logs, so I'm tempted to fill it anyway. This will be a sort of supplementary backup in case the archive disk (+ database disks) crash before the backup. Of course it is only sort of because, as you say, a runaway process will cycle the logs if it generates lots of redo. However, this seems better use of the disk space than just having a few log groups and leaving the rest of the array empty and unused. Unless there are any other implications? Thanks - Bill. Hi Yes you can untill the day that you have this runaway process that creates 20Gb of redo and than crashes your database 5 minutes before the daily offline backup should kick in. But you are only mirroring, why not put your database in archivelogmode. You do not have so much redo per day that your disks/archiver can't handle it. Now if your archive directory is full oracle won't crash, but just stop untill you free up some space (I believe this is the behaviour anyway). Jack -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan
Re: Lots and lots of redo logs
Bill Buchan wrote: Out of curiosity and as a test I scrubbed my 16Mb RAID1 array and set it up again with 5 x 50Mb redo groups. I ran the following script to generate lots of redo: begin for i in 1..1500 loop insert into test_table values (mod(i,10)); delete from test_table where anumber = (mod(i+1,10)); commit; end loop; end; ARCHIVELOG mode was on and the archive destination (on another disk) was initially empty. There were 239 log switches and the test completed in 2 hours 56 minutes. I then added a further 250 50Mb redo groups, cleared the archive destination and ran the test again. Again it completed in exactly 2 hours 56 minutes, this time 240 log switches (difference of 1, I guess due to whereabouts in the first log it was when the test started). v$session_wait shows permanent log file parallel write for LGWR while the test runs. Any suggestions why I failed to see any slow down when I (almost) filled the disk with redo groups? (This server wasn't doing anything else and the time of the test). The RAID1 array had a Linux ext2 filesystem on it and I had disabled the write cache. Thanks again, - Bill. Bill, Is there any chance that you had the following: - dictionary-managed USERS tablespace with small extent size (lots of recursize SQL) - RBS, SYSTEM, USERS datafiles on same storage volume - indexes on test_table, with INDEXES on same storage - log_buffer at default value of 32K (or some other small value) It seems likely that the bottleneck was not in the LGWR process. As others here would likely indicate, what were the other I/O-related v$system_event waits? Since I don't see version info, is it possible that you do not have a dedicated CKPT process? Paul -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Paul Drake INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! Hi Yes you can untill the day that you have this runaway process that creates 20Gb of redo and than crashes your database 5 minutes before the daily offline backup should kick in. But you are only mirroring, why not put your database in archivelogmode. You do not have so much redo per day that your disks/archiver can't handle it. Now if your archive directory is full oracle won't crash, but just stop untill you free up some space (I believe this is the behaviour anyway). Jack Bill Buchan [EMAIL PROTECTED]@fatcity.com on 14-09-2001 15:20:18 Please respond to [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] cc:(bcc: Jack van Zanen/nlzanen1/External/MEY/NL) !! Please do not post Off Topic to this List !! I am planning setting up a new database with the redo logs on RAID 1 array (mirror). The amount of space available on the array is 16Gb and only the redo logs will be on there. The application will generate 2Gb of redo per day and will be backed up (cold) each night to tape. If I set up enough groups (MAXLOGFILES) such that the whole array is full of logs (each probably 50Mb in size) can I safely run this in NOARCHIVELOG mode and still expect ARCHIVELOG mode type complete recovery? The application will not overwrite a log till several days (and several backups) after it was last used, and the logs are protected by RAID. Recovery requirement is only to be able to get back to the current state (say that last 24 hours max.) before failure, not recover way back in time. Are there any other issues (eg. performance) that I should consider? Any comments much appreciated. Thanks - Bill. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). = De informatie verzonden in dit e-mailbericht is vertrouwelijk en is uitsluitend bestemd voor de geadresseerde. Openbaarmaking, vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan derden is, behoudens voorafgaande schriftelijke toestemming van Ernst Young, niet toegestaan. Ernst Young staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden e-mailbericht, noch voor tijdige ontvangst daarvan. Ernst Young kan niet garanderen dat een verzonden e-mailbericht vrij is van virussen, noch dat e-mailberichten worden overgebracht zonder inbreuk of tussenkomst van onbevoegde derden. Indien bovenstaand e-mailbericht niet aan u is gericht, verzoeken wij u vriendelijk doch dringend het e-mailbericht te retourneren aan de verzender en het origineel en eventuele kopieën te verwijderen en te vernietigen. Ernst Young hanteert bij de uitoefening van haar werkzaamheden algemene voorwaarden, waarin een beperking van aansprakelijkheid is opgenomen. De algemene voorwaarden worden u op verzoek kosteloos toegezonden. = The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed. You should not copy, disclose or distribute this communication without the authority of Ernst Young. Ernst Young is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. Ernst Young does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. In carrying out its engagements, Ernst Young applies general terms and conditions, which contain a clause that limits its liability. A copy of these terms and conditions is available on request free of charge. = -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! You can only have a max of 8 log groups if I remember correctly. Yesterday's backup may have failed, and you may have to recover from the day prior or prior's prior. Keep this in mind as well. With archive log, you can use 6 month old backup, and apply all the logs to become current if for whatever reason all the backups failed and that is all you had. Another thing to keep in mind is if you plan on using log miner, you may want to look through a log file in the past, via archive log. Also keep in mind, DDL and data dictionary costs redo, so your redo usage is almost always more than expected. For example if you have to run initjvml.sql, that generates over 100Mb of redo activity. This under normal cases will spin two of your 50Mb logs. But given these and perhaps other concerns, if your still comfortable, by all means. But in my opinion here is my priorities. 1. Recoverability 2. Performance Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 9:20 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! I am planning setting up a new database with the redo logs on RAID 1 array (mirror). The amount of space available on the array is 16Gb and only the redo logs will be on there. The application will generate 2Gb of redo per day and will be backed up (cold) each night to tape. If I set up enough groups (MAXLOGFILES) such that the whole array is full of logs (each probably 50Mb in size) can I safely run this in NOARCHIVELOG mode and still expect ARCHIVELOG mode type complete recovery? The application will not overwrite a log till several days (and several backups) after it was last used, and the logs are protected by RAID. Recovery requirement is only to be able to get back to the current state (say that last 24 hours max.) before failure, not recover way back in time. Are there any other issues (eg. performance) that I should consider? Any comments much appreciated. Thanks - Bill. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! Hi Thanks. That's a very good point. I agree that ARCHIVELOG mode will be needed. However, I still have this big disk just for redo logs, so I'm tempted to fill it anyway. This will be a sort of supplementary backup in case the archive disk (+ database disks) crash before the backup. Of course it is only sort of because, as you say, a runaway process will cycle the logs if it generates lots of redo. However, this seems better use of the disk space than just having a few log groups and leaving the rest of the array empty and unused. Unless there are any other implications? Thanks - Bill. Hi Yes you can untill the day that you have this runaway process that creates 20Gb of redo and than crashes your database 5 minutes before the daily offline backup should kick in. But you are only mirroring, why not put your database in archivelogmode. You do not have so much redo per day that your disks/archiver can't handle it. Now if your archive directory is full oracle won't crash, but just stop untill you free up some space (I believe this is the behaviour anyway). Jack -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! It is very common for people to see all that free space and want to fill it. Avoid the desire, fill it with a blank file. Disks are cheap and if you store things on the outer platters performance will suffer. Redo logs and other things in oracle waste disk space as drives get bigger, it is unavoidable. But using the space for something totally defeats the purpose of good configurations. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 10:35 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Hi Thanks. That's a very good point. I agree that ARCHIVELOG mode will be needed. However, I still have this big disk just for redo logs, so I'm tempted to fill it anyway. This will be a sort of supplementary backup in case the archive disk (+ database disks) crash before the backup. Of course it is only sort of because, as you say, a runaway process will cycle the logs if it generates lots of redo. However, this seems better use of the disk space than just having a few log groups and leaving the rest of the array empty and unused. Unless there are any other implications? Thanks - Bill. Hi Yes you can untill the day that you have this runaway process that creates 20Gb of redo and than crashes your database 5 minutes before the daily offline backup should kick in. But you are only mirroring, why not put your database in archivelogmode. You do not have so much redo per day that your disks/archiver can't handle it. Now if your archive directory is full oracle won't crash, but just stop untill you free up some space (I believe this is the behaviour anyway). Jack -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: lots and lots of redo logs
!! Please do not post Off Topic to this List !! Christopher R. Spence said: You can only have a max of 8 log groups if I remember correctly. Gee, I thought that the DBA controlled the maximum number of redo logs allowed for a database. There's this thing called a database create statement: (e.g.) CREATE DATABASE DEV LOGFILE 'E:\Oracle\oradata\DEV\redo01.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo02.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo03.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo04.log' SIZE 16384K MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXLOGHISTORY 1 DATAFILE 'F:\Oracle\oradata\EMS\system01.dbf' SIZE 320M REUSE AUTOEXTEND ON NEXT 32768K MAXDATAFILES 128 MAXINSTANCES 1 CHARACTER SET WE8ISO8859P1 NATIONAL CHARACTER SET WE8ISO8859P1; Funny, how reading the documentation or just looking at your create scripts can answer lots of questions before just simply spewing email. Personally, I try to send fewer, higher quality emails rather than dozens of things that are the first thing that pops into my head. Paul -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Paul Drake INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! Generally IDE shows this problem much more than scsi, but on IDE you can see as much as 50% performance degrading, I haven't really tested the difference. If you put the logs on, then fill the rests of the disks with a empty file of that size, you can make sure that the end of the disk is filled with junk and the logs will never pull blocks from that area. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 12:15 PM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! How big a performance issue is the location of the log file on disk? Even if I create the minimum of 2 archive log groups, how can I be sure the controller hasn't put these on the outer platters anyway? Since these are log files then the writes will be sequential anyway (does that make a difference?) - showing my hardware ignorance here! As you said: But in my opinion here is my priorities. 1. Recoverability 2. Performance I would have thought that having lots of archive log groups (normally) not overwritten for a few days in addition to properly archived logs would boost my recoverability with negligible impact on performance. (Incidentally the MAXLOGFILES maximum value is 255, on Linux anyway). Thanks - Bill. At 07:10 14/09/01 -0800, you wrote: !! Please do not post Off Topic to this List !! It is very common for people to see all that free space and want to fill it. Avoid the desire, fill it with a blank file. Disks are cheap and if you store things on the outer platters performance will suffer. Redo logs and other things in oracle waste disk space as drives get bigger, it is unavoidable. But using the space for something totally defeats the purpose of good configurations. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 10:35 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Hi Thanks. That's a very good point. I agree that ARCHIVELOG mode will be needed. However, I still have this big disk just for redo logs, so I'm tempted to fill it anyway. This will be a sort of supplementary backup in case the archive disk (+ database disks) crash before the backup. Of course it is only sort of because, as you say, a runaway process will cycle the logs if it generates lots of redo. However, this seems better use of the disk space than just having a few log groups and leaving the rest of the array empty and unused. Unless there are any other implications? Thanks - Bill. Hi Yes you can untill the day that you have this runaway process that creates 20Gb of redo and than crashes your database 5 minutes before the daily offline backup should kick in. But you are only mirroring, why not put your database in archivelogmode. You do not have so much redo per day that your disks/archiver can't handle it. Now if your archive directory is full oracle won't crash, but just stop untill you free up some space (I believe this is the behaviour anyway). Jack -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! Christopher R. Spence said: Disks are cheap and if you store things on the outer platters performance will suffer? Chris, I'm not sure what you mean here. The concept of Variable Transfer Rate covers this. Stealing a quote from: Optimal Storage Configuration Made Easy, By Juan Loaiza, Oracle Corporation The transfer rate for a disk drive is not the same for all portions of a disk. The outer sectors of a disk drive move by the disk head faster than the inner sections leading to a faster transfer rate for the outer sectors. This is simply because of the circular shape of a disk drive. Scott -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Scott Crabtree INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! How big a performance issue is the location of the log file on disk? Even if I create the minimum of 2 archive log groups, how can I be sure the controller hasn't put these on the outer platters anyway? Since these are log files then the writes will be sequential anyway (does that make a difference?) - showing my hardware ignorance here! As you said: But in my opinion here is my priorities. 1. Recoverability 2. Performance I would have thought that having lots of archive log groups (normally) not overwritten for a few days in addition to properly archived logs would boost my recoverability with negligible impact on performance. (Incidentally the MAXLOGFILES maximum value is 255, on Linux anyway). Thanks - Bill. At 07:10 14/09/01 -0800, you wrote: !! Please do not post Off Topic to this List !! It is very common for people to see all that free space and want to fill it. Avoid the desire, fill it with a blank file. Disks are cheap and if you store things on the outer platters performance will suffer. Redo logs and other things in oracle waste disk space as drives get bigger, it is unavoidable. But using the space for something totally defeats the purpose of good configurations. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 10:35 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Hi Thanks. That's a very good point. I agree that ARCHIVELOG mode will be needed. However, I still have this big disk just for redo logs, so I'm tempted to fill it anyway. This will be a sort of supplementary backup in case the archive disk (+ database disks) crash before the backup. Of course it is only sort of because, as you say, a runaway process will cycle the logs if it generates lots of redo. However, this seems better use of the disk space than just having a few log groups and leaving the rest of the array empty and unused. Unless there are any other implications? Thanks - Bill. Hi Yes you can untill the day that you have this runaway process that creates 20Gb of redo and than crashes your database 5 minutes before the daily offline backup should kick in. But you are only mirroring, why not put your database in archivelogmode. You do not have so much redo per day that your disks/archiver can't handle it. Now if your archive directory is full oracle won't crash, but just stop untill you free up some space (I believe this is the behaviour anyway). Jack -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: lots and lots of redo logs
!! Please do not post Off Topic to this List !! I forgot the word default; I know 8 used to be the default. I tend to be doing many different things when I respond to emails. I guess it would be much easier if I didn't post at all. Not like I ever ask questions on the list. But thanks for your flame, specially the one you sent privately stating you wish me to get kicked off the list the other day. Keep up the good work. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 12:21 PM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Christopher R. Spence said: You can only have a max of 8 log groups if I remember correctly. Gee, I thought that the DBA controlled the maximum number of redo logs allowed for a database. There's this thing called a database create statement: (e.g.) CREATE DATABASE DEV LOGFILE 'E:\Oracle\oradata\DEV\redo01.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo02.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo03.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo04.log' SIZE 16384K MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXLOGHISTORY 1 DATAFILE 'F:\Oracle\oradata\EMS\system01.dbf' SIZE 320M REUSE AUTOEXTEND ON NEXT 32768K MAXDATAFILES 128 MAXINSTANCES 1 CHARACTER SET WE8ISO8859P1 NATIONAL CHARACTER SET WE8ISO8859P1; Funny, how reading the documentation or just looking at your create scripts can answer lots of questions before just simply spewing email. Personally, I try to send fewer, higher quality emails rather than dozens of things that are the first thing that pops into my head. Paul -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Paul Drake INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! AIX has a unique concept of this. Given data spread on a disk. The head will spend more time over the middle tracks as it seeks data that is distributed across the disk. Thus for faster access, place your tablespace on the middle tracks of a disk because the probability that the head will be over it is much greater. Learned this with Syabase on AIX. It may still hold true today. I don't know. Technology had advanced a lot from those day. (But I think the laws of physics are the same ;-)) -Original Message- Sent: Friday, September 14, 2001 10:05 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Christopher R. Spence said: Disks are cheap and if you store things on the outer platters performance will suffer? Chris, I'm not sure what you mean here. The concept of Variable Transfer Rate covers this. Stealing a quote from: Optimal Storage Configuration Made Easy, By Juan Loaiza, Oracle Corporation The transfer rate for a disk drive is not the same for all portions of a disk. The outer sectors of a disk drive move by the disk head faster than the inner sections leading to a faster transfer rate for the outer sectors. This is simply because of the circular shape of a disk drive. Scott -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Scott Crabtree INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: John Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! Excellent. Thanks for the information; maybe I won't fill my whole disk with redo now! - Bill. At 08:40 14/09/01 -0800, you wrote: !! Please do not post Off Topic to this List !! Generally IDE shows this problem much more than scsi, but on IDE you can see as much as 50% performance degrading, I haven't really tested the difference. If you put the logs on, then fill the rests of the disks with a empty file of that size, you can make sure that the end of the disk is filled with junk and the logs will never pull blocks from that area. -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Bill Buchan INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: lots and lots of redo logs
!! Please do not post Off Topic to this List !! I think that Chris was referring to the maximum number of redo log group one COULD create - an Oracle hard limit. I don't know what it is, but I know its not 8 since I have created OPS databases with 12 redo groups for each instance and multiple instances. -Don Granaman [Orasaurus - Honk if you remember UFI!] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, September 14, 2001 11:20 AM !! Please do not post Off Topic to this List !! Christopher R. Spence said: You can only have a max of 8 log groups if I remember correctly. Gee, I thought that the DBA controlled the maximum number of redo logs allowed for a database. There's this thing called a database create statement: (e.g.) CREATE DATABASE DEV LOGFILE 'E:\Oracle\oradata\DEV\redo01.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo02.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo03.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo04.log' SIZE 16384K [...] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Don Granaman INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: lots and lots of redo logs
!! Please do not post Off Topic to this List !! It is default to 8, unless you change it by rebuilding the control file or init.ora, depending on the version. Although 8 is platform dependant. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 2:36 PM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! I think that Chris was referring to the maximum number of redo log group one COULD create - an Oracle hard limit. I don't know what it is, but I know its not 8 since I have created OPS databases with 12 redo groups for each instance and multiple instances. -Don Granaman [Orasaurus - Honk if you remember UFI!] - Original Message - To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Sent: Friday, September 14, 2001 11:20 AM !! Please do not post Off Topic to this List !! Christopher R. Spence said: You can only have a max of 8 log groups if I remember correctly. Gee, I thought that the DBA controlled the maximum number of redo logs allowed for a database. There's this thing called a database create statement: (e.g.) CREATE DATABASE DEV LOGFILE 'E:\Oracle\oradata\DEV\redo01.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo02.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo03.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo04.log' SIZE 16384K [...] -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Don Granaman INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: lots and lots of redo logs
!! Please do not post Off Topic to this List !! Christopher - I for one appreciate your efforts to share your knowledge. I suppose that like most of us you have employment in addition to this list. The best most of us can manage is to jot off a quick reply without benefit of extensive research. The tradeoff as I see it is between the occasional not-quite-complete answer versus many unanswered questions. And if a point is incorrect, there is usually someone that will provide a correction. Keep up the good work! Dennis Williams DBA Lifetouch, Inc. [EMAIL PROTECTED] -Original Message- Sent: Friday, September 14, 2001 12:37 PM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! I forgot the word default; I know 8 used to be the default. I tend to be doing many different things when I respond to emails. I guess it would be much easier if I didn't post at all. Not like I ever ask questions on the list. But thanks for your flame, specially the one you sent privately stating you wish me to get kicked off the list the other day. Keep up the good work. Do not criticize someone until you walked a mile in their shoes, that way when you criticize them, you are a mile a way and have their shoes. Christopher R. Spence Oracle DBA Phone: (978) 322-5744 Fax:(707) 885-2275 Fuelspot 73 Princeton Street North, Chelmsford 01863 -Original Message- Sent: Friday, September 14, 2001 12:21 PM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Christopher R. Spence said: You can only have a max of 8 log groups if I remember correctly. Gee, I thought that the DBA controlled the maximum number of redo logs allowed for a database. There's this thing called a database create statement: (e.g.) CREATE DATABASE DEV LOGFILE 'E:\Oracle\oradata\DEV\redo01.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo02.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo03.log' SIZE 16384K, 'E:\Oracle\oradata\DEV\redo04.log' SIZE 16384K MAXLOGFILES 16 MAXLOGMEMBERS 2 MAXLOGHISTORY 1 DATAFILE 'F:\Oracle\oradata\EMS\system01.dbf' SIZE 320M REUSE AUTOEXTEND ON NEXT 32768K MAXDATAFILES 128 MAXINSTANCES 1 CHARACTER SET WE8ISO8859P1 NATIONAL CHARACTER SET WE8ISO8859P1; Funny, how reading the documentation or just looking at your create scripts can answer lots of questions before just simply spewing email. Personally, I try to send fewer, higher quality emails rather than dozens of things that are the first thing that pops into my head. Paul -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Paul Drake INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Christopher Spence INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
RE: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! I am with John on this - For those with AIX, it is essential that the Logical volume be created first and then the filesystem be created on this LV. It is via this route that you will be able to place this LV in the 'center' (default). I have had great success placing redologs, rbs, temp and system in the 'center' and all other tablespaces on the 'edge'/'middle' when I was 'disk constrained' (read : I had only one 9Gb disk for *all* user/oracle binaries and database :( John Kanagaraj Oracle Applications DBA DB Soft Inc Work : (408) 970 7002 Listen to great, commercial-free christian music 24x7x365 at http://www.klove.com ** The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers ** -Original Message- From: John Lewis [mailto:[EMAIL PROTECTED]] Sent: Friday, September 14, 2001 10:45 AM To: Multiple recipients of list ORACLE-L Subject: RE: Lots and lots of redo logs !! Please do not post Off Topic to this List !! AIX has a unique concept of this. Given data spread on a disk. The head will spend more time over the middle tracks as it seeks data that is distributed across the disk. Thus for faster access, place your tablespace on the middle tracks of a disk because the probability that the head will be over it is much greater. Learned this with Syabase on AIX. It may still hold true today. I don't know. Technology had advanced a lot from those day. (But I think the laws of physics are the same ;-)) -Original Message- Sent: Friday, September 14, 2001 10:05 AM To: Multiple recipients of list ORACLE-L !! Please do not post Off Topic to this List !! Christopher R. Spence said: Disks are cheap and if you store things on the outer platters performance will suffer? Chris, I'm not sure what you mean here. The concept of Variable Transfer Rate covers this. Stealing a quote from: Optimal Storage Configuration Made Easy, By Juan Loaiza, Oracle Corporation The transfer rate for a disk drive is not the same for all portions of a disk. The outer sectors of a disk drive move by the disk head faster than the inner sections leading to a faster transfer rate for the outer sectors. This is simply because of the circular shape of a disk drive. Scott -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Scott Crabtree INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: John Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
Re: Lots and lots of redo logs
!! Please do not post Off Topic to this List !! I love it when people explain their hypotheses - it makes it so much easier to understand why two people can apparently contradict each other and still be right. Presumably the argument for putting the data at the outside edge (could still be) correct once you've decided that you're only going to use a quarter of the disc space anyway. Jonathan Lewis http://www.jlcomp.demon.co.uk Host to The Co-Operative Oracle Users' FAQ http://www.jlcomp.demon.co.uk/faq/ind_faq.html Author of: Practical Oracle 8i: Building Efficient Databases Screen saver or Life saver: http://www.ud.com Use spare CPU to assist in cancer research. -Original Message- To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED] Date: 14 September 2001 18:43 |!! Please do not post Off Topic to this List !! | |AIX has a unique concept of this. | |Given data spread on a disk. The head will spend more time over the | middle tracks as it seeks data that is distributed across the disk. | |Thus for faster access, place your tablespace on the middle tracks |of a disk because the probability that the head will be over it is |much greater. | |Learned this with Syabase on AIX. It may still hold true today. |I don't know. Technology had advanced a lot from those day. (But I think the |laws of physics are the same ;-)) | |-Original Message- |Sent: Friday, September 14, 2001 10:05 AM |To: Multiple recipients of list ORACLE-L | | |!! Please do not post Off Topic to this List !! | |Stealing a quote from: Optimal Storage Configuration Made Easy, |By Juan Loaiza, Oracle Corporation | |The transfer rate for a disk drive is not the same for all portions of a |disk. |The outer sectors of a disk drive move by the disk head faster than the |inner sections |leading to a faster transfer rate for the outer sectors. This is simply |because |of the circular shape of a disk drive. | -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jonathan Lewis INET: [EMAIL PROTECTED] Fat City Network Services-- (858) 538-5051 FAX: (858) 538-5051 San Diego, California-- Public Internet access / Mailing Lists To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
