SonaOps

تو پست قبلی مقدمه ای رو بر Policy-Based Management در SQL Server 2008 گفتم.تو این پس قصد دارم با یه مثال عملی یکی از کاربرد های Policy-Based Management  رو معرفی کنم. تو شرکت ما یکسری جدول بصورت استاندارد وجود داره ولی برای کارهای پشتیبانی و …نیاز به جداول موقت داریم.مشکلی که برای ما پیش اومده رعایت نکردن استاندارد نام گذاری این جداوله برای همین یه روی سرور یه Policy ایجاد کردم تا از ایجاد جداولی که استاندارد جداول موقت رو رعایت نکردن جلوگیری کنه. برای شروع باید اول یک Condition تعریف کرد.مسیرش رو تو شکل زیر میبینید برای ساخت Condition روی Conditions راست کلیک کرده و گزینه New Condition رو انتخاب میکنیم از مفاهیمی که تو پست قبلی گفتم تو این مثال  Target Type همون جداوله و Facet هم Table Options ه که شامل چندین خواص (Properties) هست که برای این مثال ما با خواصیت Name اون کار داریم. بعد ساخت Condition نوبت ساختنه Policy هست.برای اینکار روی Policies راست کلیک کرده و گزینه New Policy رو انتخاب میکنیم از مفاهیمی که تو پست قبلی گفتم تو این مثال Evaluation Mode یا نحوه ارزیابی ما ...

Policy-Based Management یا PBM مسلما پراهمیت ترین ویژگی SQL Server 2008 برای یک DBA هست. PBM یا مدیریت برپایه خط مشی ; روال مدیریت تعداد زیادی وهله های SQL Server رو از طریق توانایی تعریف و اعمال(Apply) کردن policy های پیکر بندی آسون میکنه.مثلا کارها و تغییراتی که policy ها رو نقض میکنند میتونن نادیده گرفته بشن(جلوگیری کردن از انجامشون) یا اینکه ثبت (Log) بشن مثلا اعمال policyی که اجازه وارد کردن پسورد با طول 6 رو به کاربر نده. اجازه بدید یه مثال دیگه رو برسی کنیم فرض کنید بعنوان DBA نیاز دارید یه استاندارد خاصی رو برای نام گذاری SP ها اجبار کنید.به این صورت که تمام SP باید به _usp شرو بشن (در رابطه با مشکل رعایت نکردن نام SP این پست رو هم ببینید ). شکل زیر رابطه بین این خط مشی و مفاهیم PBM رو نشون میده Target Type : موجودیت های که قراره از طریق PBM اونا رو مدیدریت کنیم مثلا بانک ها یا جداول و یا مثلا تو این مثال SP ها Management Facet : یا منظر مدیریت(اگه ترجمه مناسبتری پیشنهاد میکنید بگید) مجموعه ای از خواص منطقی که رفتار یا مشخصات نوع خاصی از موجودیت ها (Target Type)...

