ไม่ต้องสนใจซานนั่นหลังม่าน

กาลครั้งหนึ่งฉันสร้างเซิร์ฟเวอร์ SQL ของตัวเองและควบคุมการกำหนดค่าไดรฟ์ระดับ RAID ฯลฯ คำแนะนำแบบดั้งเดิมของการแยกข้อมูลบันทึก tempdb สำรองข้อมูล (ขึ้นอยู่กับงบประมาณ!) เป็นส่วนที่สำคัญ ของกระบวนการออกแบบเซิร์ฟเวอร์ SQL

ขณะนี้มี SAN ระดับองค์กรฉันขอพื้นที่ไดรฟ์จำนวนหนึ่งสำหรับเซิร์ฟเวอร์ SQL ใหม่โดยแบ่งเป็นไดรฟ์แบบลอจิคัลสำหรับข้อมูลการสำรองข้อมูลและแชร์ไฟล์ แน่นอนว่าทำให้งานของฉันง่ายขึ้น แต่มีบางส่วนของฉันที่รู้สึกไม่สบายอย่างสมบูรณ์ที่ฉันไม่สามารถมอง "หลังม่าน" เพื่อดูว่าเกิดอะไรขึ้นที่นั่น

ความเข้าใจของฉันคือทีม SAN ไม่ได้กำหนดค่า "ประเภท" ของไดรฟ์ที่แตกต่างกัน (ปรับแต่งไดรฟ์ข้อมูลสำหรับการเข้าถึงแบบสุ่มเทียบกับไดรฟ์บันทึกสำหรับการเขียนแบบสตรีม) บางอย่างอาจขึ้นอยู่กับผลิตภัณฑ์ SAN (เรามี HP XP12000 และ HP XP24000) แต่ฉันมั่นใจแล้วว่าซอฟต์แวร์ HP ทำการตั้งค่าประสิทธิภาพแบบไดนามิกทุกประเภท (ดูฮอตสปอต IO และตั้งค่าใหม่ได้ทันทีเพื่อ เพิ่มประสิทธิภาพ LUN เหล่านั้น) เพื่อให้ทีมแอปและ DBA ไม่จำเป็นต้องกังวลเกี่ยวกับสิ่งใด ๆ มีบางอย่างเกี่ยวกับ "การแพร่กระจายภาระของเซิร์ฟเวอร์ทั้งหมดไปยังแกนหมุนจำนวนมาก" หรืออะไรทำนองนั้น

คำถาม / การอภิปรายของฉัน:

1. หากไม่มีศัตรูในทีม SAN ฉันจะมั่นใจได้อย่างไรกับนักพัฒนาแอปพลิเคชันว่าเซิร์ฟเวอร์ SQL ของเราไม่ได้รับความทุกข์ทรมานจากการจัดเก็บที่ไม่ดี เพียงใช้สถิติ perfmon? มาตรฐานอื่น ๆ เช่น sqlio?

2. ถ้าฉันโหลดการทดสอบกับไดรฟ์ SAN เหล่านี้นั่นจะทำให้ฉันมีความน่าเชื่อถือและวัดซ้ำได้จริง ๆ ว่าฉันจะเห็นอะไรเมื่อเราใช้งานจริง (สมมติว่าซอฟต์แวร์ SAN อาจ "กำหนดค่าแบบไดนามิก" แตกต่างกันตามเวลาต่างกัน)

3. IO หนักในส่วนหนึ่งของ SAN (พูดกับเซิร์ฟเวอร์ Exchange) ส่งผลต่อเซิร์ฟเวอร์ SQL ของฉันหรือไม่ (สมมติว่าพวกเขาไม่ได้ให้ดิสก์เฉพาะกับเซิร์ฟเวอร์แต่ละตัวซึ่งฉันบอกว่าไม่ได้)

4. จะขอแยกไดรฟ์แบบลอจิคัลสำหรับไดรฟ์แบบลอจิคัลของฟังก์ชันที่แตกต่างกัน (data vs log vs tempdb) หรือไม่ SAN จะเห็นกิจกรรม IO ที่ต่างกันในสิ่งเหล่านี้และกำหนดค่าให้เหมาะสมที่สุดต่างกันหรือไม่

