>> 1. My understanding of the situation is having a zpool on a single LUN precludes some ZFS technology such as self-healing, hence is not best practice. Right?
>For important data and when you have only one LUN (eg. arrays) using copies is a way to manage your redundancy policies for each file system. In general, we like to see ZFS have the ability to repair data. I'm not sure what you mean by copies. ZFS snapshots? Clones? >> 3. Suggestions for zpool, zfs file system layout >Follow the procedures for databases on ZFS at: http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide Yeah, I read that. Thanks. I'm assuming he means something like: zfs create -o recsize=8k -o mountpoint=/ora01 san01/ora01 >Prior to Solaris 10u5 (spring '08?) you will want to put your Oracle redo log on a separate storage pool, preferrably on the fastest storage. But if you follow this advice, then I wouldn't try to mirror the redo log pool with a slow device because it is a write-mostly workload and will be sensitive to the latency of commits to both sides of the mirror. I eventually decided mirroring fast storage to slow was a stupid idea. Does the redo log filesystem need the same recsize as the filesystem ORACLE tables themselves? I thought they were more of a flat file. >NB since you only have one LUN, the performance won't be great anyway. Or to put this in perspective, competitive TPC-C benchmarks consume thousands of LUNs. In that case, you might consider investing in memory for a larger SGA. I would have assumed the SAN would be the bottleneck on this. Would having the SAN publish more LUNs buy me anything in terms of overall performance? Wouldn't the SAN be spinning its hamster wheel faster trying to deliver the data over multiple LUNs vs. one, losing us any performance gain on the ZFS end? This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
