ويژگي‌هاي معماري پايگاه داده و موتور حافظه

اين نسخه از SQL Server بر طبق معماري ضروري مشابه با آن‌چه كه در نسخه‌ 7 از SQL Server توليد مي‌شد، ساخته شده است و مايكروسافت به انجام بهبودهاي انقلابي در موتور SQL Server ادامه مي‌دهد. طبق قانون مور، ظرفيت سخت‌افزاري در هر 18 ماه دو برابر مي‌شود، در حالي كه در همان مدت زماني، هزينه‌هاي سخت‌افزاري كاهش مي‌يابد. هرچند، در حالي كه سخت‌افزار ارزان‌تر مي‌شود، هزينه‌هاي مردم بيشتر مي‌شود. در نسخه SQL Server 2005، مايكروسافت بهبودهايي را صورت داده است كه به SQL Server امكان مي‌دهند تا از جديدترين نسل‌هاي سخت‌افزار با كارآيي بالا بهره ببرند و اين قابليت را براي آن‌ها فراهم كرده است كه خود را به اوج محصولات جهاني برسانند. هم‌زمان، اين شركت ويژگي‌هايي را اضافه كرده است كه مديريت آن‌ها توسط SQL Server آسان‌تر است و هم‌چنين قابليت‌هاي جديدي را فراهم نموده است كه به شما امكان مي‌دهد تا ارزش بيشتري براي SQL Server در سازمان خود قايل شويد. در اين فصل، برخي از مهم‌ترين بهبودها را از نظر معماري كه مايكروسافت در SQL Server 2005 صورت داده است، معرفي خواهيم كرد، با اين هدف كه به شما كمك كنيم تا ببينيد اين ويژگي‌ها چگونه مي‌توانند بهره‌وري شما و قابليت اعتماد محيط پايگاه داده را بهبود بخشند.

پشتيباني سخت‌افزاري جديد

يكي از ويژگي‌هاي جديد كليدي كه به SQL Server 2005 به عنوان يك موتور پايگاه داده اجازه مي‌دهد تا سطوح كارآيي يكساني با بزرگ‌ترين پايگاه‌هاي داده UNIX داشته باشد، پشتيباني سخت‌افزار بهبود يافته آن است. حافظه هميشه يكي از حياتي‌ترين عواملي بوده است كه در كارآيي پايگاه داده تأثير داشته است و پايگاه‌هاي داده بزرگ UNIX كه رتبه‌بندي كارآيي TPC-C كلاستر فشرده بالايي دارند، همگي به سطح كارآيي با استفاده از يك سخت‌افزار 64 بيتي و محيط سيستم عامل توجه داشته‌اند. هنگامي كه يك محيط 64 بيتي قابل مقايسه براي SQL Server به شكل پردازنده Intel Itanium2 64 بيتي و پشتيباني 64 بيتي طبيعي Windows Server 2003 در دسترس قرار مي‌گيرد، SQL Server بلافاصله به رأس آزمون كارآيي TPC-C منتقل مي‌شود. SQL Server 2005 اين پشتيباني 64 بيتي طبيعي را به همراه قابليتي براي پشتيباني از NUMA[1] از Windows Server 2003 به ارث مي‌برد. SQL Server كه بر طبق محيط Windows Server 2003 ساخته شده است، پشتيباني 64 بيتي را براي معماري Itanium IA64 و معماري AMD x64 فراهم كرده است.

پشتيباني 64 بيتي طبيعي

هنگام اجرا در Windows Server 2003 براي سيستم‌هاي Itanium 64 بيتي، SQL Server 2005 از پردازنده‌هاي Itanium و Itanium2 اينتل پشتيباني مي‌كند. هنگام اجرا در Windows Server 2003 براي Extended Systems 64 بيتي، SQL Server 2005 از پردازنده‌هاي Opteron 64 بيتي AMD و AMD Athlon 64 و Xeon اينتل با EMT64[2] پشتيباني مي‌كند. SQL Server 2005 كاملاً از محيط‌هاي سخت‌افزاري 32 و 64 بيتي براي تمام سرويس‌هاي عمده آن‌ها، از جمله SQL Server Engine، Analysis Services، SQL Agent و Reporting Services پشتيباني مي‌كند. مزيت واقعي در انتقال يك پايگاه داده به محيط 64 بيتي، توان پردازش سريع‌تر نيست. در عوض، مزيت واقعي در حافظه قابل آدرس‌دهي افزايش يافته نهفته است. شكل 1-1 مقايسه‌اي از حداكثر حافظه قابل آدرس‌دهي براي SQL Server 32 بيتي و نگارش 64 بيتي SQL Server 2005 نشان مي‌دهد.

معماري 32 بيتي طبيعي به حداكثر 4GB حافظه قابل آدرس‌دهي محدود است. تحت Windows، اين حد 4GB حتي بين سيستم عامل و برنامه‌ها تقسيم مي‌شود. به عبارت ديگر، 2GB براي سيستم عامل Windows رزرو شده است و 2GB براي برنامه‌ها باقي‌مي‌ماند. با استفاده از پشتيباني AWE در نگارش 32 بيتي، SQL Server مي‌تواند حداكثر 32GB از RAM را آدرس‌دهي كند. در حالي كه اين افزايش واقعي است، باز هم سربار صفحه‌بندي براي داشتن صفحات حافظه مناسب وجود دارد. پياده‌سازي 64 بيتي طبيعي، محدوديت حافظه را با افزايش حداكثر حافظه قابل دسترسي به 32TB به‌طور مجازي برطرف كرده است. در حال حاضر، هيچ سيستم توليدي در هيچ جايي، از اين مقدار RAM فيزيكي پشتيباني نمي‌كند. حداكثر مقدار RAM فيزيكي كه SQL Server 2005 در زمان عرضه با آن تست شده است، 512GB است. با نسخه بعدي بسته خدماتي بعدي براي Windows Server 2003، انتظار مي‌رود حداكثر حافظه مورد پشتيباني تا 1 TB افزايش يابد.

شكل 1-1 مقايسه آدرس‌دهي حافظه 32 و 64 بيتي

پشتيباني NUMA

ويژگي جديد ديگري كه سيستم عامل Windows Server 2003 انجام مي‌دهد، پشتيباني NUMA[3] است. NUMA معماري سيستمي مورد استفاده برخي توليد كنندگان سيستم از قبيل IBM و Unisys است كه كاربرد حافظه و CPU را در سيستم‌هاي چند پردازنده‌اي كارآمدتر از معماري SMP معمولي مديريت مي‌كند. در سيستم‌هاي SMP استاندارد، هنگامي كه سرعت و تعداد پردازنده‌ها افزايش مي‌يابد، رقابت بين پردازنده‌ها براي دستيابي به حافظه موجب رقابت گذرگاه مي‌شود. اين امر موجب تأخيرهايي در پردازش شده و قابليت يك سيستم را براي مقياس‌بندي دچار مشكل مي‌كند. نتيجه اين امر اين است كه سيستم‌هاي SMP در صورت افزايش تعداد پردازنده‌ها، به‌طور خطي مقياس‌بندي نمي‌شوند. معماري NUMA براي حل اين مشكل در سيستم‌هاي SMP طراحي شده است كه در آن، پردازنده‌ها قادر به دستيابي سريع‌تر به داده در RAM گذرگاه سيستمي كه مي‌تواند آن را فراهم كند، هستند. معماري NUMA، CPU و حافظه را در podهاي محلي چند پردازنده گروه‌بندي مي‌كند. اين podها از طريق يك گذرگاه خارجي به يكديگر متصل مي‌شوند كه ترافيك داده چند pod را منتقل مي‌كند. اين آرايش Pod، مسأله رقابت را با محدود كردن تعداد CPUهاي رقيب براي دستيابي به حافظه، برطرف مي‌كند. براي تشخيص حداكثر مزاياي اين معماري، سيستم عامل و برنامه‌ها بايد طوري طراحي شوند تا ترافيك داده چند podاي را حداقل كرده و دستيابي حافظه داخل pod سريع را حداكثر كنند. اگر سيستم‌عامل و برنامه به‌طور صحيح طراحي شده باشند، معماري NUMA مقياس‌بندي تقريباً خطي را ممكن مي‌سازد، هنگامي كه پردازنده‌هاي بيشتري اضافه شوند. Windows Server 2003 و SQL Server 2005 بهبودهاي معماري را براي افزايش درجه‌اي كه رشته‌ها و حافظه استفاده مي‌كنند و در همان pod قرار دارند، مشاركت مي‌دهد.