5. ตอนนี้เรากำลังวุ่นวายกับเรื่องอวกาศ ทีมแอปพลิเคชันได้รับคำสั่งให้ตัดการจัดเก็บข้อมูล ฯลฯ ความกังวลเกี่ยวกับพื้นที่จะทำให้ทีม SAN ตัดสินใจแตกต่างกันเกี่ยวกับวิธีกำหนดค่าที่เก็บข้อมูลภายใน (ระดับ RAID ฯลฯ ) ที่อาจส่งผลกระทบต่อประสิทธิภาพการทำงานของเซิร์ฟเวอร์ของฉันหรือไม่

ขอบคุณสำหรับความคิดของคุณ (หัวข้อที่คล้ายกันกล่าวสั้น ๆในคำถามนี้ SF )

หากไม่มีศัตรูในทีม SAN ฉันจะสร้างความมั่นใจให้ตัวเองและผู้พัฒนาแอปพลิเคชันว่าเซิร์ฟเวอร์ SQL ของเราไม่ได้รับความทุกข์ทรมานจากการจัดเก็บที่ไม่ดี เพียงใช้สถิติ perfmon? มาตรฐานอื่น ๆ เช่น sqlio?

ในระยะสั้นอาจไม่มีวิธีที่จะแน่ใจอย่างแท้จริง สิ่งที่ฉันจะพูด (ฉันเป็นผู้ดูแลระบบ SAN) คือหากแอปพลิเคชันของคุณทำงานได้ตามความคาดหวังของคุณไม่ต้องกังวลกับมัน หากคุณเริ่มเห็นปัญหาด้านประสิทธิภาพที่คุณเชื่อว่าอาจเกี่ยวข้องกับประสิทธิภาพของ SAN / Disk IO ดังนั้นคุณควรสอบถาม ฉันไม่ได้ใช้พื้นที่เก็บข้อมูล HP เท่าที่คุณทำ แต่ในโลกของ IBM / NetApp ฉันสามารถพูดได้จากประสบการณ์ว่าไม่มีตัวเลือกมากมายที่จะช่วยให้คุณกำหนดค่า "ไม่ดี" ได้ วันนี้ที่เก็บข้อมูลขององค์กรส่วนใหญ่ใช้การคาดเดามากมายจากการสร้างอาร์เรย์การโจมตีและไม่ปล่อยให้คุณทำผิด หากพวกเขากำลังผสมความเร็วและความจุของไดรฟ์ภายในกลุ่มการโจมตีเดียวกันคุณสามารถวางใจได้ในกรณีส่วนใหญ่ว่าดิสก์ของคุณทำงานได้ดี

ถ้าฉันโหลดการทดสอบกับไดรฟ์ SAN เหล่านี้นั่นจะทำให้ฉันมีความน่าเชื่อถือและวัดซ้ำได้จริง ๆ ว่าฉันจะเห็นอะไรเมื่อเราใช้งานจริง (สมมติว่าซอฟต์แวร์ SAN อาจ "กำหนดค่าแบบไดนามิก" แตกต่างกันตามเวลาต่างกัน)

การทดสอบโหลดน่าเชื่อถืออย่างมาก เพียงจำไว้ว่าเมื่อคุณโหลดการทดสอบหนึ่งกล่องการอยู่ใน SAN / Disk Array ที่ใช้ร่วมกันนั้นประสิทธิภาพของระบบ (และจะ) ได้รับผลกระทบจากระบบอื่นโดยใช้ที่เก็บข้อมูลเดียวกัน

IO หนักในส่วนหนึ่งของ SAN (พูดกับเซิร์ฟเวอร์ Exchange) ส่งผลต่อเซิร์ฟเวอร์ SQL ของฉันหรือไม่ (สมมติว่าพวกเขาไม่ได้ให้ดิสก์เฉพาะกับเซิร์ฟเวอร์แต่ละตัวซึ่งฉันบอกว่าไม่ได้)

