ويژگيهاي
بازيافت و در دسترس بودن
بهبودهاي جديد در SQL Server 2005 براي بهبود دسترسپذيري SQL Server
با افزايش قابليتهاي كلاسترينگ آن و فراهم كردن گزينههاي پايگاه داده جديدي كه
قابليتهاي در دسترس بودن متوالي و بازيافت پايگاه داده بهبود يافته را ارايه ميكنند،
ادامه مييابد. دستيابي به در دسترس بودن بالا در يك مقياس كوچك نسبتاً آسان است،
ولي هنگام افزايش اندازه سيستم، بهطور نمايي مشكلتر ميشود. SQL Server 2005 تعدادي از ويژگيهاي جديدي را كه در دسترس بودن و قابليت بازيافت
پايگاه داده را با سامان بخشيدن به موانع اصلي كه از در دسترس بودن پايگاه داده
سطح جهاني جلوگيري ميكنند، بهبود ميبخشد. برخي از عواملي كه از در دسترس بودن
پايگاه داده در نگارشهاي قبلي SQL Server
جلوگيري ميكردند، شامل مواردي از قبيل زمانهاي failover همراه با تأخير، نياز به داشتن دستيابي پايگاه داده انحصاري براي
عمليات نگهداري منتخب و گاهي اوقات مشكل بودن پاسخ دادن سرور در طي زمان مصرف
بالاي CPU، از قبيل هنگامي كه مقداري از كد كاربر در يك حلقه بي نهايت ميافتد،
ميباشند. عامل ديگري كه ميتواند تأثير زيادي بر در دسترس بودن پايگاه داده
بگذارد، ارتقاهاي سختافزاري است. حتي اگر ارتقاهاي سختافزاري، رويدادهاي طرحريزي
شده باشند، نيازمند زمان بيكاري سيستم براي انجام ارتقا هستند. SQL Server 2005 قابليت جديدي را براي كاهش زمان بيكاري مورد نياز با يكي از
متداولترين ارتقاهاي سختافزاري طراحي كرده است. در اين فصل، نگاهي به اين گزينههاي
بازيافت و در دسترس بودن موجود در SQL Server 2005
خواهيم انداخت، بنابراين ميتوانيد نحوه استفاده از اين ويژگيها را براي پيادهسازي
در SQL
Server 2005 در يك محيط پايگاه
داده توليدي قابل بازيافت و در دسترس درك كنيد.
محافظت
از خرابي سرور يا پايگاه داده
خرابي سرور پايگاه داده، يك از كار
افتادگي است كه با خرابي يك سختافزار يا مشكل نرمافزاري به وجود ميآيد كه فعال
نبودن سرور را براي مدت زماني نمايش ميدهد. خرابي سرور پايگاه داده همچنين ميتواند
با عوامل محيطي از قبيل يك سانحه به وجود آيد. در اين بخش، مطالبي درباره برخي از
مهمترين ويژگيهاي جديدي كه SQL Server 2005
براي سامان بخشيدن به خرابيهاي سرور پايگاه داده فراهم كرده است، ميآموزيد.
كلاسترينگ
Failover
بهبود يافته
يك مزيت در دسترس بودن بالاي كليدي كه SQL Server 2005 در بخشي از پشتيباني آن براي Windows Server
2003 پشتيباني براي
كلاسترينگ failover را اشتقاق ميكند، است. با بهره بردن از پشتيباني كلاسترينگ بهبود
يافته در Windows
Server 2003، SQL Server 2005 هماينك ميتواند در كلاسترهاي تا هشت گره در Windows Server
2003 Datacenter Edition
باشد. علاوه بر اين، SQL Server 2005
از كلاسترينگ چهار گرهه در Windows Server 2003 Enterprise Edition و Windows
Server 2003 Datacenter Server
پشتيباني ميكند. از يك حداكثر كلاسترينگ دو گرهه در Windows 2000
Advanced Server پشتيباني ميشود.
با سرويسهاي كلاسترينگ Windows، هر سرور در كلاستر، يك گره[1] ناميده ميشود.
تمام گرهها در يك كلاستر در حالتي از ارتباط ثابت هستند. اگر يكي از گرهها در يك
كلاستر در دسترس نباشد، گره ديگري وظايف آن را در نظر خواهد گرفت و تدارك سرويسهايي
يكسان را با گره خراب شده، شروع ميكند. اين فرآيند failover ناميده ميشود. كاربراني كه به كلاستر دسترسي دارند، بهطور
خودكار به گره جديد سوييچ ميكنند.
كلاسترينگ ميتواند به دو روش اساسي
تنظيم شود: كلاسترينگ Active-Active
كه تمام گرهها كاري انجام ميدهند يا Active-Passive
كه يكي از گرهها غيرفعال است، تا وقتي كه گره فعال خراب شود. Windows Server
2003 همچنين از
پيكربنديهاي N+I (N فعال با I زاپاس) پشتيباني ميكند كه يك روش كلاسترينگ با هزينه كارآمد و
انعطافپذيري بالا فراهم ميكند تا برنامهها در دسترس قرار گيرند. مثلاً، با يك
كلاستر هشت گرهه در يك پيكربندي N+I،
ميتوانيد هفت گره از هشت گره را براي در دسترس بودن تنظيم كرده و سرويسهاي
متفاوتي را فراهم كنيد، در حالي كه هشت گره حالت غيرفعال هستند كه ميتواند سرويسهايي
از هر يك از هفت گره فعال را در نظر داشته باشد. شكل 1-3 مثالي از كلاستر هشت گرهي
را نشان ميدهد كه هفت گره فعال بوده و يك گره آماده كار است تا در صورت خراب شدن
هر يك از هفت گره فعال، شروع به كار كند.
شكل 1-3 پشتيباني
كلاستر هشت گرهي
برخي از بهبودهاي خاص كلاسترينگ در SQL Server 2005 شامل پشتيباني براي يك تنظيم كلاستر ناموجه است. علاوه بر اين،
تمام سرويسهاي مختلف در SQL Server 2005
كاملاً از كلاستر آگاه هستند، از جمله:
ü Database
Engine
ü Analysis
services
ü Reporting
services
ü SQL
Server Agent
ü Full-Text
Search
ü Service
Broker
ü SQLiMail
علاوه بر اين، تمام ابزارهاي مديريتي
عمده در SQL
Server 2005 نيز آگاه از
كلاستر هستند، از جمله:
ü SQL
Server Management Studio
ü Service
Control Manager
ü SQL
Profiler
ü SQL
Query Analyzer
ميتوانيد اطلاعات بيشتر درباره ابزارهاي
مديريت SQL
Server 2005 را در فصل 1 بيابيد.
Database Mirroring
احتمالاً
بزرگترين ويژگي جديد در ناحيه در دسترس بودن، پشتيباني SQL
Server 2005 از Database
Mirroring است. ويژگي Database
Mirroring جديد از
خرابي سرور يا پايگاه داده با دادن قابليت آماده به كار ثابت توسط SQL
Server 2005 محافظت ميكند.
Database
Mirroring لزوماً failover سطح پايگاه داده را فراهم ميكند. در
رويدادي كه پايگاه داده اصلي خراب شود، قرينه پايگاه داده، يك پايگاه داده دوم
آماده كار را در حدود 2 تا 3 ثانيه در دسترس قرار ميدهد. Database
Mirroring فقدان داده
صفر را مهيا ميكند و پايگاه داده قرينه هميشه با تراكنش جاري كه در سرور پايگاه
داده اصلي پردازش ميشود، بهنگام ميشود. تأثير اجراي Database
Mirroring بر بازده
تراكنش حداقل صفر است. پشتيباني failover پايگاه داده ميتواند براي انجام خودكار يا دستي تنظيم شود. حالت failover خودكار را به پايگاههاي داده توليدي
خود بدهيد. Database Mirroring با تمام آيتمهاي سختافزاري استاندارد كه از SQL
Server پشتيباني ميكنند،
كار ميكند (هيچ نيازي براي سيستمهاي خاص نيست و سرور اصلي و سرور قرينه نبايد
يكي باشند). علاوه بر اين، بر خلاف راهحلهاي كلاسترينگ در دسترس بودن بالا، هيچ
نيازي براي حافظه مشترك بين سرور اصلي و سرور قرينه وجود ندارد. ميتوانيد مروري
از نحوه كار ويژگي Database Mirroring را در شكل 2-3 ببينيد.
شكل 2-3 Database Mirroring
Database Mirroring
با استفاده از سه سيستم پيادهسازي ميشود: سرور اصلي، سرور قرينه و شاهد. با اين
نامها دچار تشويش نشويد. سرور اصلي تنها نام سيستمي است كه در حال حاضر سرويسهاي
پايگاه داده را فراهم ميكند. تمام اتصالات كلاينت وارده براي سرور اصلي شكل ميگيرند.
كار سرور قرينه، نگهداري يك كپي از پايگاه داده قرينه سرور اصلي است. بسته به
پيكربندي سرور قرينه، سرور اصلي و قرينه ميتوانند بدون عيب و نقص به نقشها سوييچ
كنند. شاهد لزوماً به عنوان يك شخص ثالث مستقل عمل ميكند و كمك ميكند تا تعيين
كنيد كدام سيستم نقش سرور اصلي را در نظر خواهد داشت. هر سيستمي كه سرور اصلي
خواهد بود، يك رأي ميگيرد. شاهد دو رأي ميگيرد تا در مورد سرور اصلي تصميم
بگيرد. اين مسأله بسيار مهم است، زيرا امكانپذير است كه ارتباطات بين سرور اصلي و
سرور قرينه بتوانند قطع باشند كه در اين مورد، هر سيستم خود را براي كار كردن به
عنوان سرور اصلي انتخاب ميكند. شاهد رأي تصميمگيري را تبديل ميكند.
Database Mirroring
با ارسال ثبت تراكنشها بين سرور اصلي و سرور قرينه كار ميكند. بنابراين، طبق
ضرورت، ويژگي Database
Mirroring جديد، يك برنامه
ارسال ثبت بلادرنگ است. Database Mirroring
ميتواند توسط يك پايگاه داده تنظيم شود يا ميتواند براي چند پايگاه داده تنظيم
گردد. هنگامي كه يك سيستم كلاينت، درخواستي را به سرور اصلي مينويسد، آن درخواست
واقعاً در فايل ثبت سرور اصلي نوشته ميشود، قبل از اين كه در فايل داده نوشته
شود، زيرا SQL
Server از يك ثبت Write-ahead استفاده ميكند. سپس، آن ركورد تراكنش به سرور قرينه ارسال ميشود
كه در ثبت تراكنش سرور قرينه نوشته ميشود. بعد از اين كه سرور قرينه، ركورد را در
ثبت خود نوشت، پيام تأييدي را به سرور اصلي مبني بر دريافت ركورد ارسال ميكند كه
نشان ميدهد هر دو سيستم در فايل ثبت خود داراي داده يكساني هستند. در مورد عمليات
Commit، سرور اصلي منتظر دريافت پيام تأييدي از سرور قرينه ميماند، قبل
از اين كه پاسخ خود را به كلاينت برگرداند و كامل شدن عمل را به او بگويد. براي
بهنگام نگه داشتن فايلهاي داده در سرور قرينه، لزوماً در حالتي از بازيافت مستمر
قرار دارد و داده را از ثبت گرفته و فايل داده را بهنگام ميكند.
Database Mirroring
با گرفتن يك پشتيبان از پايگاه دادهاي مقداردهي ميشود كه بايد در سرور اصلي
قرينه شود و آنگاه آن پشتيبان را براي سرور قرينه خود بازيابي كنيد. به عبارت
ديگر، پايگاه داده قرينه بايد در سرور قرينه وجود داشته باشد، قبل از اين كه
فرآيند قرينهسازي بتواند شروع شود. اين امر داده و طرح واره پايگاه داده مرتبط را
در يكجا قرار ميدهد. فرآيند بازيابي و پشتيبانگيري ميتواند از هر يك از انواع
رسانه استاندارد SQL
Server استفاده كند، از
جمله نوار يا ديسك. سپس، از فرمان ALTER DATABASE
استفاده كنيد، همانگونه كه در اينجا براي شروع فرآيند قرينهسازي استفاده ميكند:
ALTER DATABASE <database name>
SET PARTNER = '<partner server name>'
فرمان ALTER DATABASE ابتدا بايد در سرور قرينه اجرا شود، آن را به نام SQL Server اصلي در بخش SET PARTNER
اشاره ميكند. سپس فرمان ALTER DATABASE
در زمان بعدي اجرا ميشود (اين بار در سرور اصلي). هنگامي كه فرمان ALTER DATABASE در سرور اصلي اجرا ميشود، نام سرور قرينه در بخش SET PARTNER تأمين ميشود. هنگامي كه فرمان ALTER DATABASE در سرور اصلي كامل ميشود، قرينه پايگاه داده در حال حركت تنظيم
شده و سرور اصلي، انتقال ثبتها را به سرور قرينه پايگاه داده در حال حركت تنظيم
شده و سرور اصلي، انتقال ثبتها را به سرور قرينه شروع خواهد كرد. مرحله بعدي در
تنظيم Database
Mirroring، تنظيم شاهد است.
بيشتر اوقاتي كه سرور اصلي و قرينه را تنظيم ميكنيد، شاهد با اجراي مجدد فرمان ALTER DATABASE در سرور اصلي تنظيم ميشود، همانگونه كه در اين ليست نشان داده
شده است:
ALTER DATABASE <database name>
SET WITNESS = '<witness server name>'
در اين مورد، نام پايگاه داده با نام
پايگاه داده مورد استفاده در فرامين قبل يكسان است. هرچند، اين بار بخش SET WITNESS براي مشخص كردن سرور شاهد استفاده ميشود. هنگامي كه سرور شاهد
تنظيم شد، Database
Mirroring داراي تمام
اطلاعاتي است كه بايد failover
پايگاه داده را انجام دهند. Database Mirroring
لزوماً يك پايگاه داده مجازي با تحمل خرابي را به شما ميدهد. هرچند، اين داستان
كامل Database
Mirroring نيست. پيادهسازي
يك پايگاه داده آماده كار ثابت، به پايگاه داده امكان ميدهد تا سريعاً بعد از يك
خرابي در دسترس قرار گيرد، ولي ارتباطات كاربر براي آن پايگاه داده خراب شده، چه
ميشود؟ اينجا محلي است كه ويژگي جديد Transparent Client Redirect نقش خود را ايفا ميكند.
Transparent
Client Redirect
ويژگي Transparent Client
Redirect بسيار نزديك به
ويژگي Database
Mirroring كار ميكند و به
سيستمهاي كلاينت اجازه هدايت خودكار به سرور قرينه را در زمان در دسترس نبودن
سرور اصلي ميدهد. اين ويژگي جديد در MDAC[2] SQL Server 2005 جديد پيادهسازي شده است و هيچ تغييري براي برنامههاي لايه داده
يا كلاينت مورد نياز نيست. ميانافزار MDAC
از هر دو سرور اصلي و قرينه آگاه است. MDAC
نام سرور قرينه را طبق اتصال اوليه آن با سرور اصلي به دست ميآورد. هنگامي كه
اتصال به سرور اصلي از بين ميرود، MDAC
ابتدا تلاش خواهد كرد تا مجدداً به سرور اصلي متصل شود. اگر اولين تلاش براي اتصال
ناموفق باشد، آنگاه MDAC
بهطور خودكار تلاش اتصال دوم آن را به سرور قرينه هدايت ميكند. همانند
كلاسترينگ، اگر اتصال در ميانه يك تراكنش از بين برود، آنگاه آن تراكنش roll back خواهد شد و بايد بعد از اتصال كلاينت به سرور قرينه، مجدداً انجام
شود.
زمان
استفاده از كلاسترينگ يا Database Mirroring
كلاسترينگ و Database Mirroring، هر دو راهحلهاي آماده جهاني هستند كه قادر به فراهم كردن يك
سيستم پشتيبان در مورد خرابي سرور يا پايگاه داده هستند. آنها داراي شباهتهايي
هستند. هر دو قادر به رساندن فقدان داده به صفر هستند، هر دو داراي تشخيص خطاي
خودكار هستند، هر دو failover
خودكار را فراهم ميكنند و هر دو اتصال مجدد كلاينت را ممكن ميسازند. هرچند،
تفاوتهاي مهمي نيز دارند. Database Mirroring
همانگونه كه از نام آن مشخص است، در سطح پايگاه داده كار ميكند، در حالي كه
كلاسترينگ در سطح سرور كار ميكند. Database Mirroring
تقريباً زمان failover 2 تا 3 ثانيهاي ثابتي را فراهم ميكند، در حالي كه كلاسترينگ
داراي زمان failover حدود 30 ثانيه است (حتي گاهي طولانيتر كه اين امر وابسته به سطح
فعاليت پايگاه داده و اندازه پايگاههاي داده در سرور خراب شده است). Database Mirroring همچنين خرابيهاي ديسك را بهطور كاملاً بهتري محافظت ميكند،
زيرا هيچ حافظه ديسك مشتركي وجود ندارد، درست همانند راهحل كلاسترينگ. بهطور
مجازي، هيچ حد فاصلهاي براي Database Mirroring
وجود ندارد، در حالي كه كلاسترينگ داراي حد تقريباً 100 مايل است، زيرا يك حد
زماني براي انتقال ضربان قلب بين گرههاي كلاستر وجود دارد. علاوه بر اين، Database Mirroring يك فناوري سادهتر است كه پيادهسازي آن نسبت به كلاسترينگ آسانتر
است. از طرف ديگر، Database
Mirroring نميتواند براي
پايگاههاي داده سيستم استفاده شود، در حالي كه كلاسترينگ پايگاه داده سيستم و
پايگاههاي داده كاربر را محافظت ميكند. اصولاً، كلاسترينگ راهحل بهتري براي
محافظت از يك سرور كامل است، در حالي كه Database Mirroring
راهحل بهتري براي محافظت از يك برنامه يا پايگاه داده بحراني است.
بهبودهاي
در دسترس بودن پايگاه داده
هرچند، همه روشهاي قبل، عوامل مهمي را
سامان ميبخشيدند كه در دسترس بودن پايگاه داده را كاهش ميدهد، احتمالاً هيچ
عاملي وجود ندارد كه بر در دسترس بودن و قابليت بازيافت بيش از نگهداري پايگاه
داده تأثير گذارد. در حالي كه در سالهاي آينده قطعاً بدون خرابي پايگاه داده
امكانپذير است، نگهداري پايگاه داده بحث روزانهاي است كه نميتوانيد از آن دوري
كنيد. SQL
Server 2005 چالشهايي از اين
ناحيه حياتي را به علاوه دو ويژگي جديد بر عهده ميگيرد: Database Snapshots و دستيابي بازيابي قديمي. در بخش بعدي اين فصل، نگاهي مفصل به هر
يك از اين ويژگيهاي در دسترس بودن و قابليت بازيافت خواهيم داشت.
Database
Snapshot
ويژگي Database Snapshot جديد يك تصوير فقط خواندني از پايگاه داده را در محل خاصي از زمان
فراهم ميكند. يك Database
Snapshot براي ايجاد كپيهايي
از يك پايگاه داده براي گزارشگيري يا براي ايجاد يك كپي پشتيبان از پايگاه دادهاي
كه ميتواند براي برگرداندن يك پايگاه داده توليدي به حالت قبل استفاده شود، مناسبتر
است. هنگامي كه يك Database
Snapshot ايجاد ميشود،
سيستم يك كپي فوق داده از پايگاه داده مشخص شده در آن نقطه خاص از زمان ميسازد.
هر تغيير بعدي كه براي پايگاه داده اصلي صورت ميگيرد، در Database Snapshot منعكس نميشود. برنامهها دقيقاً به يك Database Snapshot در صورتي متصل ميشود كه پايگاه داده ديگري باشد. يك Database Snapshot ميتواند براي هر پايگاه دادهاي ايجاد شود. Database Snapshotها به عنوان بخشي
از عبارت CREATE
DATABASE DDL ايجاد ميشوند. ميتوانيد
نحوه ايجاد يك ديدگاه را در پايگاه داده AdventureWorks
نمونه در اين ليست ببينيد:
CREATE DATABASE AdWSnapShot_080104_0700
ON
( NAME = AdventureWorks_Data,
FILENAME = 'C:\Program Files\Microsoft SQL Server
\MSSQL.1\MSSQL\DATA\AdventureWorks_data_040422_1800.ss')
AS SNAPSHOT OF AdventureWorks;
در اين مثال، ميتوانيد ببينيد كه يك Database Snapshot به نام AdWSnapShot_080104_0700
در پايگاه داده AdventureWorks ايجاد شده است. Database Snapshotها با استفاده از
بخش AS
SNAPSHOT OF ايجاد ميشوند كه
ميتوانيد در ليست ميبينيد. هنگام ايجاد يك Database Snapshot، بايد تمام فايلهاي دادهاي را مشخص كنيد كه در پايگاه داده منبع
استفاده ميشوند. با توجه به اين كه پايگاه داده AdventureWorks شامل يك فايل داده است، تنها فايل AdventureWorks_Data بايد به عبارت CREATE DATABASE
مشخص شود. فايلهاي ثبت را مشخص نكنيد.
ايجاد يك Database Snapshot يك عمل كم هزينه است، همانگونه كه سرور اصولاً از فوق داده در
الحاق با بازيافت براي ايجاد نقطه ديد استفاده ميكند. درك اين مسأله مهم است كه Database Snapshotها، كپي كاملي از
يك پايگاه داده نيستند. در عوض، ايجاد يك Database Snapshot
يك عمل فقط فوق داده است. يك Database Snapshot
از همان صفحات داده مشابه پايگاه داده اصلي استفاده ميكند، بنابراين نيازي به
مقدار زيادي فضاي ديسك اضافي نيست. Database Snapshotها با استفاده از
فناوري كپي و نوشتن ساخته ميشوند كه هر زماني كه تغييري در يكي از صفحات داده
پايگاه داده منبع صورت ميگيرد، يك كپي از آن صفحه براي Database Snapshot ذخيره شده و سپس صفحه بهنگام شده به همان روش طبيعي نوشته ميشود.
هنگامي كه Database Snapshot مورد دستيابي قرار ميگيرد، از صفحات داده مشترك استفاده ميكند،
تا وقتي كه به صفحه تغيير يافته برسد و سپس صفحاتي را بررسي خواهد كرد كه كپي شدهاند
و نه صفحات دادهاي كه حاوي داده بهنگام شده هستند. در اين روش، Database Snapshot نياز به حافظهاي براي تنها صفحاتي دارد كه از زمان ايجاد Database Snapshot تغيير يافتهاند. شكل 3-3 چگونگي كار كردن Database Snapshotها را نشان ميدهد.
شكل 3-3 Database Snapshotها
Database Snapshotها ميتوانند با Database Mirroring براي ايجاد يك سرور گزارشگيري برطبق دادهاي كه در سرور قرينه
وجود دارد، تركيب شوند (شكل 4-3). طبيعتاً، داده در سرور قرينه هميشه در حالت
بازيافت است، بنابراين نميتواند توسط يك برنامه مورد دستيابي قرار گيرد. هرچند،
ميتوانيد يك Database
Snapshot را ايجاد كنيد كه
بر طبق پايگاه داده قرينه باشد و آن Database Snapshot
ميتواند در حالت فقط خواندني براي گزارشگيري مورد دستيابي قرار گيرد.
هر چند پايگاه داده در سرور قرينه نميتواند
مستقيماً مورد دستيابي قرار گيرد، زيرا در يك حالت بازيافت در حال پيشرفت است كه
بر Database
Snapshot تأثيري نميگذارد
كه به يك تصوير فوري از صفحات داده در پايگاه داده سرور قرينه دستيابي دارد. ايجاد
يك Database
Snapshot در سرور قرينه به
شما امكان ميدهد تا توان پردازشي سرور قرينه را با امكان انتقال گزارش ايستا به
آن سرور بهتر به كار بريد. هنگام استفاده از Database Snapshotها در يك Database Mirroring بايد به رويداد يك failover
توجه داشته باشيد و Database Snapshotها موجودي كه در سرور قرينه ايجاد شدهاند،
بيعيب و نقص باقي خواهند ماند.
شكل 4-3 Database Mirroring و Database
Snapshot يك سرور گزارشگيري
را ايجاد ميكنند.
تشخيص اين نكته حايز اهميت است كه Database Snapshotها يك ويژگي در
دسترس بودن هستند و يك ويژگي failover
آنها روشهاي بيشتري براي دستيابي به داده شما فراهم ميكنند و در دسترس بودن
داده شما را افزايش ميدهند. آنها يك ويژگي failover نيستند (اگر پايگاه داده اصلي در دسترس نباشد، Database Snapshot نيز در دسترس نخواهد بود).
Early
Restore Access
هر بار كه پايگاه داده SQL Server شروع ميشود يا يك پايگاه داده بازيابي ميگردد، آن پايگاه داده
بايد به دورهاي از بازيافت برود كه هر تراكنشي كه در ثبت است، بر فايلهاي داده
اعمال ميشود. فاز بازيافت معمولاً redo
گفته ميشود. به محض اين كه بخش redo
فرآيند بازيافت كامل ميشود، تمام عمليات undo
انجام ميگردد، زيرا تمام تراكنشهاي ناقص در ثبت وقايع roll back ميشوند. در SQL Server 2000،
پايگاه داده در دسترس نبود، تا وقتي كه تمام عمليات redo و undo كامل ميشدند. اگر پايگاه دادهاي مختل ميشد، در حالي كه فعال
بود و آن پايگاه داده بسيار مشغول بود، آنگاه قبل از اين كه پايگاه داده مجدداً
در دسترس قرار گيرد، يك تأخير طولاني را داشتيم، زيرا بايد تا زماني كه تمام وروديها
در ثبت وقايع پردازش ميشدند، منتظر ميمانديد.
Early Restore Access جديد SQL Server 2005
به پايگاههاي داده امكان ميدهد تا بلافاصله بعد از كامل شدن بخش redo فرآيند بازيافت، در دسترس قرار گيرد. در SQL Server 2005، هنگاميكه پايگاه داده مجدداً شروع ميشود، تمام تراكنشهاي بازي
كه در ثبت وقايع هستند، مجدداً انجام شده و سپس پايگاه داده بلافاصله در دسترس
قرار ميگيرد. نتيجه دقيق اين است كه پايگاه داده خيلي زودتر در دسترس قرار ميگيرد.
براي تراكنشهايي كه Commit
نشده باشند، SQL
Server هنوز قفلهايي را
روي صفحات داده مورد استفاده اين تراكنشها نگهداري ميكند، بنابراين حتي اگر
پايگاه داده در حال استفاده باشد، مستحكم باقي خواهند ماند. سپس SQL Server 2005 فرآيند undo
كردن اين تراكنشها را در حالت فعال بودن پايگاه داده شروع ميكند. كاربران ميتوانند
عمليات خواندن/ نوشتن پايگاه داده را در طي فاز undo بازيافت شروع كنند. هرچند، هر تلاشي در طي فرآيند Undo، براي دستيابي به دادهاي كه SQL Server قفل كرده است، موجب بلوكه شدن خواهد شد تا وقتي كه فرآيند undo قفلهاي روي آن داده را رها كند. شكل 5-3 تفاوت در دسترسپذيري
بين SQL
Server 2000 و SQL Server 2005 را نشان ميدهد.
شكل 5-3 Early Restore
Access
عمل RESTORE حالا سنجيدهتر است و برد عمل redo را تعريف ميكند. ميتوانيد پشتيبانهاي كامل، جزيي يا گروه فايل
را بازيابي كنيد. اگر نشان دهيد كه ميخواهيد يك گروه فايل را بازيابي كنيد، آنگاه
تنها آن داده گروه فايل به عمل roll-forward
اضافه ميشود. اگر نشان دهيد كه ميخواهيد يك پشتيبان كامل را بازيابي كنيد، آنگاه
تمام داده در مجموعه پشتيبان، براي عمل redo
استفاده خواهد شد.
عمليات
ايندكس به صورت online
در نگارشهاي قبلي SQL Server هنگامي كه ايندكسي بازسازي ميشد، نميتوانستيد هيچ عمل بهنگامرساني
را روي جدول انجام دهيد تا وقتي كه بازسازي ايندكس خاتمه مييافت. ويژگي عمليات
ايندكس online جديد SQL Server 2005، در دسترس بودن SQL Server
را با دادن امكان بهنگامرساني، درج و حذف رديفها از جدول در هنگام بازسازي
ايندكس به برنامهها، توسعه داده است. ويژگي ايندكس online جديد، اين جادو را با حفظ دو كپي از ايندكس انجام ميدهد: يكي كه
برنامهها ميتوانند به استفاده از آن ادامه دهند و ايندكس موقت دومي كه هنگام
بازسازي ايندكس استفاده ميشود. موتور SQL Server
هر دو ايندكس را با تمام تغييرات هنگام انجام بازسازي نگهداري ميكند. هنگام اتمام
بازسازي، ايندكس قديمي حذف شده و با ايندكس جديد جايگزين ميشود. بازسازي ايندكس Online براي عبارات CREATE INDEX،
ALTER
INDEX REBUILD، ALTER INDEX
DISABLE، DROP INDEX، ALTER
TABLE ADD CONSTRAINT و ALTER TABLE DROP
CONSTRAINT پشتيباني ميشود.
هر چند SQL
Server 2005 هماكنون از
بازسازي ايندكس Online پشتيباني ميكند، ولي سرباري اضافي را متحمل ميشود، زيرا ميتوانيد
بازسازي ايندكسهاي خود را به صورت offline
نيز داشته باشيد.
ليست زير نشان ميدهد كه چگونه ويژگي
ايندكسگذاري online استفاده ميشود:
CREATE INDEX MyIndex ON
Person.Contact(LastName) WITH (ONLINE=ON)
در اينجا ميتوانيد ببينيد كه عبارت CREATE INDEX استاندارد براي ايجاد ايندكسي به نام MyIndex در ستون LastName
جدولي به نام PersonContact استفاده شده است كه در پايگاه داده AdventureWorks است. بخش ONLINE=ON
به ايندكس امكان ايجاد به صورت Online
را ميدهد.
فرمتهاي
Online
سنجيده
ويژگي جديد ديگري كه در دسترس بودن SQL Server 2005 را بهبود بخشيده است، توانايي انجام بازيابيهاي سنجيده است. در
حالي كه اين ويژگي بازيابيهاي سطح جدولي كه افراد مختلف از زمان SQL Server 6.5 تاكنون ديدهاند، نيست، ويژگي بازيابي سنجيده در SQL Server 2005 به شما امكان بازيابي گروه فايلهاي منتخب را در يك پايگاه داده
ميدهد، در حالي كه بقيه پايگاه داده به دسترسپذيري خود ادامه ميدهد. در SQL Server 2000، واحد اصلي در دسترس بودن پايگاه داده است. تمام اجزاي پايگاه
داده بايد سالم باشند، قبل از اين كه پايگاه داده در دسترس باشد. در SQL Server 2005، هماكنون واحد در دسترس بودن گروه فايل است. SQL Server 2005 به شما امكان ميدهد تا يك گروه فايل را در يك زمان يا حتي يك
صفحه يا گروهي از صفحات را در يك زمان بازيابي كنيد و بقيه پايگاه داده ميتواند
به در دسترس بودن ادامه دهد، مادامي كه گروه فايل اصلي بالا باشد.
رديابي
صفحه آسيب ديده
يك ويژگي جديد دقيقاً مرتبط كه با
توانايي انجام بازيابيهاي سطح صفحه با SQL Server 2005
گره خورده است، توانايي رديابي صفحات آسيب ديده است. در يك عمل
خواندن، با صفحات بدي كه مواجه ميشويم، در يك جدول رديابي ميشوند و با استفاده
از قابليت بازيابي سنجيده، ميتوانيد بازيابي را به صورت صفحه به صفحه بازيابي
كنيد، در حالي كه پايگاه داده به صورت online باقي ميماند. هر تراكنشي كه از داده يك صفحه آسيب ديده استفاده
كند، roll
back ميشود. اگر صفحه
بدي در طي rollback تراكنش برگردد، آنگاه پايگاه داده بايد مجدداً شروع شود.
اتصال
راهبري اختصاصي
ويژگي جالب ديگر در SQL Server 2005 كه به فراهم كردن دسترسپذيري بهتر كمك ميكند، اتصال راهبري
اختصاصي جديد است. اتصال راهبري اختصاصي، DBA
را با دستيابي به سرور، بدون توجه به كار بار جاري سرور مهيا ميكند. اين امر به DBA امكان دستيابي به سرور و كشتن فرآيندهاي خارج از كنترل را ميدهد.
براي شروع ابزار SQLCMD جديد در حالت راهبري اختصاصي، اين فرمان را وارد كنيد:
C:\Sqlcmd –A
براي كسب اطلاعات بيشتر درباره استفاده
از اتصال راهبري اختصاصي به فصل 1 مراجعه كنيد.
حافظه
Hot-Plug
ويژگي در دسترس بودن جديد ديگري كه ميتواند
از Windows
Server 2003 مشتق شود، حافظه Hot-Plug است. حافظه Hot-Plug به شما اجازه ميدهد تا RAM
را در حالي اضافه كنيد كه سيستم در حال اجراست. همانگونه كه ممكن است انتظار
داشته باشيد، اين ويژگي نياز به پشتيباني OS
مرتبط و محيط سختافزاري دارد. در مورد SQL Server 2005،
اين بدان معني است كه SQL Server
بايد در Windows
Server 2003 اجرا شود تا
بتواند از اين ويژگي در دسترس بودن بهره ببرد. اگر محيط از اين ويژگي پشتيباني كند،
ميتوانيد حافظه را اضافه كنيد و SQL Server 2005
قادر خواهد بود به طور پويا RAM
اضافي را تشخيص دهد، بدون اين كه نياز به reboot
سرور يا downtime داشته باشد. در حالي كه حافظه Hot-Plug به شما اجازه ميدهد تا بهطور پويا RAM را اضافه كنيد، امكان برداشتن آن ميسر نيست.
پيكربندي
پوياي بهبود يافته
تمام پيكربندي در SQL Server 2005 هم اينك پوياست، از جمله وابستگي I/O و CPU. در SQL Server 2005،
هماكنون ميتوانيد اين مقادير را تغيير دهيد و اثرات آن بلافاصله انجام خواهند
شد.
ديگر نيازي به شروع مجدد سرور نيست. علاوه
بر اين، تغييراتي در AWE[3] نيز پوياست. SQL Server 2005 ميتواند بهطور خودكار تغييرات اندازه AWE فيزيكي را بهطور پويا تنظيم كند. اين ويژگي براي كار كردن در
الحاق با توانايي استفاده از حافظه Hot-Plug
طراحي شده است. اين ويژگي نياز به Windows Server 2003 دارد.
سطوح
جداسازي تراكنش SQL Server
ناحيه ديگري كه بر قابليت پايگاه داده
تأثير ميگذارد، سطح جداسازي تراكنش است كه توسط برنامه مورد استفاده قرار ميگيرد.
SQL
Server 2005 سطح جديدي از
تراكنش به نام Snapshot
Isolation را فراهم كرده است
كه انعطافپذيري بيشتري را براي دستيابي داده به آن ميدهد. چهار سطح جداسازي ANSI استانداردي كه در نگارشهاي قبلي SQL Server از آنها پشتيباني ميشد (Serializable،
Repeatable، Read
Committed، Read Incommitted) همگي از تراكنشهاي يكي ديگر با قفلگذاري روي رديفهاي داده
مرتبط محافظت ميكنند، بنابراين ساير برنامهها نميتوانند داده را تغيير دهند. هنوز
هم از اين سطوح تراكنش پشتيباني ميشود. Snapshot Isolation
جديد در دسترس بودن داده بيشتري را براي خواندن برنامهها فراهم ميكند. با Snapshot Isolation، SQL
Server 2005 نوعي از قفلگذاري
بهينه را انجام ميدهد كه SQL Server
هيچ قفلي را روي رديفهاي موجود در يك تراكنش نميگذارد. در عوض، رد حالت رديف را
هنگام باز شدن تراكنش حفظ ميكند. هنگامي كه يك تراكنش Snapshot باز ميشود، سيستم لزوماً داده رديف را براي تراكنش كپي ميكند و
به برنامه شما امكان ميدهد تا مشاهده داده رديف را ادامه دهد، زيرا در زمان شروع
تراكنش قرار داشته است. هيچ قفلي روي رديفها قرار داده نميشود. اين امر خواندنهاي
مستحكم بلوكه نشده را در يك برنامه OLTP
ممكن ميسازد. به دليل اين كه Snapshot Isolation
هيچ قفلي را نگهداري نميكند، نويسندههاي داده، خوانندهها و خوانندهها، نويسندهها
را بلوكه نميكنند. سطح Snapshot Isolation
جديد واقعاً براي برنامههايي است كه تأكيد بر عمليات خواندن دارند. هنگامي كه
برنامه شما، رديفها را در يك تراكنش ميخواند، ممكن است داده قديمي را بخواند،
زيرا ساير برنامهها قادر به تغيير داده هستند. در حالي كه اين سطح جداسازي جديد،
نوشتنها را ميسر نميسازد، سربار اضافي در تمام بهنگامرسانيها وجود دارد. Snapshot Isolation هنگامي مفيد است كه نياز به يك ديدگاه مستحكم زماني از تمام داده
در پايگاه داده خود داريد. براي برنامههاي بهنگامرساني، Snapshot Isolation در روشهايي كه هزينه قفلگذاري بيش از هزينه roll back كردن يك تراكنش است، بهترين كاربرد را دارد.
پشتيبانگيري
و بازيابي
SQL Server 2005
همچنين چند ويژگي جديد را در ناحيه فناوري پشتيبانگيري و بازيابي در برميگيرد.
در حالي كه تعدادي از ويژگيهاي در دسترس بودن قبل مربوط به برخي از اين ويژگيهاي
پشتيبانگيري و بازيابي بود (به ويژه عمليات Online سنجيده)، اين بخش در اصل بر تغييراتي تمركز دارد كه مايكروسافت
براي مستحكمتر و آسانتر ساختن پيادهسازي فرآيند پشتيبانگيري و بازيابي صورت
داده است.
بازيابي
جزيي
در SQL Server 2000، پايگاه داده در طي عمل بازيابي در دسترس نبود. در SQL Server 2005، پايگاه داده به محض بازيابي گروه فايل اصلي، online است. تنها داده بازيابي شونده در دسترس نيست. اگر كاربر به دادهاي
دستيابي داشته باشد كه در گروه فايل اصلي باشد، عمل به صورت موفق انجام ميشود،
بدون اين كه چيزي به كاربر نشان داده شود و بازيابي بقيه پايگاه داده را بيان كند.
اگر كاربر تلاش كند تا به داده يك گروه فايل دستيابي داشته باشد كه هم اينك در حال
بازيابي است يا هنوز offline
است، آنگاه پايگاه داده پيامي را برخواهند گرداند كه بيانگر offline بودن داده است.
بهبودهاي
قابليت اتكاي رسانه
SQL Server 2005
همچنين بهبودهايي را در روش ارتباط با رسانه فراهم كرده است. به ويژه، هم اينك
انجام پشتيبانگيريها براي وسايل قرينه را ميسر ميسازد، جامعيت checksum بهبود يافته را فراهم ميكند و ادامه عمل بازيابي را ممكن ميسازد،
حتي اگر با خطايي مواجه شود.
پشتيبانگيري
قرينهسازي رسانه
يكي از ويژگيهاي قابليت اتكاي رسانه
جديد در SQL
Server 2005، توانايي پشتيباني
از قرينهسازي رسانه است. قرينهسازي رسانه به شما امكان ميدهد تا بهطور همزمان
يك پشتيبانگيري را براي چند وسيله پشتيبانگيري انجام دهيد. مثلاً، ميتوانيد از
پايگاه داده خود براي tape1
و tabe2 در يك زمان پشتيبانگيري كنيد و دو كپي يكسان از مجموعه پشتيبان
داشته باشيد. رسانه پشتيبانگيري اضافي، يك ضامن استاندارد است كه ميتواند به
محافظت از سازمان شما از خطاهاي رسانهاي كمك كند و كمك ميكند تا از توانايي
انجام يك بازيابي موفق مطمئن شويد. اين مثال، كاربرد ويژگي قرينهسازي رسانه جديد
را تشريح ميكند:
BACKUP DATABASE AdventureWorks TO
TAPE='\\.\tape1'
MIRROR TO
TAPE='\\.\tape2'
WITH FORMAT, MEDIANAME = 'ADWBackup'
اين مثال نشان ميدهد كه پايگاه داده AdventureWorks بر روي tape1
پشتيبانگيري كرده و بر روي tape2
قرينهسازي نموده است. كارآيي پشتيبانگيري متأثر از افزودن يك قرينه پشتيبان
نيست. ميتوان تا چهار قرينه را بر يك پشتيبان اعمال كرد.
تأييد
پشتيبانهاي بهبود يافته
در SQL Server 2000، استفاده از فرمان RESTORE VERIFYONLY
تنها باعث ميشود SQL
Server نوار را بدون هيچ
كار اضافهاي در فرآيند بازيابي بخواند. استفاده از فرمان RESTORE VERIFYONLY در SQL Server 2005
هر كاري در مورد بازيابي واقعي در رسانه بازيابي را بهطور مختصر انجام ميدهد و
ايده بهتري در مورد امكان موفقيت داده در مجموعه پشتيبان به شما ميدهد.
ادامه
خطاهاي بازيابي گذشته
بهبود قابليت اتكاي رسانه جديد ديگر،
توانايي عمل بازيابي براي ادامه دادن خطاهاي رسانهاي گذشته است. نگارشهاي قبلي SQL Server، در صورت مواجه شدن با خطا در طي فرآيند بازيابي، از عمل بازيابي
صرفنظر ميكردند. هرچند، در مواردي كه اين تنها نگارش رسانه موجود بود، ممكن بود
مانع جدي براي بازيافت داده موجود باشد. با اين ويژگي جديد، SQL Server 2005 ادامه فرآيند بازيابي را تا حد امكان ميسر ميسازد. و از خطاهاي
رسانهاي كه با آنها مواجه ميشود، صرفنظر ميكند. بعد از خاتمه فرآيند بازيابي،
پايگاه داده ميتواند بهطور دستي مرمت شود.
Database
Page Checksums
ويژگي Database Page
Checksums جديد به پايگاه
داده امكان ميدهد تا خطاهاي I/O
و ديسك را كه توسط زيرسيستم ديسك گزارش نشدهاند، تشخيص دهد. هنگامي كه ويژگي Database Page
Checksums فعال ميشود، SQL Server يك مقدار Checksum
را هنگام نوشتن صفحه روي ديسك محاسبه كرده و آن Checksum را به همراه داده مينويسد. هنگامي كه صفحه خوانده ميشود، Checksum ديگري محاسبه شده و با Checksum
اولي كه با داده نوشته شده است، مقايسه ميكند. اگر آن دو متفاوت باشند، خطايي
گزارش ميشود. فرمان زير نشان ميدهد كه چگونه Database Page
Checksums ميتواند به يك
پايگاه داده موجود اضافه شود:
ALTER DATABASE AdventureWorks
SET PAGE_VERIFY CHECKSUM
پشتيبانهاي
log
و پايگاه داده همزمان
ويژگي جديد ديگر در ناحيه پشتيباني SQL Server 2005، توانايي انجام همزمان پشتيبانهاي log و پايگاه داده است. با استفاده از SQL Server 2000، بايد منتظر پشتيبانگيري log
بمانيد تا وقتي كه پشتيبانگيري پايگاه داده كامل شود. در SQL Server 2005، پشتيبانهاي پايگاه داده ديگر پشتيبانهاي block log نيستند. در ضمن، همچنين ميتوانيد از فايلها و گروههاي فايل در
همان زماني پشتيبانگيري كنيد كه از log
تراكنش پشتيبانگيري ميكنيد. هرچند، محدود به انجام پشتيبانگيري
از يك فايل داده در زماني در هر پايگاه داده هستيد.
پشتيبانگيري
از كاتالوگهاي Full-Text
يك بهبود پشتيبانگيري ديگري كه بخشي از SQL Server 2005 است، توانايي پشتيبانگيري از كاتالوگهاي Full Text است. در SQL Server 2000،
داده كاتالوگ Full
Text خارج از SQL Server توسط سرويس جستجوي مايكروسافت نگهداري ميشد. پشتيبانگيري از
پايگاه داده SQL
Serverاي
كه حاوي داده Full-Text است كه بهطور خودكار موجب پشتيبانگيري از كاتالوگ Full-Text نميشود. اين امر امكان خارج از هم زماني بودن كاتالوگ را در مورد
داده Full-Text بازيابي شونده مطرح ميكند. SQL Server 2005 اين مشكل را با داشتن توانايي پشتيبانگيري خودكار از تمام كاتالوگهاي
Full-Text خارجي در همان زمان پشتيبانگيري از پايگاه داده برطرف ميكند.
اين امر اطمينان ميدهد كه كاتالوگ Full-Text
و داده بين عمليات پشتيبانگيري و بازيابي مستحكم باقي ميمانند. فرامين DATABASE ATTACH و DEATTACH نيز داراي گزينهاي براي داشتن تمام كاتالوگهاي Full-Text هستند. لينكها در پايگاه داده به فايلهاي خارجي مورد استفاده
اشاره ميكنند. هنگامي كه از پايگاه داده پشتيبانگيري ميشود، از اين فايلهاي
خارجي نيز پشتيبانگيري ميشود كه استحكام پايگاه داده را اطمينان ميدهد.