پشتيباني از Hyper-Threading

SQL Server 2005 هم‌چنين مي‌تواند از Hyper-Threading بهره ببرد و ما بايد ممنون مايكروسافت باشيم كه Hyper-Threading را به Windows Server 2003 اضافه كرده است. Hyper-Threading يك فناوري CPU است كه توسط اينتل توسعه يافته است و دو پردازنده منطقي را براي هر پردازنده فيزيكي در يك سيستم ايجاد مي‌كند. هر پردازنده منطقي، قادر به اجراي هم‌زمان رشته‌هاي مجزاست. هدف Hyper-Threading فراهم كردن مصرف منبع بهتر براي برنامه‌هاي چند رشته‌اي يا چندين برنامه در حال اجرا روي يك ماشين است. در حالي كه Hyper-Threading پتانسيل افزايش بازده در يك سرور را فراهم مي‌كند، پردازنده‌هاي منطقي براي منابع سيستم از قبيل داده در كش پردازنده رقابت مي‌كنند. اين رقابت براي منابع مانع از انجام كار Hyper-Threading CPU شده و استفاده از دو CPU فيزيكي توسط سيستم قابل مقايسه مي‌شود.

SQL Server 2005 دو مزيت عمده را از پشتيباني Windows Server 2003 براي Hyper-Threading مي‌گيرد. اول اين كه، برخلاف Windows 2000، Windows Server 2003 تنها پردازنده‌هاي فيزيكي را براي اهداف تعيين مدرك به حساب مي‌آورد. بنابراين، يك پردازنده تكي با استفاده از Hyper-Threading، به عنوان يك پردازنده تكي تعيين مي‌شود و نه يك پردازنده دوم كه تحت Windows 2000 چنين بود. سپس، Windows Server 2003 زمان‌بندي رشته‌اي بهبود يافته را براي سيستم‌هاي Hyper-Threading شده فراهم كرده است. اين تغييرات موجب كارآيي بهتر براي برنامه‌هاي چند رشته‌اي نظير SQL Server مي‌شوند.

SQL Server Engine

در حالي كه اولين بخش اين فصل، تصوير بزرگ‌تري از پشتيباني سخت‌افزاري جديد فراهم شده در SQL Server 2005 را بررسي كرد، اين بخش به بررسي عمقي برخي از مهم‌ترين بهبودهايي مي‌پردازد كه مايكروسافت در خود SQL Server Engine صورت داده است.

يكپارچگي .NET Framework

مهم‌ترين بهبود موتور SQL Server در SQL Server 2005، يكپارچگي Microsoft .NET Framework است. يكپارچگي .NET Framework با SQL Server، قابليت SQL Server 2005 را با امكان ساخت رويه‌هاي ذخيره شده، توابع تعريف شده كاربر، تريگر‌ها، انبوهه‌ها و انواع تعريف شده كاربر با استفاده از هر يك از زبان‌هاي .NET، از قبيل VB.NET، C# يا J# توسعه داده است. يكپارچگي .NET CLR با SQL Server 2005، بيش از يك مسأله سطحي است، زيرا موتور پايگاه داده SQL Server از CLR در فرآيند ميزباني مي‌كند. مي‌توانيد در فصل 4 مطالب بيشتري در اين زمينه بياموزيد.

پشتيباني چند نمونه‌اي بهبود يافته

بهبود مهم ديگر در ويرايش Enterprise از SQL Server 2005، پشتيباني براي حداكثر تا 50 نمونه است. اين مسأله در SQL Server 2000، 16 نمونه بود. اين بهبود مهم خاصي براي ميزباني از فروشندگاني است كه چند سرويس SQL Server را به عنوان بخشي از ارايه سرويس‌هاي وب خود اجاره مي‌دهند.

انواع داده جديد

SQL Server 2005 هم‌چنين از چند نوع داده جديد پشتيباني مي‌كند. در حالي كه يكپارچگي .NET Framework ، پشتيباني براي انواع تعريف شده كاربر را ممكن مي‌سازد، SQL Server 2005 نيز يك جفت از انواع داده طبيعي جديد را فراهم كرده است: انواع داده XML و varbinary(max). نوع داده varbinary(max) متد جديدي را براي استفاده از LOBها با SQL Server فراهم مي‌كند. برخلاف انواع داده Image و Text قديمي‌تر، نوع داده varbinary(max) جديد مي‌تواند به عنوان يك متغير استفاده شود و با برنامه‌نويسي مي‌تواند با آن همانند انواع داده كوچك‌تر رفتار كرد كه اين امر موجب روش‌هاي كاربرد آسان‌تر و مستحكم‌تر مي‌شود.

نوع داده XML جديد برطبق نوع داده varbinary(max)، به شما امكان ذخيره اسناد XML را در پايگاه داده مي‌دهد. هرچند، نوع داده XML جديد براي داده XML طراحي شده است و از تأييد طرح‌واره اسناد XML پشتيباني مي‌كند. مي‌توانيد در فصل 7 مطالب بيشتري درباره انواع داده جديد مورد پشتيباني SQL Server 2005 بياموزيد.

تصويرگيري و قرينه كردن پايگاه داده

قرينه كردن پايگاه داده[4] موجب محافظت از خرابي پايگاه داده با دادن يك قابليت standby پايگاه داده ثابت به SQL Server 2005 مي‌شود. قرينه كردن پايگاه داده يك فناوري در دسترس بودن سطح پايگاه داده است كه با تمام سخت‌افزارهاي استاندارد مورد پشتيباني SQL Server كار مي‌كند. هيچ نيازي براي هر حافظه مشترك بين سرور اصلي و سرور قرينه وجود ندارد و هيچ محدوديت فاصله‌اي نيز وجود ندارد. قرينه كردن پايگاه داده با ارسال ثبت وقايع تراكنش بين سرور اصلي و سرور قرينه كار مي‌كند. اصولاً ويژگي قرينه كردن پايگاه داده، يك برنامه انتقال ثبت بلادرنگ را مي‌سازد. قرينه كردن پايگاه داده مي‌تواند در يك يا چند پايگاه داده تنظيم شود.

Database Snapshot يك تصوير فقط خواندني از يك پايگاه داده را در نقطه خاصي در زمان فراهم مي‌كند. Database Snapshot براي ايجاد كپي‌هايي از يك پايگاه داده براي گزارش‌گيري يا ايجاد كپي‌هاي پشتيبان از يك پايگاه داده مناسب است كه مي‌توانيد براي roll back كردن يك پايگاه داده توليدي با حالت قبلي آن استفاده كنيد. Database Snapshot مي‌تواند با Database Mirroring براي ايجاد يك سرويس گزارش‌گيري برطبق داده موجود در سرور قرينه تركيب شود. داده در سرور قرينه نمي‌تواند مستقيماً مورد دستيابي قرار گيرد، زيرا سرور قرينه هميشه در حالت بازيافت است. هرچند، مي‌توانيد يك Database Snapshot را در پايگاه داده قرينه ايجاد كرده و آن‌گاه براي گزارش‌گيري به ديدگاه پايگاه داده دسترسي داشته باشيد. در فصل 3 مطالب بيشتري درباره قرينه كردن و ديدگاه‌هاي پايگاه داده مي‌آموزيد.