มันสามารถ ไม่เกี่ยวกับดิสก์หรือดิสก์ใดที่เซิร์ฟเวอร์เปิดอยู่ ข้อมูลทั้งหมดจะถูกให้บริการผ่านตัวควบคุมดิสก์แล้วสวิตช์ SAN ประสิทธิภาพที่คุณจะเห็นนั้นขึ้นอยู่กับว่าตัวควบคุมดิสก์เชื่อมต่อกับชั้นวางดิสก์ที่เกี่ยวข้องอย่างไรและ SAN ที่เกี่ยวข้อง หากทั้งอาร์เรย์เชื่อมต่อกับแบ็คโบน SAN บนเส้นใยเดี่ยวขนาด 4 กิกะไบต์ต่อวินาทีประสิทธิภาพการทำงานจะได้รับผลกระทบอย่างชัดเจน หากอาเรย์นั้นเชื่อมต่อกับ SAN ที่ซ้ำซ้อนสองตัวซึ่งมีโหลดบาลานซ์โดยใช้ลิงก์ที่มีลำต้นดังนั้นมันจะเป็นไปไม่ได้ที่จะแลกเปลี่ยนเพียงลำพังเพื่อดูดแบนด์วิดท์ที่มากเกินไป อีกสิ่งหนึ่งที่ต้องพิจารณาคือจำนวน IO / วินาทีที่อาร์เรย์สามารถใช้งานได้ ตราบใดที่อาเรย์และ SAN นั้นเชื่อมต่ออยู่จะถูกปรับขนาดอย่างถูกต้อง

จะขอแยกไดรฟ์แบบลอจิคัลสำหรับไดรฟ์แบบลอจิคัลของฟังก์ชันที่แตกต่างกัน (data vs log vs tempdb) ช่วยได้ไหม SAN จะเห็นกิจกรรม IO ที่ต่างกันในสิ่งเหล่านี้และกำหนดค่าให้เหมาะสมที่สุดต่างกันหรือไม่

นั่นอาจเป็นเรื่องของการตั้งค่าและขึ้นอยู่กับว่าผู้ดูแลระบบพื้นที่เก็บข้อมูลของคุณกำหนดค่าไว้อย่างไร พวกเขาสามารถให้คุณสาม LUNs ในอาร์เรย์หรือโวลุ่มเดียวกันซึ่งในกรณีนี้มันเหมือนกันทั้งหมด หากพวกเขาให้แต่ละ LUNs ในอาร์เรย์ที่แตกต่างกันในปริมาณที่แตกต่างกัน (ดิสก์ที่แตกต่างกันทางกายภาพ) แล้วมันอาจจะคุ้มค่าสำหรับคุณที่จะแยกพวกเขา

ตอนนี้เรากำลังวุ่นวายกับเรื่องอวกาศ ทีมแอปพลิเคชันได้รับคำสั่งให้ตัดการจัดเก็บข้อมูล ฯลฯ ความกังวลเกี่ยวกับพื้นที่จะทำให้ทีม SAN ตัดสินใจแตกต่างกันเกี่ยวกับวิธีกำหนดค่าที่เก็บข้อมูลภายใน (ระดับ RAID ฯลฯ ) ที่อาจส่งผลกระทบต่อประสิทธิภาพการทำงานของเซิร์ฟเวอร์ของฉันหรือไม่

ฉันไม่คิดว่าผู้ดูแลระบบที่เก็บข้อมูลของคุณจะเปลี่ยนระดับการโจมตีเพื่อเพิ่มพื้นที่ว่าง ถ้าเขาต้องการเขาก็น่าจะถูกไล่ออก ความกังวลเกี่ยวกับพื้นที่สามารถนำไปสู่สิ่งต่าง ๆ ที่ได้รับการกำหนดค่าแตกต่างกัน แต่ไม่ปกติในลักษณะที่ส่งผลกระทบต่อประสิทธิภาพ พวกเขาอาจกลายเป็นเพียงเล็กน้อยแน่นเกี่ยวกับพื้นที่เท่าไหร่พวกเขาให้คุณ พวกเขาอาจเปิดใช้งานคุณลักษณะต่างๆเช่นการทำซ้ำข้อมูล (ถ้าอาร์เรย์รองรับมัน) ซึ่งสามารถขัดขวางประสิทธิภาพของอาร์เรย์ในขณะที่กระบวนการทำงาน แต่ไม่ทำงานตลอดเวลา

ทีม SAN ควรมีเครื่องมือที่สามารถช่วยคุณเปิดเผยว่าแอปของคุณกำลังฮอตสปอต เห็นได้ชัดว่าคุณควรตรวจสอบและวัดที่ปลายของคุณด้วย

ประสบการณ์ส่วนใหญ่ของฉันอยู่ที่ EMC ดังนั้น YMMV แต่สิ่งต่อไปนี้ควรใช้กับอุปกรณ์ SAN ส่วนใหญ่

