Thanks to: Rick Waegner Christophe Dupre Wade.Stuart Kevin Buterbaugh John Eisenschmidt for replies. The consencious is memory allocation will not be reduced by the SAN. CPU cycles should be reduced, more so if I were running software RAID or SDS to manage disks. For those wondering about the validity of my question, I was reaching. I've talked myself blue trying to get budget for RAID for data survivability and redundancy reasons and a SAN for reduced management and growth. I was looking for one more line item in the improved performance catagory. Anyone that has been in my spot trying to get a budget aproved for a SAN that would be several times more expensive than the server that attaches to it and wants to share comments oro suggestions, I'm all ears. As always, thanks to everyone for being a fantastic resource. Kevin Metzger Systems Administrator Progressive Medical, Inc. ---------- Forwarded message ---------- Date: Mon, 1 Jul 2002 17:16:12 -0400 (EDT) From: Kevin Metzger <kevin@pmimail.com> Reply-To: Kevin Metzger <kevin.metzger@ieee.org> To: sunmanagers mailing list <sunmanagers@sunmanagers.org> Subject: memory size for disk management In an effort to justify a SAN, I would like to quantify the amount of memory the system is dedicating to disk IO. It is a 220R running Solaris 8 and Oracle. Our database memory allocation is already greater than the 2G that is installed and I'm hoping to make the case that something like a EMC FC4700 would extend the usable life of the server(s) attached since their load would no longer include managing disks. Any methods or suggestions are welcome. Kevin Metzger Systems Administrator Progressive Medical, Inc. _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagers _______________________________________________ sunmanagers mailing list sunmanagers@sunmanagers.org http://www.sunmanagers.org/mailman/listinfo/sunmanagersReceived on Tue Jul 9 09:48:57 2002
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:48 EST