پشتيباني HTTP طبيعي

يكي از بهبودهاي مهم ديگر موتور پايگاه داده SQL Server، الحاق پشتيباني HTTP طبيعي به خود موتور است. قابليت SQL Server براي پردازش درخواست‌هاي HTTP ورودي، به SQL Server امكان فراهم كردن اجراي عبارت SQL و احضار رويه ذخيره شده را از طريق پروتكل SOAP مي‌دهد. اين بدان معني است كه SQL Server 2005 قادر به پردازش درخواست‌هاي سرويس وب ورودي بدون وجود IIS يا سرور وب ديگري است. پشتيباني HTTP جديد قابليت‌هاي استماع HTTP طبيعي را به SQL Server مي‌دهد، از جمله قابليت پشتيباني از نقاط انتهايي HTTP كه URL پورت و درخواست‌هايي را كه پشتيباني خواهند شد، مشخص مي‌كنند. SQL Server هم‌چنين قادر به انتشار سرويس‌هاي وب به عنوان WSDL[5] براي نقاط انتهاست. پشتيباني SQL Server HTTP سازگار با استانداردهاست، و از SOAP و نگارش‌هاي 1.0 و 1.2 و WSDL 1.1 پشتيباني مي‌كند. ويژگي پشتيباني، HTTP طبيعي جديد، هم‌چنين از تعيين هويت SQL Server و Windows و SSL پشتيباني مي‌كند. براي فعال كردن اين ويژگي براي داشتن سازگاري بيشتر با برنامه‌نويسي رديف مياني، رويه‌هاي ذخيره شده مي‌توانند مجموعه نتايج را به عنوان يك ADO.NET DataSet برگردانند.

Server Events و DDL Triggers

ويژگي‌هاي Server Events و DDL Triggers جديد SQL Server 2005 به شما امكان مي‌دهند تا با برنامه‌نويسي به تغييرات در سيستم پاسخ دهيد. در حالي كه هر دوي اين ويژگي‌هاي جديد مي‌توانند اعمال مشابهي را انجام دهند، به‌طور كاملاً متفاوتي پياده‌سازي مي‌شوند. تريگرهاي DDL، شبيه تريگرهاي DML استاندارد، رويدادهاي هم‌زماني هستند كه رويه‌هاي ذخيره شده را اجرا مي‌كنند. در فصل 4، مطالب بيشتر درباره تريگرهاي DDL مي‌آموزيد.

در مقايسه، رويدادهاي سرور غيرهم‌زمان هستند. در مدل رويدادي سرور، سرور يك رويداد را براي يك SQL Broker Service ثبت مي‌كند و آن‌گاه يك مصرف كننده مي‌تواند به‌طور مستقل آن رويداد را بازيابي كند. خود رويداد به عنوان داده XML ثبت مي‌شود. هيچ روشي براي roll back كردن يك رويداد وجود ندارد و در صورتي از يك رويداد صرف‌نظر مي‌شود كه هيچ مصرف كننده‌اي آن را بازيابي نكند. هنگامي كه رويدادي رخ مي‌دهد، رويداد سيستم فعال مي‌شود كه مي‌تواند شما را از رويداد يا اجراي اختياري يك روال كد مطلع كند. مثال زير ساختار دستوري مورد استفاده براي تنظيم يك هشدار رويداد را تشريح مي‌كند:

CREATE EVENT NOTIFICATION MyDDLEvents

ON SERVER FOR DDL_STATEMENTS TO SERVICE MyDDL_log

اين مثال رويداد جديدي را ايجاد كرده و هشدار رويداد را MyDDLEvents مي‌نامد و رويداد را به عبارت DDL متصل مي‌كند. بخش TO SERVICE مشخص مي‌كند كه SQL Broker Service با نام MYDLL_log دريافت كننده رويدادها خواهد بود. مي‌توانيد مطالب بيشتري درباره SQL Service Broker را در فصل 6 بيابيد.

بهبودهاي فايل داده پايگاه داده

SQL Server 2005 هم‌اكنون از توانايي تغيير مسير فايل‌هاي داده و ثبت وقايع يك پايگاه داده با استفاده از فرمان ALTER DATABASE پشتيباني مي‌كند. SQL Server 2000 توانايي انتقال فايل‌ها را براي پايگاه داده tempdb فراهم مي‌كرد، ولي اين مسأله براي ساير پايگاه‌هاي داده ممكن نبود. همان‌گونه كه ممكن است انتظار داشته باشيد، SQL Server 2005 از انتقال فايل‌ها تنها به عنوان يك عمل offline پشتيباني مي‌كند. مثال بعد ساختار دستوري عبارات ALTER DATABASE جديد را تشريح مي‌كند:

ALTER DATABASE <database_name>

MODIFY FILE(name=<'data_file_name'>, filename=<'new path'>)

پارتيشن‌بندي داده

بهبود جديد ديگر در SQL Server 2005، توانايي انجام پارتيشن‌بندي داده است. پارتيشن‌بندي داده[6] به شما اجازه مي‌دهد تا يك شئ پايگاه داده از قبيل يك جدول يا ايندكس را به چند قطعه بشكنيد. ويژگي پارتيشن‌بندي داده جديد، مديريت جداول و ايندكس‌هاي خيلي بزرگ را تسهيل مي‌كند. پارتيشن‌بندي براي برنامه‌ها شفاف است كه تنها خود شئ پايگاه داده را مي‌بيند و از چند پارتيشني بودن حافظه مرتبط كه توسط SQL Server مديريت مي‌شود، آگاه نيست.

پارتيشن‌ها مي‌توانند ايجاد و حذف شوند، بدون اين كه بر در دسترس بودن خود شئ پايگاه داده تأثير بگذارند. لزوماً، پارتيشن‌بندي به شما امكان مي‌دهد تا حافظه داده مرتبط را به چند شئ بشكنيد، در حالي كه هنوز ديدگاه يك شكلي از شئ و تمام پارتيشن‌هاي آن را به يك برنامه نشان مي‌دهيد. شكل 2-1 مروري پايه‌اي از پارتيشن‌بندي را نشان مي‌دهد.

شكل 2-1 پارتيشن‌بندي داده

SQL Server 2005 از پارتيشن‌بندي داده براي جداول، ايندكس‌ها و ديدگاه‌هاي ايندكس‌دار پشتيباني مي‌كند. رديف واحد پايه پارتيشن‌بندي است. پارتيشن‌ها مي‌توانند برطبق مقادير موجود در ستون‌ها در يك رديف ايجاد شوند. اين مسأله، پارتيشن‌بندي افقي[7] ناميده مي‌شود. براي نمونه، يك جدول ممكن است برطبق تاريخ پارتيشن‌بندي شود كه پارتيشن متفاوتي براي هر سال ايجاد مي‌شود. اين نوع پارتيشن‌بندي طبق تاريخ به شما امكان مي‌دهد تا يك نوع پردازش پنجره‌اي تاريخ اسلايدي را انجام دهيد كه در آن مي‌توانيد پارتيشن حاوي داده سال قبل را حذف كنيد به‌طوري كه بر داده موجود در پارتيشن سال جاري هيچ تأثيري نگذارد.

پارتيشن‌بندي داده يك جفت مزيت مهم را براي هر پايگاه داده بزرگ (VLDBها) فراهم مي‌كند. پارتيشن‌هاي داده مي‌توانند مديريت داده را تسهيل كنند و به شما امكان پشتيبان‌گيري انتخابي را تنها از پارتيشن‌هاي مشخص شده مي‌دهند. مثلاً، در مورد جدول بزرگي كه طبق تاريخ پارتيشن‌بندي مي‌شود، شايد بخواهيد تنها از سال جاري پشتيبان‌گيري كنيد نه پارتيشن سال قبل. مزيت ديگر اين است كه در سيستم‌هاي چند پردازنده‌اي، مي‌توانيد يك CPU را به پردازش پارتيشن خودش اختصاص دهيد تا بازده بهبود يابد.