มีเพียงพอร์ตมากมายที่เข้าสู่อาเรย์ บางครั้งมีสวิตช์ SAN อยู่ระหว่างที่คุณสามารถกำหนดโซน เพียงเพราะว่าอาเรย์นั้นเป็นแหล่งเก็บข้อมูลขนาดใหญ่ไม่ได้หมายความว่าคุณไม่ควรกังวลเกี่ยวกับประสิทธิภาพของ IO

ดังนั้นหากคุณรู้สึกว่าคุณมีปัญหาเกี่ยวกับ IO คุณจะต้อง จำกัด ขอบเขตของปัญหาให้แคบลง หากอยู่ระหว่าง HBA และอาร์เรย์คุณสามารถคิดได้ว่า HBA นั้นถูก maxed out หรือหากพอร์ต SAN ที่ด้านสวิตช์ / อาร์เรย์นั้นมีการบอกรับสมาชิกมากเกินไป นอกจากนี้คุณควรมีรูปแบบการเข้าถึงการตรวจสอบทีม SAN สำหรับแอปของคุณทั้งตั้งแต่เริ่มต้นและเริ่มร้อน

เห็นได้ชัดว่าที่เก็บข้อมูลพื้นฐานสร้างความแตกต่างว่าการรัน RAID5 ขนาดใหญ่ช้ากับ RAID10 ที่รวดเร็วอย่างที่คุณต้องการในบางครั้งต้องกดดิสก์โดยไม่คำนึงถึงระดับแคชที่ต่างกัน

HTH คุณสามารถ ping ฉันออฟไลน์หากคุณมีปัญหาเฉพาะเนื่องจากอาจใช้เวลาสักครู่ในการขุดผ่าน

หากไม่มีศัตรูในทีม SAN ฉันจะสร้างความมั่นใจให้ตัวเองและผู้พัฒนาแอปพลิเคชันว่าเซิร์ฟเวอร์ SQL ของเราไม่ได้รับความทุกข์ทรมานจากการจัดเก็บที่ไม่ดี เพียงใช้สถิติ perfmon? มาตรฐานอื่น ๆ เช่น sqlio?

สิ่งแรกที่คุณต้องรู้ก่อนที่จะทำการเปรียบเทียบประเภทใด ๆ ก็คือการที่เวิร์กโหลดของคุณเองนั้นต้องทนต่อการทำงานดังนั้นเกณฑ์มาตรฐานของคุณเองก่อนที่จะตรวจสอบระบบใหม่ ด้วยวิธีนี้หากคุณพบว่าคุณกำลังเพิ่มสูงสุดให้พูดว่า 56MB / s ในระหว่างที่มีการโหลดสูงสุด (สำรองข้อมูลหรือไม่) พบว่าอาร์เรย์ดิสก์ที่แนบกับ SAN 'เท่านั้น' จะดัน 110MB / s ภายใต้โหลดสูงสุดแบบจำลอง มั่นใจได้ว่าขีด จำกัด จะไม่เป็นช่อง I / O

เมื่อตรวจสอบดิสก์อาร์เรย์ใหม่ฉันได้ทำการทดสอบประสิทธิภาพแบบนี้แล้ว อาร์เรย์ใหม่ใช้ไดรฟ์ SATA แทนไดรฟ์ไฟเบอร์แชนเนล (SCSI) และฉันต้องการยืนยันตัวเองว่ามันจะทำงานในสภาพแวดล้อมของเรา ฉันสงสัยอย่างมาก แต่หลังจากการจำแนกลักษณะฉันพบว่าระบบใหม่มีค่าใช้จ่าย I / O เพียงพอภายใต้จุดสูงสุดเพื่อให้ทันกับจุดสูงสุดที่วัดได้ในดิสก์ที่เชื่อถือได้มากขึ้น มันทำให้ฉันประหลาดใจ

ถ้าฉันโหลดการทดสอบกับไดรฟ์ SAN เหล่านี้นั่นจะทำให้ฉันมีความน่าเชื่อถือและวัดซ้ำได้จริง ๆ ว่าฉันจะเห็นอะไรเมื่อเราใช้งานจริง (สมมติว่าซอฟต์แวร์ SAN อาจ "กำหนดค่าแบบไดนามิก" แตกต่างกันตามเวลาต่างกัน)