سناریو / مشکل :دیتابیس چندین تربایتی داریم و عملیات Restore کردن زمانبر است و در نتیجه Down Time سیستم بالا راه حل : استفاده از چندین فایل گروپ وقتی ما در دیتابیسمون از چندین  filegroup استفاده کنیم قادر خواهیم بود بجای Restore کردن کل دیتابیس که کار زمان بری است (با توجه به سناریوی ما) بخشی از دیتابیس رو که برای ما از اهمیت بیشتری برخورداره Restore کنیم .در این روش بعد Restore کردن بخش مورد نظر (filegroup) دیتابیس آنلاین شده و کاربر میتونه به کار خودش ادامه بده در حالی که بخش های باقی مونده (filegroups) در حال Restore شدن هستند. مثال:فرض کنید دیتابیسی بنام Sales داریم که از 2 filegroup بنام های Sales_Main (که شامل جداول اصلی ما است) و Sales_Archive (که شامل جداول آرشیو ما است) تشکیل شده CREATE DATABASE [Sales] ON PRIMARY (NAME = N'Sales', FILENAME = N'j:\SQL Data\Sales.mdf') , FILEGROUP [Sales_Main] (NAME = N'Sales_Main', FILENAME = N'j:\SQL Data\Sales_Main.ndf') , FILEGROUP [Sales_Archive] (NAME = N'Sales_Archive', FIL...

سناریو / مشکل : بکاپ های که از بانک ها گرفته میشود در هر سیستمی قابل بازیابی است و در صورت خارج شدن از سازمان دیتا در هر سیتمی قابل استفاده است.   سناریو / مشکل : فایل های اصلی بانک اطلاعاتی شامل MDF , LDF در صورت دزدیده شدن در هر سیستمی قابل استفاده هستند. راه حل : رمزنگاری بانک اطلاعاتی Transparent Data Encryption نوع دیگری از رمزنگاری هست که با SQL SERVER 2008 معرفی شده و رمزنگاری رو در سطح دیتابیس انجام میده و محدود به ستون ها و رکوردهای دیتابیس نیست و از data فایل و log فایل محافظت میکنه. پیاده سازی Transparent Data Encryption در بانک اطلاعاتی همونطور که اسمش پیداس برای برنامه های کاربردی که از بانک اطلاعاتی استفاده میکنند بصورت نا پیدا (transparent) است یعنی بدون نیاز به هیچ تغییری میتونیم این مکانیزم امنیتی رو در سطح دیتابیس داشته باشیم. بعد از فعال کردن این نوع رمزنگاری در بانک اطلاعاتی بکاپی که از این بانک گرفته میشود(در سرور مبدا) فقط و فقط در سروری که certificate از سرور مبدا داشته باشد قابل بازیابی است همچنیا برای attach کردن فایل های اصلی بانک اطلاعاتی در س...

و میرسیم به پستی که متاسفانه تو بیشتر وبلاگ ها دیده میشه(بعضیها با تعداد پست کم و بعضی زیاد) و البته برای رفع این مشکل  اینحا روشی ارئه شده هر چند شاید هم زیاد مهم نباشه ولی برای اینکه خودم راحت باشم (شاید باورتون نشه ولی هروقت به وبلاگ های بلاگری  سر میزنم ناراحت میشم که چرا نمیتونم برم تو بلاگ خودم پستی بزنم)این پست رو میزنم و اما بنابه دلایل زیر 1-آماده شدن برای کنکور (که شدیدا محتاج دعای دوستان هستم) 2-مشغله کاری در آخر امیدوارم این پستم مثل بعضی وبلاگ های که گفتم آخرین پستم نباشه ممنون از توجهتون

در این پست نکات کوچیکی  لیست شده که با توجه به اونا میتونیم سرعت اجرا شدن SP هامون رو افزایش بدیم NOCOUNT رو فعال کنیم همونطور که میدونید اسکیوال سرور با هر دستور Select و دستورات DML تعداد رکوردهای رو که تحت تاثیر اون دستور قرار گرفتن رو برمیگردونه این تعداد رکورد تحت تاثیر قرار گرفته برای دیباگ کردن کد میتون کارآمد باشه ولی بعد اون بی استفاده میشه با توجه به اینکه SP میتونه شامل چندین دستور مختلف باشه غیر فعال کردن این ویژگی میتونه کارائى رو افزایش بده CREATE PROC dbo.ProcName AS SET NOCOUNT ON; --دستورات در این قسمت SELECT column1 FROM dbo.TblTable1 -- فعال کردن ویژگی تعداد رکورد تحت تاثیر قرار گرفته SET NOCOUNT OFF; GO استفاده از اسکیما (schema) در کنار نام اشیاء نام اسکیما باید با نام SP و تمام اشایی که داخل SP به آنها ارجاع شده استفاده بشه.این کار باعث مشیه اسکیوال مستقیما  پلن کامپایل شده(complied plan) رو پیدا و استفاده کنه بجای اینکه دنبال اون اشیاء تو اسکیما های دیگه بگرده و در صورت وجود از پلن کامپایل شده(complied plan) استفاده کنه.این جستجوها برا یافتن اشیاء د...

برای نمونه برداری تصادفی (Random) اصلاعات در اسکیوال سرور معمولا از روش زیر استفاده میکردم select * from mytable order by newid() اما با اومدن اسکیوال سرور 2005 دستور جدیدی در T-Sql اضافه شد بانام  TABLESAMPLE که کارش نمونه برداری تصادفی  از جدول داده شده است SELECT FirstName, LastName FROM Person.Person TABLESAMPLE (100 ROWS) برای اطلاعات بیشتر  TABLESAMPLE و اما نکته ای که باید بگم اینه که روش اول رو برای جداول با تعداد رکورد کم استفاده کنید چون در این روش اسکیوال سرور میاد برای هر رکورد یک ID درست میکنه و برا اساس اون رکورد ها رو مرتب (Sort) میکنه در نتیجه افت کارائى (Performance) تو این روش زیاده (برای جداول با تعدا رکورد بالا)