دو مرحله پايه‌اي براي پياده‌سازي پارتيشن‌بندي داده وجود دارد. در اولين مرحله، بايد دقيقاً تعيين كنيد كه چگونه مي‌خواهيد يك شئ معين را پارتيشن‌بندي كنيد. در دومين مرحله، بايد هر پارتيشن را به يك محل حافظه فيزيكي نسبت دهيد. پارتيشن‌هاي متفاوت مي‌توانند همگي به يك گروه فايل تكي يا پارتيشن‌هاي متفاوتي كه مي‌توانند به چند گروه فايل نگاشت شوند، نسبت داده شوند.

مثال بعد ساختار دستوري براي ايجاد يك تابع پارتيشن ساده و طرح‌واره‌اي را كه يك جدول را با استفاده از يك بخش Range پارتيشن‌بندي خواهد كرد، نشان مي‌دهد:

CREATE PARTITION FUNCTION MyPF

(int) AS RANGE LEFT FOR VALUES (50, 100)

CREATE PARTITION SCHEME MyPS

AS PARTITION MyPF TO (FileGroup1)

CREATE TABLE MyTable (col1 int, col2 varchar(50))

ON MyPS(col1)

خط اول يك تابع پارتيشن‌بندي به نام MyPF را ايجاد مي‌كند. (int) نشان مي‌دهد كه پارتيشن‌بندي روي ستوني خواهد شد كه با استفاده از نوع داده int تعريف شده است. كلمه كليدي Range مشخص مي‌كند كه از پارتيشن‌بندي Range استفاده خواهد شد. كلمه كليدي LEFT كنترل مي‌كند كه كدام پارتيشن مقادير خط حاشيه را دريافت خواهد كرد. مقدار LEFT نشان مي‌دهد كه هر رديفي كه داراي يك مقدار است كه با كران پارتيشن تطابق دارد، بلافاصله به پارتيشن سمت چپ منتقل خواهد شد. بخش VALUES براي تعريف محل‌هاي كران پارتيشن‌ها استفاده مي‌شود. توجه به اين نكته مهم است كه اين مقادير نقاط كران هستند و نه خود پارتيشن‌ها. اين مسأله واقعاً موجب ايجاد سه پارتيشن مي‌شود: اولي كه حاوي مقادير منفي تا 50 است؛ پارتيشن دوم كه حاوي مقادير 51 تا 100 است و پارتيشن سوم كه حاوي تمام مقادير 101 به بالا است.

خط دوم يك طرح‌واره پارتيشن‌بندي به نام MyPS را ايجاد مي‌كند. بخش AS PARTITION براي مشخص كردن عمل پارتيشن‌بندي استفاده مي‌شود كه توسط اين طرح‌واره به كار خواهد رفت. اين مثال از تابع پارتيشن‌بندي MYPF استفاده مي‌كند. بخش TO گروه فايل گروه‌هاي فايلي را تعيين مي‌كند كه پارتيشن‌ها را ذخيره خواهند كرد. اين مثال از يك گروه فايل تكي به نام FileGroup1 استفاده مي‌كند.

سپس، طرح‌واره پارتيشن بايد به جدولي ضميه شود كه پارتيشن‌بندي خواهد شد. اين مثال دستور CREATE TABLE توسعه يافته را نشان مي‌دهد كه به جدول امكان پارتيشن‌بندي شدن را مي‌دهد. اولين بخش عبارت CREATE TABLE تغيير نكرده است. اين بخش نام جدول (در اين مثال MyTable) و ستون‌هاي جدول را مشخص مي‌كند. اين جدول ساده از دو ستون به نام‌هاي col1 و col2 استفاده مي‌كند. آن‌گاه كلمه كليدي ON جديدي براي مشخص كردن طرح‌واره پارتيشن‌بندي مورد استفاده به كار مي‌رود. اين مثال از طرح‌واره پارتيشن‌بندي MyPS استفاده مي‌كند كه ايجاد كرده‌ايد و ستوني كه حاوي داده كليد پارتيشن‌بندي است، در پرانتز قرار مي‌گيرد. اين مثال از ستون col2 براي كليد پارتيشن‌بندي استفاده مي‌كند. اين ستون يك نوع داده int است كه بايد با نوع داده مشخص شده در تابع پارتيشن‌بندي تطابق داشته باشد.

محدوديت‌هايي در انواع ستون‌هايي كه مي‌توانند براي كليد پارتيشن‌بندي استفاده شوند، وجود دارد. اين محدوديت‌ها بسيار شبيه محدوديت ستون‌هايي است كه مي‌توانند در يك ايندكس به كار روند. متن ntext و انواع داده تصويري نمي‌توانند استفاده شوند. علاوه بر اين، ستون‌هاي timestamp نيز محدود شده‌اند. تنها انواع داده طبيعي "T-SQL" مي‌توانند استفاده شوند. نمي‌توانيد از يك نوع تعريف شده كاربر به عنوان كليد پارتيشن‌بندي استفاده كنيد. هرچند، مي‌توانيد از نوع داده varchar(max) جديد استفاده كنيد. هم‌چنين حد 1000 پارتيشن در هر جدول وجود دارد و تمام پارتيشن‌ها بايد در يك گروه وجود داشته باشند.

بهبودهاي ايندكس

بهبودهاي جديدي در ايندكس‌ها در SQL Server 2005 وجود دارد. اول اين كه، بازسازي يك ايندكس كلاستر شده، ديگر تمام ايندكس‌هاي غيركلاستري را مجبور به بازسازي نمي‌كند. در SQL Server 2000، هنگام بازسازي يك ايندكس كلاستر شده، تمام ايندكس‌هاي كلاستر نشده مرتبط نيز بازسازي مي‌شدند. ديگر چنين حالتي وجود ندارد، زيرا SQL Server 2005 ايندكس‌هاي كلاستر نشده را در طي بازسازي ايندكس كلاستر شده صحيح و سالم حفظ مي‌كند.

سپس، يك ويژگي ستون‌هاي موجود وجود دارد كه به شما امكان افزودن ستون‌هاي غيركليدي را به ايندكس مي‌دهد. اين ويژگي جديد به پرس‌وجوهاي بيشتر امكان مي‌دهد تا توسط ايندكس تحت پوشش قرار گيرند، بنابراين كارآيي پرس‌وجو را با حداقل كردن نياز براي موتور SQL Server براي رفتن به جدول مرتبط براي تكميل پرس‌وجو بهبود مي‌بخشد. در عوض، موتور مي‌تواند الزامات پرس‌وجو را با استفاده از داده در ايندكس تحت پوشش برآورده سازد. يكي از جنبه‌هاي خوب ويژگي ستون‌هاي موجود جديد اين واقعيت است كه ستون‌هاي موجود كه بخشي از كليد نيستند، در اندازه حداكثر ايندكس وجود ندارند كه باز هم 900 بايت است.

بهبود ايندكس جديد ديگري كه مايكروسافت به SQL Server 2005 اضافه كرده است، توانايي غيرفعال كردن يك ايندكس است. غيرفعال كردن يك ايندكس، آن ايندكس را از نگهداري توسط موتور SQL Server متوقف كرده و هم‌چنين مانع از كاربرد ايندكس مي‌شود. هنگامي كه ايندكسي غيرفعال مي‌شود. SQL Server فضاي حافظه مورد استفاده ايندكس را مي‌گيرد ولي فوق داده ايندكس را حفظ مي‌كند. قبل از اين كه ايندكس غيرفعال بتواند مجدداً فعال شود، بايد با استفاده از فرمان ALTER INDEX بازسازي شود.