เนื่องจากลักษณะที่ใช้ร่วมกันของดิสก์อาร์เรย์ SAN ที่แนบมาทำให้ประสิทธิภาพการทำงานเปลี่ยนแปลงตลอดทั้งสัปดาห์ หากคุณทราบดีอยู่แล้วว่าโหลด I / O สูงสุดของคุณเป็นเท่าใดให้ทำการทดสอบโหลดหลายครั้งในระหว่างวันที่มีการโหลดสูงสุด I / O ของคุณ ด้วยวิธีนี้คุณจะสามารถจำแนกลักษณะของค่าใช้จ่าย I / O ได้ดีขึ้นในช่วงเวลาที่คุณสนใจมากที่สุดการทดสอบการโหลดในช่วงเวลาที่ไม่มากจะทำให้คุณรู้สึกว่าสิ่ง 'เร็ว' จะได้รับอย่างไร ให้ขอบเขตการตรวจสอบที่แท้จริง

IO หนักในส่วนหนึ่งของ SAN (พูดกับเซิร์ฟเวอร์ Exchange) ส่งผลต่อเซิร์ฟเวอร์ SQL ของฉันหรือไม่ (สมมติว่าพวกเขาไม่ได้ให้ดิสก์เฉพาะกับเซิร์ฟเวอร์แต่ละตัวซึ่งฉันบอกว่าไม่ได้)

หาก Exchange LUNs ใช้ดิสก์ร่วมกับ SQL LUN ​​ของคุณพวกเขาจะทำอย่างนั้น เราใช้ HP EVAs ไม่ใช่ XP แต่ฉันคิดว่าพวกเขาใช้คำศัพท์ "กลุ่มดิสก์" เดียวกัน LUN ในดิสก์กลุ่มดิสก์เดียวกันจะใช้ร่วมกันดังนั้นจึงต้องต่อสู้กับ I / O บนอุปกรณ์ฟิสิคัลเหล่านั้น ยิ่งคุณใส่ดิสก์ลงในกลุ่มดิสก์มากเท่าไหร่ก็จะยิ่งสามารถเคลื่อนย้าย I / O ได้มากขึ้น อาร์เรย์ (อย่างน้อย EVA ทำเช่นนี้และฉันคิดว่า XP ที่แพงกว่าทำเช่นเดียวกัน) แจกจ่ายบล็อก LUN แบบลอจิคัลทั่วทั้งดิสก์ทางกายภาพในลักษณะที่ไม่ต่อเนื่อง สิ่งนี้ช่วยให้สามารถทำสิ่งที่คุณแนะนำซึ่งเป็นการกระจายกลุ่มของบล็อกที่เข้าถึงบ่อยไปยังอุปกรณ์ทางกายภาพที่แตกต่างกันเพื่อเพิ่มความเท่าเทียมและลดความขัดแย้งของ I / O ที่ระดับดิสก์

คำถามที่ถามคืองบประมาณของกลุ่มดิสก์นั้นมีเท่าไรและแอปพลิเคชันที่ใช้ LUN เหล่านั้นมีการสมัครใช้งาน I / O เกินหรือไม่ นั่นเป็นคำถามที่ผู้ดูแลระบบจัดเก็บข้อมูลจะต้องติดตาม อาจเป็นได้ว่า I / O สูงสุดสำหรับการแลกเปลี่ยน (อาจอยู่ในระหว่างการสำรองข้อมูล) อาจไม่ตรงกับการโหลด SQL และทั้งสองระบบสามารถอยู่ร่วมกันได้อย่างมีความสุข

จะขอแยกไดรฟ์แบบลอจิคัลสำหรับไดรฟ์แบบลอจิคัลของฟังก์ชันที่แตกต่างกัน (data vs log vs tempdb) ช่วยได้ไหม SAN จะเห็นกิจกรรม IO ที่ต่างกันในสิ่งเหล่านี้และกำหนดค่าให้เหมาะสมที่สุดต่างกันหรือไม่

