انٽرپرائز ايپليڪيشنن ۽ ورچوئلائيزيشن سسٽم جو هڪ وڏو تعداد غلطي برداشت ڪندڙ حلن جي تعمير لاءِ پنهنجون ميکانيزم آهن. خاص طور تي، Oracle RAC (Oracle Real Application Cluster) ٻن يا وڌيڪ Oracle ڊيٽابيس سرورز جو ڪلستر آھي جيڪو گڏجي ڪم ڪري ٿو لوڊ کي بيلنس ڪرڻ ۽ سرور/ايپليڪيشن جي سطح تي غلطي رواداري مهيا ڪرڻ لاءِ. ھن موڊ ۾ ڪم ڪرڻ لاءِ، توھان کي ھڪڙي حصيداري اسٽوريج جي ضرورت آھي، جيڪو عام طور تي ھڪڙي اسٽوريج سسٽم آھي.
جيئن ته اسان اڳ ۾ ئي اسان جي هڪ ۾ بحث ڪيو آهي اسٽوريج سسٽم پاڻ، نقل ٿيل اجزاء جي موجودگي جي باوجود (ڪنٽرولرز سميت)، اڃا تائين ناڪامي جا نقطا آهن - خاص طور تي ڊيٽا جي هڪ واحد سيٽ جي صورت ۾. تنهن ڪري، هڪ Oracle حل کي وڌائڻ جي قابل اعتماد گهرجن سان گڏ، "N سرورز - هڪ اسٽوريج سسٽم" اسڪيم کي پيچيده ٿيڻ جي ضرورت آهي.
پهرين، يقينا، اسان کي اهو فيصلو ڪرڻو پوندو ته اسان ڪهڙن خطرن جي خلاف بيمه ڪرڻ جي ڪوشش ڪري رهيا آهيون. هن آرٽيڪل ۾، اسان خطرن جي خلاف تحفظ تي غور نه ڪنداسين جهڙوڪ "هڪ ميٽيورائٽ اچي ويو آهي." تنهن ڪري هڪ جغرافيائي طور تي منتشر آفت جي بحالي جي حل جي تعمير هيٺ ڏنل مضمونن مان هڪ لاء هڪ موضوع رهندو. هتي اسان کي نام نهاد ڪراس-ريڪ آفت جي بحالي واري حل تي نظر ايندي، جڏهن تحفظ سرور ڪابينا جي سطح تي ٺهيل آهي. ڪابينا پاڻ کي ساڳئي ڪمري ۾ يا مختلف ماڻهن ۾ واقع ٿي سگهي ٿو، پر عام طور تي ساڳئي عمارت جي اندر.
انهن ڪابينا ۾ لازمي طور تي سامان ۽ سافٽ ويئر جو سڄو ضروري سيٽ شامل هوندو جيڪو "پاڙيسري" جي حالت کان سواءِ Oracle ڊيٽابيس جي آپريشن جي اجازت ڏيندو. ٻين لفظن ۾، ڪراس-ريڪ آفت جي بحالي جي حل کي استعمال ڪندي، اسان ناڪامي جي خطرن کي ختم ڪريون ٿا:
- Oracle ايپليڪيشن سرورز
- اسٽوريج سسٽم
- سوئچنگ سسٽم
- ڪابينا ۾ سڀني سامان جي مڪمل ناڪامي:
- طاقت کان انڪار
- کولنگ سسٽم جي ناڪامي
- خارجي عنصر (انسان، فطرت، وغيره)
Oracle سرورز جي نقل جو مطلب Oracle RAC جي بلڪل آپريٽنگ اصول آهي ۽ هڪ ايپليڪيشن ذريعي لاڳو ڪيو ويو آهي. سوئچنگ سهولتن جي نقل پڻ ڪو مسئلو ناهي. پر اسٽوريج سسٽم جي نقل سان، هر شيء بلڪل سادو ناهي.
سڀ کان آسان اختيار ڊيٽا جي نقل آهي مکيه اسٽوريج سسٽم کان بيڪ اپ هڪ ڏانهن. Synchronous يا asynchronous، اسٽوريج سسٽم جي صلاحيتن تي منحصر ڪري ٿو. هم وقت سازي جي نقل سان، سوال فوري طور تي پيدا ٿئي ٿو ڊيٽا جي مطابقت کي يقيني بڻائڻ جو تعلق Oracle جي حوالي سان. پر ان جي باوجود جيڪڏهن ايپليڪيشن سان سافٽ ويئر انضمام آهي، ڪنهن به صورت ۾، مکيه اسٽوريج سسٽم تي ناڪامي جي صورت ۾، ڪلستر کي بيڪ اپ اسٽوريج ۾ تبديل ڪرڻ لاء منتظمين جي دستي مداخلت جي ضرورت پوندي.
ھڪڙو وڌيڪ پيچيده اختيار آھي سافٽ ويئر ۽ / يا هارڊويئر اسٽوريج "ورچوئلائزر" جيڪو مستقل مسئلن ۽ دستي مداخلت کي ختم ڪندو. پر تعیناتي جي پيچيدگي ۽ بعد ۾ انتظاميه، انهي سان گڏ اهڙي حل جي تمام غير معمولي قيمت، ڪيترن ئي ماڻهن کي خوفزده ڪري ٿو.
AccelStor NeoSapphire™ سڀ فليش سري حل منظرنامي لاءِ ڀرپور آهي جهڙوڪ ڪراس-ريڪ آفت جي بحالي Shared-Nothing آرڪيٽيڪچر استعمال ڪندي. هي ماڊل هڪ ٻه-نوڊ اسٽوريج سسٽم آهي جيڪو فليش ڊرائيو سان ڪم ڪرڻ لاءِ ملڪيت FlexiRemap® ٽيڪنالاجي استعمال ڪري ٿو. مهرباني هن جي NeoSapphire™ H710 600K IOPS@4K بي ترتيب لکڻ ۽ 1M+ IOPS@4K بي ترتيب پڙهڻ تائين ڪارڪردگي پهچائڻ جي قابل آهي، جيڪو ناگزير آهي جڏهن کلاسڪ RAID تي ٻڌل اسٽوريج سسٽم استعمال ڪندي.
پر NeoSapphire ™ H710 جي مکيه خصوصيت ٻن نوڊس جي الڳ الڳ ڪيسن جي صورت ۾ عمل ڪرڻ آهي، جن مان هر هڪ ڊيٽا جي پنهنجي ڪاپي آهي. نوڊس جي هم وقت سازي کي خارجي InfiniBand انٽرفيس ذريعي ڪيو ويندو آهي. هن فن تعمير جي مهرباني، اهو ممڪن آهي ته مختلف هنڌن تي نوڊس کي 100m جي فاصلي تي ورهايو وڃي، ان ڪري هڪ ڪراس-ريڪ آفت جي بحالي جي حل فراهم ڪري ٿي. ٻئي نوڊس مڪمل طور تي هم وقت ڪم ڪن ٿا. ميزبان پاسي کان، H710 هڪ عام ڊبل ڪنٽرولر اسٽوريج سسٽم وانگر ڏسڻ ۾ اچي ٿو. تنهن ڪري، ڪنهن به اضافي سافٽ ويئر يا هارڊويئر اختيارن يا خاص طور تي پيچيده سيٽنگون انجام ڏيڻ جي ڪا ضرورت ناهي.
جيڪڏهن اسان مٿي بيان ڪيل سڀني ڪراس-ريڪ آفت جي بحالي جي حل جو مقابلو ڪريون ٿا، ته پوء AccelStor مان اختيار باقي کان نمايان طور تي بيٺو آهي:
AccelStor NeoSapphire™ شيئر ٿيل ڪجھ به نه آرڪيٽيڪچر
سافٽ ويئر يا هارڊويئر "ورچوئلائزر" اسٽوريج سسٽم
نقل جي بنياد تي حل
دستياب
سرور جي ناڪامي
ڪوبه وقتي وقت ناهي
ڪوبه وقتي وقت ناهي
ڪوبه وقتي وقت ناهي
سوئچ جي ناڪامي
ڪوبه وقتي وقت ناهي
ڪوبه وقتي وقت ناهي
ڪوبه وقتي وقت ناهي
اسٽوريج سسٽم جي ناڪامي
ڪوبه وقتي وقت ناهي
ڪوبه وقتي وقت ناهي
آخري وقت
مڪمل ڪابينا ناڪامي
ڪوبه وقتي وقت ناهي
ڪوبه وقتي وقت ناهي
آخري وقت
قيمت ۽ پيچيدگي
حل جي قيمت
گھٽ*
Высокая
Высокая
لڳائڻ جي پيچيدگي
گھٽ
Высокая
Высокая
*AccelStor NeoSapphire™ اڃا تائين هڪ آل فليش صف آهي، جنهن جي وصف نه آهي "3 ڪوپيڪس"، خاص طور تي جڏهن ته ان ۾ ٻٽي گنجائش رزرو آهي. جڏهن ته، جڏهن هڪ حل جي آخري قيمت جي مقابلي ۾ ان جي بنياد تي ٻين وينڊرز کان ملندڙن سان، قيمت گهٽ سمجهي سگهجي ٿي.
ايپليڪيشن سرورز کي ڳنڍڻ لاءِ ٽوپولوجي ۽ آل فليش ايري نوڊس هن طرح نظر اينديون:
جڏهن ٽوپولوجي جي منصوبابندي ڪندي، اهو پڻ انتهائي سفارش ڪئي وئي آهي ته نقل ڪرڻ جي انتظام سوئچز ۽ سرور سان ڳنڍيل هجي.
هتي ۽ اڳتي اسان فائبر چينل ذريعي ڳنڍڻ بابت ڳالهائينداسين. جيڪڏھن توھان iSCSI استعمال ڪندا، سڀ ڪجھ ساڳيو ھوندو، استعمال ٿيل سوئچز جي قسمن لاءِ ترتيب ڏنل ۽ ڪجھ مختلف صف سيٽنگون.
تياري جو ڪم صفن تي
استعمال ٿيل سامان ۽ سافٽ ويئر
سرور ۽ سوئچ وضاحتون
اجزاء
بيان
Oracle ڊيٽابيس 11g سرور
ٻه
سرور آپريٽنگ سسٽم
اورلڪس لينڪس
Oracle ڊيٽابيس ورزن
11g (RAC)
پروسيسرز في سرور
ٻه 16 ڪور Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
جسماني ياداشت في سرور
128GB
ايف سي نيٽ ورڪ
16Gb/s FC multipathing سان
FC HBA
ايمولڪس Lpe-16002B
ڪلستر مينيجمينٽ لاءِ وقف عوامي 1GbE بندرگاهن
Intel ethernet اڊاپٽر RJ45
16Gb/s FC سوئچ
بروڪيڊ 6505
وقف ٿيل نجي 10GbE بندرگاهن ڊيٽا هم وقت سازي لاءِ
Intel X520
AccelStor NeoSapphire™ سڀ فليش آري جي وضاحت
اجزاء
بيان
اسٽوريج سسٽم
NeoSapphire™ اعلي دستيابي ماڊل: H710
تصويري نسخو
4.0.1
ڊرائيو جو ڪل تعداد
48
ڊرائيو سائيز
1.92TB
گاڏي جو قسم
ايس ايم ڊي
ايف سي ٽارگيٽ بندرگاهن
16x 16Gb بندرگاهن (8 في نوڊ)
انتظام بندرگاهن
1GbE ايٿرنيٽ ڪيبل ميزبانن سان ڳنڍيندي هڪ ايٿرنيٽ سوئچ ذريعي
دل جي ڌڙڪن پورٽ
1GbE ايٿرنيٽ ڪيبل ٻن اسٽوريج نوڊس جي وچ ۾ ڳنڍيندي
ڊيٽا هم وقت سازي پورٽ
56Gb/s InfiniBand ڪيبل
ان کان اڳ جو توھان ھڪڙو صف استعمال ڪري سگھو، توھان کي ان کي شروع ڪرڻ گھرجي. ڊفالٽ طور، ٻنهي نوڊس جو ڪنٽرول پتو ساڳيو آهي (192.168.1.1). توھان کي انھن کي ھڪڙي ھڪڙي سان ڳنڍڻ جي ضرورت آھي ۽ نئين (اڳ ۾ ئي مختلف) مئنيجمينٽ ايڊريس سيٽ ڪريو ۽ وقت جي هم وقت سازي کي سيٽ ڪريو، جنھن کان پوء مئنيجمينٽ بندرگاھن ھڪڙي نيٽ ورڪ سان ڳنڍي سگھجن ٿيون. ان کان پوء، نوڊس انٽر لنڪ ڪنيڪشن لاء سبنيٽس کي تفويض ڪندي HA جوڙي ۾ گڏ ڪيا ويا آهن.
شروعاتي مڪمل ٿيڻ کان پوء، توهان ڪنهن به نوڊ مان صف کي منظم ڪري سگھو ٿا.
اڳيون، اسان ضروري حجم ٺاهيندا آهيون ۽ انهن کي ايپليڪيشن سرورز تي شايع ڪندا آهيون.
Oracle ASM لاءِ ڪيترن ئي جلدن کي ٺاهڻ جي تمام گهڻي سفارش ڪئي وئي آهي جيئن ته اهو سرورز لاءِ هدفن جو تعداد وڌائيندو، جيڪو آخرڪار مجموعي ڪارڪردگي کي بهتر بڻائيندو (وڌيڪ ٻئي ۾ قطار تي وڌيڪ. ).
ٽيسٽ جي تشڪيل
اسٽوريج حجم جو نالو
حجم جي ماپ
ڊيٽا 01
200GB
ڊيٽا 02
200GB
ڊيٽا 03
200GB
ڊيٽا 04
200GB
ڊيٽا 05
200GB
ڊيٽا 06
200GB
ڊيٽا 07
200GB
ڊيٽا 08
200GB
ڊيٽا 09
200GB
ڊيٽا 10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
ريڊو01
100GB
ريڊو02
100GB
ريڊو03
100GB
ريڊو04
100GB
ريڊو05
100GB
ريڊو06
100GB
ريڊو07
100GB
ريڊو08
100GB
ريڊو09
100GB
ريڊو10
100GB
صف جي آپريٽنگ طريقن ۽ هنگامي حالتن ۾ ٿيندڙ عملن بابت ڪجهه وضاحتون
هر نوڊ جي ڊيٽا سيٽ کي "نسخ نمبر" پيٽرولر آهي. شروعاتي شروعات کان پوء، اهو ساڳيو آهي ۽ 1 جي برابر آهي. جيڪڏهن ڪجهه سببن لاء نسخي نمبر مختلف آهي، پوء ڊيٽا هميشه پراڻي نسخي کان ننڍي نسخ ۾ هم وقت سازي ڪئي ويندي آهي، جنهن کان پوء ننڍي نسخي جو تعداد ترتيب ڏنو ويندو آهي، يعني. مطلب ته ڪاپيون هڪجهڙيون آهن. سببن جا نسخا مختلف ٿي سگهن ٿا:
- ھڪڙي نوڊس جي مقرر ڪيل ريبوٽ
- اوچتو بند ٿيڻ جي ڪري ھڪڙي نوڊس تي ھڪڙو حادثو (بجلي جي فراهمي، گھڻي گرمي، وغيره).
- گم ٿيل InfiniBand ڪنيڪشن کي هم وقت سازي ڪرڻ جي ناڪامي سان
- ڊيٽا جي بدعنواني جي ڪري ھڪڙي نوڊس تي ھڪڙو حادثو. هتي توهان کي هڪ نئون HA گروپ ٺاهڻ ۽ ڊيٽا سيٽ جي مڪمل هم وقت سازي جي ضرورت پوندي.
ڪنهن به صورت ۾، نوڊ جيڪو آن لائن رهي ٿو ان جو نسخو نمبر هڪ طرف وڌائي ٿو ان جي ڊيٽا سيٽ کي هم وقت سازي ڪرڻ لاءِ جوڙي سان ڪنيڪشن بحال ٿيڻ کان پوءِ.
جيڪڏهن Ethernet لنڪ تي ڪنيڪشن گم ٿي وڃي ٿو، دل جي بيٽ عارضي طور تي InfiniBand ڏانهن سوئچ ڪري ٿي ۽ 10 سيڪنڊن اندر واپس اچي ٿي جڏهن ان کي بحال ڪيو وڃي.
ميزبانن کي ترتيب ڏيڻ
غلطي رواداري کي يقيني بڻائڻ ۽ ڪارڪردگي بهتر ڪرڻ لاء، توهان کي صف لاء MPIO سپورٽ کي فعال ڪرڻ گهرجي. ائين ڪرڻ لاءِ، توهان کي /etc/multipath.conf فائل ۾ لائينون شامل ڪرڻ گهرجن، ۽ پوءِ ملٽي پاٿ سروس کي ٻيهر شروع ڪريو.
لڪيل متنڊوائيسز {
ڊوائيس {
وڪرو ڪندڙ "AStor"
path_grouping_policy "group_by_prio"
path_selector "قطار جي ڊگھائي 0"
path_checker "tur"
خاصيتون "0"
هارڊويئر سنڀاليندڙ "0"
prio "const"
فوري طور تي ناڪام ٿيڻ
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ها
detect_prio ها
rr_min_io_rq 1
no_path_retry 0
}
}
اڳيون، ASM لاءِ ASMLib ذريعي MPIO سان ڪم ڪرڻ لاءِ، توهان کي تبديل ڪرڻو پوندو /etc/sysconfig/oracleasm فائل ۽ پوءِ هلايو /etc/init.d/oracleasm scandisks.
لڪيل متن
# ORACLEASM_SCANORDER: ڊسڪ اسڪيننگ کي ترتيب ڏيڻ لاءِ ملاپ جا نمونا
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: اسڪين مان ڊسڪ کي خارج ڪرڻ لاءِ ملاپ جا نمونا
ORACLEASM_SCANEXCLUDE="sd"
ويچاري
جيڪڏھن توھان ASMLib استعمال ڪرڻ نٿا چاھيو، توھان استعمال ڪري سگھوٿا UDEV ضابطا، جيڪي ASMLib لاءِ بنياد آھن.
Oracle Database جي ورجن 12.1.0.2 سان شروع ٿي، اختيار موجود آهي انسٽاليشن لاءِ ASMFD سافٽ ويئر جي حصي طور.
ان ڳالهه کي يقيني بڻائڻ ضروري آهي ته Oracle ASM لاءِ ٺاهيل ڊسڪ بلاڪ جي سائيز سان جڙيل آهن جيڪا صف جسماني طور تي هلندي آهي (4K). ٻي صورت ۾، ڪارڪردگي مسئلا ٿي سگهي ٿي. تنهن ڪري، اهو ضروري آهي ته مناسب پيٽرولن سان حجم ٺاهي:
parted/dev/mapper/device-name mklabel gpt mkpart پرائمري 2048s 100% align-check optimal 1
ڊيٽابيس جي ورڇ اسان جي ٽيسٽ جي ترتيب لاءِ ٺاهيل حجمن ۾
اسٽوريج حجم جو نالو
حجم جي ماپ
حجم LUNs ميپنگ
ASM حجم ڊيوائس تفصيل
مختص يونٽ جي ماپ
ڊيٽا 01
200GB
نقشو سڀني اسٽوريج حجمن کي اسٽوريج سسٽم تي سڀني ڊيٽا بندرگاهن کي
فالتو: معمولي
نالو: DGDATA
مقصد: ڊيٽا فائلون
4MB
ڊيٽا 02
200GB
ڊيٽا 03
200GB
ڊيٽا 04
200GB
ڊيٽا 05
200GB
ڊيٽا 06
200GB
ڊيٽا 07
200GB
ڊيٽا 08
200GB
ڊيٽا 09
200GB
ڊيٽا 10
200GB
Grid01
1GB
فالتو: معمولي
نالو: DGGRID1
مقصد:گرڊ: CRS ۽ ووٽنگ
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
فالتو: معمولي
نالو: DGGRID2
مقصد:گرڊ: CRS ۽ ووٽنگ
4MB
Grid05
1GB
Grid06
1GB
ريڊو01
100GB
فالتو: معمولي
نالو: DGREDO1
مقصد: ريڊ لاگ آف ٿريڊ 1
4MB
ريڊو02
100GB
ريڊو03
100GB
ريڊو04
100GB
ريڊو05
100GB
ريڊو06
100GB
فالتو: معمولي
نالو: DGREDO2
مقصد: ريڊ لاگ آف ٿريڊ 2
4MB
ريڊو07
100GB
ريڊو08
100GB
ريڊو09
100GB
ريڊو10
100GB
ڊيٽابيس سيٽنگون
- بلاڪ سائيز = 8K
- تبديل ڪرڻ جي جاء = 16GB
- اي ايم ايم کي غير فعال ڪريو (خودڪار ميموري مئنيجمينٽ)
- شفاف وڏن صفحن کي بند ڪريو
ٻيون سيٽنگون
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # جيڪڏھن توھان لينڪس x86 استعمال ڪري رھيا آھيو ته ھن کي سيٽ نه ڪريو
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ گرڊ نرم nproc 2047
✓ گرڊ هارڊ nproc 16384
✓ گرڊ نرم nofile 1024
✓ گرڊ هارڊ نوفائل 65536
✓ گرڊ نرم اسٽيڪ 10240
✓ گرڊ هارڊ اسٽيڪ 32768
✓ اوريڪل نرم اين پروڪ 2047
✓ اوريڪل هارڊ nproc 16384
✓ اوريڪل نرم نوفائل 1024
✓ اوريڪل هارڊ نوفائل 65536
✓ اوريڪل نرم اسٽيڪ 10240
✓ اوريڪل هارڊ اسٽيڪ 32768
✓ نرم ميملوڪ 120795954
✓ هارڊ ميم لاک 120795954
sqlplus "/ as sysdba"
تبديل ڪريو سسٽم سيٽ عمل = 2000 دائرو = اسپي فائل؛
تبديل ڪريو سسٽم سيٽ open_cursors=2000 scope=spfile؛
سسٽم سيٽ تبديل ڪريو session_cached_cursors=300 scope=spfile؛
تبديل ڪريو سسٽم سيٽ db_files=8192 scope=spfile؛
ناڪامي جو امتحان
مظاهرين جي مقصدن لاء، HammerDB استعمال ڪيو ويو ھڪڙي OLTP لوڊ کي نقل ڪرڻ لاء. HammerDB ترتيب:
گودامن جو تعداد
256
ڪل ٽرانزيڪشن في صارف
1000000000000
مجازي استعمال ڪندڙ
256
نتيجو هڪ 2.1M TPM هو، جيڪو صف جي ڪارڪردگي جي حد کان پري آهي ، پر سرورز جي موجوده هارڊويئر ترتيبن جي لاءِ ”ڇت“ آهي (بنيادي طور تي پروسيسرز جي ڪري) ۽ انهن جو تعداد. هن امتحان جو مقصد اڃا تائين مڪمل طور تي حل جي غلطي رواداري کي ظاهر ڪرڻ آهي، ۽ وڌ ۾ وڌ ڪارڪردگي حاصل ڪرڻ نه آهي. تنهن ڪري، اسان صرف هن شڪل تي تعمير ڪنداسين.
ھڪڙي نوڊس جي ناڪامي لاء ٽيسٽ
لشڪر اسٽوريج ڏانهن رستن جو حصو وڃائي ڇڏيو، باقي ٻين جي ذريعي ڪم ڪرڻ جاري رکي ٻئي نوڊ سان. ڪارڪردگي ڪجهه سيڪنڊن لاءِ گهٽجي وئي ڇاڪاڻ ته رستن کي ٻيهر تعمير ڪيو پيو وڃي، ۽ پوءِ معمول تي موٽي آيو. خدمت ۾ ڪا به رڪاوٽ نه هئي.
ڪابينا ناڪامي ٽيسٽ سڀني سامان سان
انهي حالت ۾، ڪارڪردگي پڻ ڪجهه سيڪنڊن لاء رستن جي بحالي جي ڪري، ۽ پوء اڌ اصل قدر ڏانهن موٽيو. نتيجو هڪ ايپليڪيشن سرور جي آپريشن کان خارج ٿيڻ جي ڪري شروعاتي ھڪڙي کان اڌ ٿي ويو. خدمت ۾ به ڪا رڪاوٽ نه هئي.
جيڪڏهن ضرورت آهي ته Oracle لاءِ مناسب قيمت تي غلطي برداشت ڪندڙ ڪراس-ريڪ آفت جي بحالي واري حل کي لاڳو ڪرڻ ۽ ٿورڙي تعیناتي/انتظاميه ڪوشش سان، پوءِ Oracle RAC ۽ آرڪيٽيڪچر گڏجي ڪم ڪن. بهترين اختيارن مان هڪ هوندو. Oracle RAC جي بدران، ڪو ٻيو سافٽ ويئر ٿي سگهي ٿو جيڪو ڪلسترنگ مهيا ڪري ٿو، ساڳيو DBMS يا ورچوئلائيزيشن سسٽم، مثال طور. حل جي تعمير جو اصول ساڳيو رهندو. ۽ هيٺئين لائن RTO ۽ RPO لاءِ صفر آهي.
جو ذريعو: www.habr.com