عمليات ايندكس Online

نگارش‌هاي قبلي SQL Server هيچ دستيابي به ايندكس را در هنگام بازسازي ايندكس ممكن نمي‌ساختند. شما بايد منتظر مي‌مانديد تا وقتي كه فرآيند بازسازي كامل شود و جدول بتواند مجدداً بهنگام شود. ويژگي عمليات ايندكس Online جديد SQL Server 2005 به برنامه‌ها امكان دستيابي به ايندكس و انجام عمليات بهنگام‌رساني، درج و حذف در يك جدول را مي‌دهد، در حالي كه عمليات بازسازي ايندكس در حال انجام است. مي‌توانيد اطلاعات بيشتري درباره عمليات ايندكس SQL Server 2005 Online را در فصل 3 بيابيد.

بهبودهاي فوق داده و كاتالوگ سيستم

در SQL Server 2000 و نگارش‌هاي قبلي، كاتالوگ سيستم و فوق داده به عنوان بخشي از هر پايگاه داده در پايگاه داده اصلي ذخيره مي‌شدند. در SQL Server 2005، اين روش تغيير كرده است و هم‌اكنون فوق داده در پايگاه داده منبع قرار مي‌گيرد كه سيستم را به عنوان يك شئ sys ذخيره مي‌كند. SQL Server 2005 ديگر هيچ دستيابي مستقيمي به جداول سيستم ميسر نمي‌سازد. اين تغيير ارتقاهاي سيستم سريع‌تر و ايمني بهتري را با مستحكم ساختن فوق داده سيستم ممكن مي‌سازند. فوق داده كاتالوگ با استفاده از فيلترهاي سطح رديف ايمن مي‌شوند. مي‌توانيد مطالب بيشتري درباره امنيت سطح رديف SQL Server 2005 را در بخش بعدي اين فصل بياموزيد.

فوق داده جديد كاملاً با قبل سازگار است، مادامي كه از جداول سيستمي مستند نشده‌اي استفاده كنيد كه مايكروسافت به كرات هشدار داده است كه از آن‌ها استفاده نشود. فوق داده‌هاي سيستم در SQL Server 2005 از طريق مجموعه‌اي از ديدگاه‌هاي كاتالوگ ارايه مي‌شوند. ديدگاه‌هاي كاتالوگ، همانند ديدگاه‌هاي ANSI INFORMATION_SCHEMA توابع Property و توابع تعبيه شده، نياز به استفاده از جداول سيستم را كه ممكن است در SQL Server 2000 انجام داده باشيد، برطرف مي‌كنند. در كل، بيش از 250 ديدگاه كاتالوگ جديد در SQL Server 2005 وجود دارد و آن‌ها مي‌توانند از طرح‌واره sys پايگاه داده هر كاربر مشاهده شوند. مي‌توانيد ديدگاه‌هاي سيستم جديد را با استفاده از Microsoft SQL Server Manager Studio براي باز كردن Object Browser بيابيد و آن‌گاه به گره Databases | <database> | Views | System Views برويد. هم‌چنين مي‌توانيد يك پنجره پرس‌وجوي جديد را باز كرده و اين پرس‌وجو را وارد كنيد:

select * from sys.system_views

چند مجموعه نتيجه (MARS)

نگارش‌هاي قبلي SQL Server محدود به يك مجموعه نتيجه فعال در هر اتصال بودند. SQL Server 2005 هم اينك قادر به پشتيباني از چند مجموعه نتيجه فعال در يك اتصال است. اين ويژگي جديد به شما امكان مي‌دهد تا يك اتصال به پايگاه داده را باز كنيد، يك پرس‌وجو را اجرا كرده و مقداري نتيجه را پردازش كنيد و آن‌گاه پرس‌وجوي ديگري را شروع كرده و نتايج آن را پردازش كنيد. برنامه‌هاي شما مي‌توانند به راحتي بين چند مجموعه نتيجه باز، عقب و جلو كنند. در فصل 4 نحوه استفاده از اين ويژگي MARS جديد به وسيله مثال‌هايي نشان داده مي‌شود.

بارگذاري داده حجيم

SQL Server 2005 برخي بهبودهاي مهم را در زمينه افزايش كارآيي در بارگذاري داده حجيم فراهم كرده است. پردازش بارگذاري داده حجيم هم‌اكنون از يك فايل فرمت مبتني بر XML استفاده مي‌كند كه تمام عملكرد موجود در نگارش‌هاي قبلي فايل فرمت BCP[8] را فراهم مي‌كند. علاوه بر اين، فرمت XML خواندن و درك فايل فرمت BCP را آسان‌تر مي‌سازد. براي سازگاري قبلي با برنامه‌هاي موجود، فايل فرمت BCP قديمي هنوز مي‌تواند استفاده شود.

فرآيند بارگذاري داده حجيم SQL Server 2005 هم‌اكنون از ثبت رديف‌هاي بد پشتيباني مي‌كند. اين امر به فرآيند بارگذاري داده حجيم امكان مي‌دهد تا حتي در صورت مواجه شدن با رديف‌ها يا داده نامعتبر، به كار خود ادامه دهد. رديف‌هايي كه به‌طور نادرست فرمت شده باشند، به همراه شرحي از شرط خطا، در يك فايل خطا نوشته مي‌شوند. رديف‌هايي كه از الزامات تخطي كرده باشند، به يك جدول خطا به همراه شرط خطاي خاص آن‌ها هدايت مي‌شوند.

جستجوي Full-Text

پشتيباني از جستجوي Full-Text نيز در SQL Server 2005 بهبود يافته است. نگارش‌هاي قبلي SQL Server نياز به استفاده از رويه‌هاي ذخيره شده براي ايجاد كاتالوگ‌هاي جستجوي Full-Text داشتند. در SQL Server 2005، چندين عبارت DDL جديد معرفي شده است تا به شما امكان كار كردن با ويژگي‌هاي SQL Server Full-Text را بدهند. براي نمونه، دو عبارت DDL جستجوي T-SQL Full-Text جديد، CREATE FULLTEXT CATALOG و CREATE FULLTEXT INDEX هستند.

بهبودهاي ديگر در جستجوي FULL-TEXT در SQL Server 2005 شامل توانايي پشتيبان‌گيري و بازيابي ايندكس‌ها و كاتالوگ‌هاي جستجوي FULL-TEXT به همراه داده پايگاه داده شما هستند. در ضمن، ايندكس‌ها و كاتالوگ‌هاي FULL-TEXT مي‌توانند به پايگاه‌هاي داده متناظر خود ضميمه شده و از آن‌ها جدا شوند. بهبود جالب ديگر پشتيباني جستجوي FULL-TEXT SQL Server 2005، توانايي استفاده از يك گنج واژه براي يافتن مترادف كلمات جستجو است.

بهبودهاي پردازشگر پرس‌وجوي T-SQL

بهبودهاي متعددي براي پردازشگر پرس‌وجو در SQL Server 2005 وجود دارد، از جمله CTE[9]، يك بخش TOP بهبود يافته، يك عبارت WAITFOR بهبود يافته و يك بخش OUTPUT جديد براي عبارات DML. مثال‌هاي استفاده از اين بهبودها در T-SQL در فصل 4 ارايه مي‌شوند.

امنيت