สำหรับอาร์เรย์ของ HP คุณจะต้องใส่รูปแบบ I / O ที่แตกต่างกันลงในกลุ่มดิสก์ที่แตกต่างกันไม่ใช่ LUN รูปแบบ I / O ฐานข้อมูลไม่ควรอยู่ร่วมกับรูปแบบการเข้าถึงการให้บริการเว็บเป็นต้น LUN ที่แตกต่างกันไม่ได้ปรับปรุงประสิทธิภาพของคุณอย่างชัดเจนเว้นแต่ว่าพวกเขาอยู่ในกลุ่มดิสก์ที่แตกต่างกัน หากพวกเขาอยู่ในกลุ่มดิสก์เดียวกันข้อดีที่แท้จริงเพียงอย่างเดียวคือระบบปฏิบัติการซึ่งสามารถกำหนดเวลา I / O ในเคอร์เนลเพื่อปรับปรุงความขนานให้กับระบบย่อยของดิสก์ ที่กล่าวว่า ...

เพื่อให้เข้าใจถึงอาร์เรย์ของ HP ได้ตระหนักถึงรูปแบบการเข้าถึงที่แตกต่างกันใน LUNs แต่ให้ความสนใจกับบล็อกตรรกะจริง ๆ อย่างใกล้ชิด การวางล็อกบน LUN ที่แตกต่างกันจะทำให้ขอบเขตของบล็อกโลจิคัลที่จะรับทราฟฟิกของ I / O นั้นและนั่นจะช่วยให้งานของการเรียงลอจิคัลบล็อกบนฟิสิคัลดิสก์ถูกต้อง

ตอนนี้เรากำลังวุ่นวายกับเรื่องอวกาศ ทีมแอปพลิเคชันได้รับคำสั่งให้ตัดการจัดเก็บข้อมูล ฯลฯ ความกังวลเกี่ยวกับพื้นที่จะทำให้ทีม SAN ตัดสินใจแตกต่างกันเกี่ยวกับวิธีกำหนดค่าที่เก็บข้อมูลภายใน (ระดับ RAID ฯลฯ ) ที่อาจส่งผลกระทบต่อประสิทธิภาพการทำงานของเซิร์ฟเวอร์ของฉันหรือไม่

อย่างแน่นอน. หากพื้นที่ว่างคุณจะไม่ได้รับกลุ่มดิสก์เฉพาะสำหรับ I / O ของคุณ (ยกเว้นกรณีที่สภาพแวดล้อมการจัดเก็บของคุณมีขนาดใหญ่พอที่จะพิสูจน์ความทุ่มเท 7TB ของดิสก์ทางกายภาพสำหรับการใช้งานแบบเอกสิทธิ์เฉพาะบุคคลของคุณ ณ จุดนั้น ) การอภิปรายของ Raid5 / Raid10 นั้นขึ้นอยู่กับนโยบายขององค์กรเป็นส่วนใหญ่และการถามคือทางออกที่ดีที่สุดของคุณ

ฉันขอแนะนำให้เปิดกล่องโต้ตอบกับทีม SAN และผู้ขายของคุณเพื่อแก้ไขข้อกังวลของคุณ หนึ่งในปัญหาที่คุณจะต้องดำเนินการเกี่ยวกับการวัดประสิทธิภาพของคุณเองก็คือการทดสอบของคุณอาจไม่มีผลต่อสิ่งที่เกิดขึ้นในการผลิตโดยเฉพาะอย่างยิ่งเมื่อโหลดสูงสุด SAN ส่วนใหญ่มีแคชแบตเตอรี่สำรองมากมายซึ่งในหลายกรณี (โดยเฉพาะเมื่อคุณเรียกใช้เบนช์มาร์กแบบสังเคราะห์) หมายความว่าคุณกำลังเขียนถึง RAM และรับประสิทธิภาพการทำงานแบบเตะ

ขึ้นอยู่กับสภาพแวดล้อมของคุณและวิธีการแก้ปัญหาที่คุณใช้ CE ผู้ขายบางรายอาจบินเข้ามาและตั้งค่า SAN ให้เป็นมาตรฐานที่เขาต้องการ มันเกิดขึ้นมากกว่าที่คุณคิด คุณจะต้องกำจัดชิปที่ "ทีม SAN รู้ทั้งหมด" จนกว่าคุณจะมั่นใจว่าโซลูชันนั้นตรงตามความต้องการของคุณ

โชคดี.

ฉันอยู่ในการประชุม oracle ครั้งเดียวด้วยการพูดคุยในหัวข้อนี้ - SAN มีสติสำหรับฐานข้อมูล

ส่วนสำคัญของการพูดคุยสามารถใช้ได้ในไฟล์ PDF นี้หรือที่เว็บไซต์ของผู้เขียนที่นี่