Re: raw space vs unix filesystem

From: <dfly_at_infinet.com>
Date: 1996/08/06
Message-ID: <4u8urk$24u_at_Darkstar.siberia.ru>#1/1


In article <320263D2.64DB_at_teldta.com>, Brian P. Mac Lean <brian.maclean_at_teldta.com> wrote:
}
} - is this true ?
}
} Yes. In all tuning books I have read including Oracle's it suggests
} using raw devices. I have also done some timings on a Sun Sparc 1000
} with Solaris 2.3 using a Sparc Array via Oracle 7.1.3. I mixed and matched
} configurations to include different levels of raid and raw/UFS. In
} short, the best was raid 0+1 (striping+mirroring). But as always,
} test your configuration and select the best solution.
}
} - Advantages of raw-devices against files ?
}
} No more overhead of the system cache (remember to lower the UNIX
} system cache value, a large one is not necessary anymore).
}
} I/O is direct and therefor faster. The work that UNIX must do to
} maintain the file system (UFS) is gone.
}
} Most UNIX file systems like to reserve 10% of any space for overhead,
} fragmentation, i-nodes, etc. (or something like that) leaving only
} 90% usable. With raw devices the entire partition, all 100% is
} available for Oracle tablespace datafiles.
}
} - which conditions have to be done for raw-devices ?
}
} I'm not sure what you mean hear. How about this, all parts of the
} db can be raw including the redo logs (I have not tried this but
} it's supposed to be do-able) excluding the archive area.
}
} - raw-devices pitfalls ?
}
} must use the UNIX 'dd' command or something at the device level to
} do backups. No more cp/compress/tar/etc.
}
} You must brown nose the system administrator so they will do the
} disk partition for you.

How about crash recovery?
Unix journal filesystems are very reliable and fault-tolerant.
Is it the case with Oracle using raw devices?

Serge

}
} - practical experiences ?
}
} I have had positive experiences with raw devices for the last 5 years
} on 5-10g databases.
}
} Hopefully you will find this helpful.
}
} brian.maclean_at_teldta.com
}
} (not responsible for lost or stolen data)
}
} , ,
} /( )`
} \ \___ / |
} /- _ `-/ '
} (/\/ \ \ /\
} / / | ` \
} O O ) / |
} `-^--'`< '
} TM (_.) _ ) /
} | | |\ | ~|~ \ / `.___/` /
} | | | \ | | X `-----' /
} `__| | \| _|_ / \ <----. __ / __ \
} <----|====O)))==) \) /====
} <----' `--' `.__,' \
} | |
} \ /
} ______( (_ / \______
} ,' ,-----' | \
} `--{__________) \/
Received on Tue Aug 06 1996 - 00:00:00 CEST

Original text of this message