امنيت بزرگ‌ترين نسخه مايكروسافت از زماني بوده است كه شركت Trustworthy Computing Initiative خود را شروع كرد. هدف Trustworthy Computing Initiative مايكروسافت، ايمن‌تر و قابل اعتمادتر ساختن محصولات مايكروسافت است. همان‌گونه كه انتظار مي‌رود، SQL Server 2005 كه بخشي از Trustworthy Computing Initiative است، دريافت كننده تعدادي از مهم‌ترين بهبودهاي امنيتي است. دغدغه امنيتي مايكروسافت براي SQL Server بر ساخت ايمن‌تر و مستحكم‌تر محصول نسبت به طراحي آن از طريق توزيع آن تمركز دارد. هنگام طراحي بهبودهاي امنيت براي SQL Server 2005، مايكروسافت از برخي از اصول امنيتي پيروي مي‌كند. ابتدا، بايد سيستم را با در نظر گرفتن تمام تنظيمات نصب پيش‌فرض به سمت ايجاد يك محيط ايمن، ايمن كرد. در حالي كه گزينه‌هايي براي كاربران باز گذاشته شده است تا تنظيمات امنيتي كمتري را انتخاب كنند، انتخاب اين گزينه‌ها نياز به گزينش‌هاي آگاهانه‌اي دارد. سپس، مايكروسافت از اصل حداقل امتيازات در طراحي سيستم خود پيروي مي‌كند. اين سيستم طوري طراحي مي‌شود كه يك فرد براي انجام يك عمل معين و نه چيز ديگري، بايد تنها نياز به امتيازاتي داشته باشد. بالاخره، مايكروسافت قصد داشت تا ناحيه سطح عرضه بالقوه را با فراهم كردن توانايي نصب تنها اجزاي مورد نياز كاهش دهد.

تمام اين ويژگي‌هاي امنيتي جديد در SQL Server 2005، عميقاً تحت تأثير مواردي هستند كه مايكروسافت در طي تلاش امنيتي خود در اوايل سال 2002 كشف كرد و در طراحي و پياده‌سازي SQL Server 2005، آن‌ها را اعمال نمود. برخي از بهبودهاي ويژگي امنيتي اصلي در SQL Server 2005 كه در اين بخش مطالعه خواهيد كرد، شامل جداسازي كاربران از طرح‌واره‌ها، زمينه اجراي رويه ذخيره شده جديد، كنترل سنجيده‌تر مجوزها، تقويت خط‌مشي كلمه عبور جديد، تغييراتي در امنيت سطح رديف و امنيت بهبود يافته براي كاتالوگ‌ها هستند.

جداسازي كاربر- طرح‌واره

مهم‌ترين تغيير مربوط به امنيت در SQL Server 2005، جداسازي كاربر- طرح‌واره است. يك كاربر يا شايد به‌طور دقيق‌تر، يك اصل، هر موجوديتي است كه اشيا پايگاه داده در مقابل آن ايمن مي‌شوند. يك اصل مي‌تواند يك كاربر Windows، يك كاربر SQL Server، يك نقش برنامه يا يك نقش باشد. در SQL Server 2000، مستقيماً تحت مالكيت اشياي پايگاه داده كاربران قرار مي‌گيرد و خود كاربران در جدول سيستمي Sys_Users بودند. همگي اين موارد در SQL Server 2000 تغيير كرده‌اند. حال اشياي پايگاه داده تحت مالكيت طرح‌واره‌ها هستند. كاربران ديگر مستقيماً مالك اشياي پايگاه داده نيستند؛ در عوض آن‌ها مالك طرح‌واره‌ها هستند. در SQL Server 2000، كاربران و ساير اصول امنيتي را مي‌توانيد در ديدگاه sys.database_principals جديد بيابيد. ليست طرح‌واره‌هاي SQL Server 2000 را مي‌توانيد در ديدگاه sys.schemas جديد بيابيد.

يك طرح‌واره[10] كانتينر اشيا است. طرح‌واره توسط بخش سوم از ساختار دستوري نام‌گذاري شئ چهار بخشي مورد استفاده SQL Server تعيين مي‌شود. مثال بعد ساختار دستوري نام‌گذاري SQL Server 2005 را تشريح مي‌كند كه هر بخش از نام، به‌طور افزايشي خاص‌تر مي‌شود.

Server_name.Database_name.Schema_name.Object_name

در تمام نسخه‌هاي قبلي SQL Server، نام طرح‌واره و نام مالك لزوماً يكسان بود. در SQL Server 2005، مالك مجزا از طرح‌واره است. هنگامي كه SQL Server 2000 و نسخه‌هاي قبلي نام اشيا را تفكيك مي‌كردند، SQL Server 2005 ابتدا Database_name.User_name.Object_name را جستجو مي‌كرد و در صورت عدم موفقيت، آن‌گاه Database_name.dbo.Object_name را جستجو مي‌كند.

دليل اصلي براي اين جداسازي كاربر و طرح‌واره در SQL Server 2005، سامان بخشيدن به مشكل نياز به تغيير مالكيت چند شئ پايگاه داده است، چنان‌چه كاربر معيني سازمان را ترك كرده باشد. علاوه بر اين، عمل تغيير مالك يك شئ پايگاه داده موجب تغيير نام مي‌شود. مثلاً، اگر مالك Table1 در پايگاه داده MyDB از UserA به UserB تغيير كند، آن‌گاه نام معين Table1 از MyDB.UserA.Table1 به MyDB.UserB.Table1 تغيير خواهد كرد. براي كمك به جلوگيري از اين مشكل، بعضي از سازمان‌ها، استاندارد مالكيت تمام اشياي پايگاه داده توسط dbo را مي‌پذيرند، ولي چيزي در سرور وجود ندارد كه اين مسأله را اجباري كند.

پياده‌سازي SQL Server 2005 از مفهوم طرح‌واره يك پايگاه داده، سطحي از انتزاع را در زنجيره مالكيت شئ پايگاه داده معرفي كرده است. مي‌توانيد زنجيره مالكيت شئ پايگاه داده SQL Server 2005 را در شكل 3-1 ببينيد.

در SQL Server 2005، اشياي پايگاه داده در طرح‌واره‌ها قرار دارند و طرح‌واره به نوبت تحت مالكيت كاربران هستند. اين سطح انتزاع جديد، مسأله تغيير مالكيت شئ پايگاه داده را قابل مديريت‌تر مي‌سازد. حذف كاربري كه مالك اشياي پايگاه داده در SQL Server 2005 است، بدين معني است كه DBA هم اينك تنها بايد مالك طرح‌واره را تغيير دهد و نه تمام تك تك اشياي پايگاه داده را. اين امر تعداد اشيايي را كه DBA بايد براي مالك اشيا در يك پايگاه داده با آن‌ها تماس داشته باشد، به شدت كاهش مي‌دهد. براي تغيير مالك تمام اشيا در پايگاه داده SQL Server 2005، تنها مالك طرح‌واره را تغيير داده و آن‌گاه مي‌توانيد كاربر قديمي را حذف كنيد. تغيير مالك شئ پايگاه داده، نام شئ را تغيير نمي‌دهد، زيرا نام طرح‌واره تغيير نكرده است و تنها مالك آن تغيير كرده است.

شكل 3-1 زنجيره مالكيت شئ SQL Server 2005

همان‌گونه كه ممكن است انتظار داشته باشيد، شئ طرح‌واره جديد، روشي را كه SQL Server تفكيك نام شئ پايگاه داده را انجام مي‌دهد، تغيير مي‌دهد. حال هر كاربر داراي يك طرح‌واره پيش‌فرض مرتبط است و SQL Server 2005 ابتدا نام يك شئ نامعين را با استفاده از طرح‌واره پيش‌فرض كاربر جستجو خواهد كرد. اگر اين امر ناموفق بود، SQL Server شئ را با استفاده از نام طرح‌واره dbo جستجو خواهد كرد. مثلاً، اگر UserA داراي يك طرح‌واره پيش‌فرض MySchema1 باشد و آن كاربر پرس‌وجويي را براي جستجوي Table1 انجام دهد، آن‌گاه سرور در ابتدا تلاش خواهد كرد تا نام را با استفاده از MySchema1.Table1 تفكيك كند و آن‌گاه به dbo.Table1 برگردد.

تنها به دليل اين كه پايگاه‌هاي داده SQL Server 2000 مي‌توانستند حاوي چند كاربر و نقش باشند، پايگاه‌هاي داده SQL Server 2005 مي‌توانند حاوي چند طرح‌واره باشند. هر طرح‌واره داراي يك مالك اصلي است كه معمولاً يك كاربر يا نقش مي‌باشد. براي اهداف تفكيك نام، هر كاربر داراي يك طرح‌واره پيش‌فرض است. آن‌گاه اشياي واقعي پايگاه داده در يك طرح‌واره قرار مي‌گيرند. براي ايجاد اشياي پايگاه داده جديد در يك طرح‌واره، بايد مجوز CREATE را براي خود شئ پايگاه داده و مجوز ALTER يا CONTROL را براي طرح‌واره داشته باشيد. زنجيره مالكيت باز هم بر طبق مالكان اصلي است و نه طرح‌واره‌ها.

SQL Server 2005 تغييرات DDL چندي را براي سروكار داشتن با جداسازي كاربر و طرح‌واره جديد معرفي كرده است، از جمله عبارت CREATE/DROP/ALTER براي اشياي USER، ROLE و SCHEMA. ليست زير نحوه ايجاد و انتساب يك طرح‌واره پايگاه داده را تشريح مي‌كند:

/* Create a login */

CREATE LOGIN UserA WITH PASSWORD = 'ABC123#$'

/* Create a user for that login – the schema doesn't need to exist*/

CREATE USER UserA FOR LOGIN UserA

WITH DEFAULT_SCHEMA = MySchema

/* Create the schema and assign its owner */

CREATE SCHEMA MySchema AUTHORIZATION UserA

/* Create a Table in the new schema */

CREATE TABLE MySchema.Table1 (col1 char (20))

اولين خط در اين ليست، login جديدي به نام UserA را ايجاد كرده و كلمه عبوري را براي آن Login تنظيم مي‌كند. خط بعد كاربر جديدي به نام UserA را براي اين login ايجاد كرده و طرح‌واره پيش‌فرضي را براي UserA تحت عنوان MySchema تنظيم مي‌كند. طرح‌واره واقعي نبايد در زماني كه در عبارت CREATE USER مشخص مي‌شود، وجود داشته باشد. اگر هنگام ايجاد كاربر جديد، طرح‌واره پيش‌فرضي را مشخص نكنيد، آن‌گاه طرح واره پيش‌فرض با dbo تنظيم خواهد شد. سپس، عبارت CRAETE SCHEMA براي ايجاد يك طرح‌واره جديد به نام MySchema استفاده مي‌شود. بخش AUTHORIZATION مالك طرح واره را براي UserA تنظيم مي‌كند. بالاخره، جدولي به نام Table1 در طرح‌واره به نام MySchema ايجاد مي‌شود. مالك MySchema و اشياي آن نظير Table1، UserA است.

زمينه اجراي رويه ذخيره شده

در حالي كه مايكروسافت به يكي از ويژگي‌هاي جديد به عنوان زمينه اجراي رويه ذخيره شده مراجعه مي‌كند، واقعاً آن را بر ماژول‌ها اعمال مي‌كند و نه رويه‌هاي ذخيره شده. يك ماژول مي‌تواند يك رويه ذخيره شده، يك تابع، يا يك اسمبلي باشد. تنظيم زمينه اجرا براي يك ماژول موجب مي‌شود تمام عباراتي كه در آن ماژول قرار دارند، براي مجوزها در مقابل زمينه اجراي مشخص شده بررسي شوند. به عبارت ديگر، با تنظيم زمينه اجراي يك ماژول معين، موجب مي‌شويد كه تمام عباراتي كه در آن ماژول قرار دارند، با استفاده از هويت كاربري اجرا شوند كه مشخص كرده‌ايد (به‌جاي فراخواني واقعي ماژول). اين ويژگي جديد به شما امكان مي‌دهد تا مزايايي مشابه با آن‌چه كه از طريق زنجيره مالكيت SQL Server 2000 تشخيص مي‌داديد، داشته باشيد، ولي اين انعطاف‌پذيرتر است زيرا محدوديت‌هاي مشابهي ندارد. مثلاً، برخلاف زنجيره مالكيت SQL Server 2000 كه به شما اجازه تغيير دادن زمينه اجرا را براي SQL پويا نمي‌داد، زمينه اجراي ماژول SQL Server 2005 بر SQL پويا تنها به اين دليل اعمال مي‌شود كه در SQL ايستا نيز انجام مي‌شود. براي درك بهتر اين موضوع، شكل 4-1 را ببينيد كه زنجيره مالكيت SQL Server 2000 را تشريح مي‌كند.

شكل 4-1 زنجيره مالكيت SQL Server 2000

براي اين كه UserA، dbo.Proc1 را اجرا كند، بايد مجوز اجراي آن شئ را داشته باشد. هرچند، هنگامي كه dbo.Proc1 به dbo.Table1 دسترسي دارد، هيچ مجوزي بررسي نمي‌شود، زيرا dbo مالك هر دو شئ است. اين مثالي از يك زنجيره مالكيت صحيح بود. در سناريو بعد، براي UserA جهت اجراي UserB.Proc2، UserA بايد مجوزهاي Execute را براي آن شئ داشته باشد. سپس، هنگامي كه UserB.Proc2 تلاش مي‌كند تا به UserC.Table2 دستيابي داشته باشد، انتخاب مجوزها از UserA بايد بررسي شود. در اين مورد، به دليل اين كه UserB.Proc2 و UserC.Table2 داراي مالكان متفاوتي هستند، زنجيره مالكيت نقض مي‌شود.

اجراي SQL Server 2005 اين سناريو را آسان مي‌كند، همان‌گونه كه در شكل 5-1 نشان داده شده است. در اين سناريو، هنگامي‌كه UserA تلاش مي‌كند تا UserB.Proc2 را اجرا كند، SQL Server بررسي مي‌كند تا اطمينان يابد كه UserA داراي مجوزهاي Execute براي UserB.Proc1 است. اگر شئ UserB.Proc1 با يك زمينه اجرايي ايجاد شود كه مشخص كند يك رويه ذخيره شده به عنوان UserZ اجرا خواهد شد، آن‌گاه هنگامي كه رويه ذخيره شده UserB.Proc1 تلاش مي‌كند تا به UserC.Table1 دستيابي داشته باشد، UserB.Proc1 براي مجوزهاي Select تنها كاربر مشخص شده در زمينه اجرا را بررسي خواهد كرد كه در اين مورد UserZ است. هيچ مجوز Selectاي براي UserA مورد نياز نيست، كسي كه فراخوان واقعي است.

شكل 5-1 زمينه اجراي SQL Server 2005

ليست زير نشان مي‌دهد چگونه زمينه اجراي يك رويه ذخيره شده به نام MyProc1 را تغيير مي‌دهيد:

ALTER PROC MySchema.Proc1 WITH EXECUTE AS USER UserB

اين عبارت بخش WITH EXECUTE جديد را نشان مي‌دهد. در اين‌جا، رويه ذخيره شده‌اي به نام Proc1 كه در MySchema قرار دارد، براي اجرا تحت زمينه UserB تنظيم شده است. بايد نام كاربري را براي محتواي اجرا مشخص كنيد. نمي‌توانيد نام يك نقش را مشخص كنيد. تغييرات در زمينه اجرا در ديدگاه Sys.sql_modules جديد ذخيره مي‌شود.

كنترل مجوزهاي سنجيده‌تر

SQL Server 2005 هم‌چنين كنترل سنجيده‌تري را روي مجوزها فراهم كرده است. در SQL Server 2005، مايكروسافت مجوزهاي بيشتري را در حوزه‌هاي مختلف اضافه كرده است. اين حوزه‌ها براي مجوزهايي كه مي‌توانند اعمال شوند، عبارتند از: سرور، پايگاه داده، طرح‌واره، شئ و اصل. ايده طراحي تحت مجوزهاي بهبود يافته SQL Server 2005 اصل حداقل امنيت و توانايي كنترل دقيق مجوزهاي منتسب را به DBA مي‌دهند. مجوزهاي سنجيده‌تر، خلاص شدن از شر نقش‌هاي ثابت موجود SQL Server نيست. تمام نقش‌هاي قديمي هنوز وجود دارند و مي‌توانند بدون هيچ مشكلي به همراه مجوزهاي جديد وجود داشته باشند. سناريوي خاصي كه اين مجوزهاي سنجيده‌تر براي سامان دادن به آن در نظر گرفته شده‌اند، حالت مميزي است. در SQL Server 2000، شما بايد عضوي از گروه Sysadmins بوديد تا مميزي را انجام مي‌داديد. هرچند، عضويت در اين گروه باعث ممكن ساختن كارهاي ديگري مي‌شد، قابليت‌هايي بود كه رسيدن به آن‌ها مشكل و بعيد بود. برخي از مجوزهاي جديد موجود در SQL Server 2005، امكان انجام اعمال مميزي را بدون نياز به اين مسأله كه كاربر بخشي از گروه Sysadmins باشد، ميسر مي‌سازند.

حالات مجوز پايه مشابه GRANT، DENY و REVOKE كه در نگارش‌هاي قبلي SQL Server استفاده مي‌شدند، هنوز اعمال مي‌شوند. موردي كه درباره اين روش متفاوت است و SQL Server 2005 از مجوزها استفاده مي‌كند، اين است كه مجوز مشابهي مي‌تواند در چندين حوزه اعمال شود. مثلاً اگر مجوزي را براي حوزه پايگاه داده اعمال كنيد، بر تمام اشياي موجود در پايگاه داده اعمال مي‌شود. اگر مجوزي را براي سطح طرح‌واره به كار بريد، تنها بر اشياي موجود در طرح‌واره اعمال مي‌شود. به استثناي مجوز DENY، مجوز حوزه بالاتر هميشه استفاده مي‌شود. هرچند، يك DENY در هر سطحي هميشه داراي تقدم است. جدول 1-1 برخي از مهم‌ترين مجوزهاي جديد SQL Server 2005 را فهرست كرده است. مجوزهاي سرور در ديدگاه sys.server_permissions وجود دارند، در حالي كه مجوزهاي پايگاه داده در ديدگاه sys.database_permissions وجود دارد.

جدول 1-1 برخي از مجوزهاي جديد در SQL Server 2005

مجوز	شرح
ALTER	توانايي تغيير خصوصيات يك شئ را واگذار مي‌كند. هم‌چنين توانايي اجراي عبارات CREATE/DROP/ALTER را واگذار مي‌كند.
ALTER ANY ‘X’	توانايي تغيير هر شيئي از نوع X را واگذار مي‌كند. مثلاً، اگر TABLE را با X جايگزين كنيد، اين مجوز توانايي تغيير هر جدولي را در پايگاه داده واگذار مي‌كند.
ALTER TRACE	توانايي انجام مميزي و اجراي Profiler را واگذار مي‌كند.
CONTROL	مجوزهاي شبيه مالك اصلي را واگذار مي‌كند.
SELECT	توانايي دستيابي به يك شئ را واگذار مي‌كند. هم‌اكنون بر سطوح پايگاه داده و طرح‌واره اعمال مي‌شود و نه تنها بر سطح شئ.
EXECUTE	توانايي اجراي يك رويه، اسمبلي يا تابع را واگذار مي‌كند. هم‌اكنون بر سطوح پايگاه داده و طرح‌واره اعمال مي‌شود و نه تنها سطح شئ.
IMPERSONATE	توانايي جعل هويت كاربري ديگر را به يك login يا كاربر واگذار مي‌كند.
TAKE OWNERSHIP	توانايي فرض كردن مالكيت يك شئ را واگذار مي‌كند.
VIEW DEFINITION	توانايي مشاهده فوق داده يك شئ را واگذار مي‌كند.

ويژگي امنيتي جديد و مهم ديگر در SQL Server 2005، پشتيباني از خط‌مشي‌هاي كلمه عبور است. اين ويژگي تقويت خط‌مشي جديد از خط‌مشي‌هاي كلمه عبور محلي Windows پيروي كرده و به شما امكان پياده‌سازي يك خط‌مشي امنيتي گستره جهاني مستحكم را مي‌دهند، نه تنها براي سيستم‌هاي Windows Server شما، بلكه هم‌چنين براي سيستم‌هاي پايگاه داده SQL Server شما. SQL Server 2005 هم‌اكنون داراي قابليت تقويت قدرت كلمه عبور، انقضاي كلمه عبور و خط‌مشي‌هاي Lockout حساب. همان‌گونه كه انتظار داريد، خط‌مشي قدرت كلمه عبور، كلمات عبور را مجبور مي‌كند تا شامل يك پيچيدگي معين باشند. خط‌مشي انقضاي كلمه عبور اطمينان مي‌دهد كه كلمات عبور منقضي شده و بايد در يك فاصله معين باشند. خط‌مشي انقضاي كلمه عبور اطمينان مي‌دهد كه كلمات عبور منقضي شده و بايد در يك فاصله معين بازنشاني شوند و خط‌مشي lockout حساب اطمينان مي‌دهد كه يك حساب بعد از تعداد تلاش‌هاي بد در مورد كلمه عبور lockout شده است. تمام اين خط‌مشي‌هاي جديد كلمه عبور، در Windows Server 2003 پشتيباني مي‌شوند. هرچند، در Windows 2000 Server تنها از خط‌مشي پيچيدگي كلمه عبور پشتيباني مي‌شود. با پيروي از دغدغه امنيتي مايكروسافت، تمام خط‌مشي‌ها در نصب پيش‌فرض فعال مي‌شوند، ولي مي‌توانيد برطبق هر login، مجدداً پيكربندي كنيد. SQL Server 2005 خط‌مشي‌هاي جديد كلمه عبور را در ديدگاه كاتالوگ sys.sql_logins ذخيره مي‌كند.

امنيت كاتالوگ

بهبود نهايي مربوط به امنيت كه در اين بخش به آن مي‌پردازيم، امنيت كاتالوگ جديدي است كه توسط SQL Server 2005 فراهم شده است. جداول سيستمي كه توسط SQL Server 2000 در پايگاه‌هاي داده مجزا و در پايگاه داده اصلي استفاده مي‌شوند، هم‌اكنون به عنوان ديدگاه‌هاي كاتالوگ در SQL Server 2005 پياده‌سازي مي‌شوند. فوق داده سرور كه در اين ديدگاه‌ها عرضه مي‌شود، به‌طور پيش‌فرض ايمن است و حداقل مجوزهاي عمومي وجود دارد. ديدگاه‌هاي كاتالوگ SQL Server 2005، امنيت سطح رديف را به كار مي‌گيرند، دستيابي به داده موجود در اين ديدگاه‌ها را به تنها اشيايي كه مال شماست يا داراي مجوزها هستند، محدود مي‌كنند. طبيعتاً، sa استثنايي براي اين مسأله است. حساب sa هنوز داراي دستيابي به تمام اين اشيا در سرور است.

براي دادن امكان دستيابي به فوق داده به يك كاربر يا نقش، DBA بايد از مجوز VIEW DEFINITION جديد استفاده كند. مجوز VIEW DEFINITION مي‌تواند در حوزه‌هاي سرور، پايگاه داده، طرح‌واره و شئ به كار رود.