یادگیری رایگان SQL Server

یکی از آخرین خطوط دفاع برای هر سیستم داشتن بک آپ در مکان می باشد در موردی که نیاز به ریکاور کردن برخی داده ها یا همه ی آنها است. این مسئله در مورد SQL Server نیز درست می باشد.

اولین موردی که باید برای بک آپ های درست تنظیم شود، تنظیم مدل مناسب ریکاوری برای هر دیتابیس می باشد. عموما مدل ریکاوری به SQL Server می گوید که چه داده ای و برای چه مدت زمانی در فایل transaction log حفظ شود.

دل ریکاوری کامل به SQL Server می گوید که همه ی داده های تراکنش را در لگاریتم تراکنش حفظ کند تا زمانی که یا یک بک آپ از transaction log اتفاق بیفتد و یا transaction log کوتاه شده باشد.

این مدل ساده آنچه را که به کار می برد، انجام می دهد، یک بک آپ ساده به شما ارائه می دهد که می تواند کل دیتابیس شما را در رویداد یک شکست جایگزین کند، یا اگر نیاز باشد دیتابیس شما را به سرور دیگری بازگرداند.

مدل ریکاوری "Bulk-logged" آنچه را به کار می برد، انجام می دهد. با این مدل حجم معینی از عملکردها از قبیل BULK INSERT, CREATE INDEX, SELECT INTO و غیره وجود دارند که به طور کامل وارد transaction log نشده و بنابراین و به اندازه ی transaction log فضا نمی گیرند.

SQL Server گزینه های بسیاری برای ایجاد بک آپ ارائه می دهد. در بخش قبلی، مدل های ریکاوری، در مورد انواع بک آپ هایی که می توانند بر اساس مدل ریکاوری دیتابیس اجرا شوند، بحث کردیم.

متداول ترین بک آپ های SQL Server بک آپ های کامل یا full می باشند که به بک آپ های دیتابیس نیز معروف می باشند. این نوع بک آپ ها یک بک آپ کامل از دیتابیس شما به همراه بخشی از log تراکنش ایجاد می کنند

اگر دیتابیس شما بر روی Full یا Bulk logged تنظیم شده باشد، شما قادر خواهید بود که بک آپ های "Transaction Log" را انتشار دهید. با داشتن این بک آپ ها به همراه بک آپ های کامل، شما قادر به یک اشاره در زمان بازگشت می باشید، بنابراین اگر شخصی به طور تصادفی همه ی داده ها را در یک دیتابیس حذف کند،

گزینه ی دیگری برای کمک به ریکاوری ایجاد بک آپ های "Differential" می باشد. یک بک آپ "Differential" نوعی بک آپ از هر حوزه ای می باشد که از زمان ایجاد آخرین بک آپ کامل تغییر کرده است.

گزینه ی دیگری برای بک آپ گرفتن دیتابیس شما، بک آپ فایل (File) می باشد. این بک آپ به شما اجازه می دهد هر فایل را به طور مستقل بک آپ بگیرید، به جای اینکه مجبور باشید کل دیتابیس را بک آپ بگیرید.

علاوه بر بک آپ های File، می توانید بک آپ های Filegroup را نیز انجام دهید که به شما اجازه می دهد تا از همه ی فایل هایی که در گروه فایل هستند، بک آپ بگیرید.

ک گزینه ی جدید بک آپ های بخشی می باشد که به وسیله ی SQL Server 2005 معرفی شد. این برنامه به شما اجازه می دهد تا فایل گروه PRIMARY، همه ی فایل گروه های Read – Write و فایل های خاص را بک آپ بگیرید.

دو فرمان اولیه وجود دارند که برای ایجاد بک آپ های SQL Server به کار می روند،

تنها دو فرمان برای بک آپ وجود دارد، اولی BACKUP DATABASE می باشد، که به شما اجازه می دهد یک بک آپ کامل از دیتابیس خود به همراه بک آپ های differential، file و غیره، بسته به گزینه ی مورد استفاده، داشته باشید.

تنها دو فرمان برای بک آپ وجود دارند که اولی BACKUP DATABASE می باشد که کل دیتابیس را بک آپ می گیرد و دیگری BACKUP LOG که گزینه های مختلفی برای انجام بک آپ های transaction log ارائه می دهد.

ایجاد بک آپ برای SQL Server بسیار ساده می باشد. چند نکته وجود دارد که باید به آنها توجه داشته باشید.

ایجاد خط فرمان بک آپ ها خیلی راحت می باشد. اساسا دو دستور وجود دارد که به شما اجازه ی ایجاد بک آپ می دهد؛ BACKUP DATABASE و BACKUP LOG.

ایجاد بک آپ ها با استفاده از SQL Server Management Studio نیز آسان می باشد. براساس میزان سادگی فرمان های T-SQL، عملیات زیادی باید در SSMS برای ایجاد بک آپ اتفاق بیفتد.

یکی از کارهای سخت تری که حرفه ای های دیتابیس دارند، نصب و آپگرید کردن برچسب ها برای دیتابیس خود می باشد. روش ها و ابزار بسیاری استفاده می شوند

ما به سمت ایجاد پروژه ی SSDT SQL اولیه با استفاده از Visual Studio 2012 پیش خواهیم رفت.

ما پروژه ی خود را شامل تنظیمات اولیه ی دیتابیس ایجاد کرده ایم. اکنون زمان ایجاد یک جدول رسیده است.

ما یک جدول ایجاد کرده ایم و می توانیم از روند ذخیره شده برای دسترسی به هر داده ای که به جدول اضافه شده، استفاده کنیم.

وقتی دیتابیس ها ایجاد ویا آپگرید می شوند، ممکن است لازم باشد داده افزوده و یا حذف شود و یا تغییر کند. علاوه بر این قبل و یا بعد از تکمیل پروسه، ممکن است لازم باشد فعالیت هایی اتفاق بیفتد.

به کار بردن تغییرات کار بسیار راحتی می باشد. قبل از انجام این کار اجازه بدهید که اطمینان حاصل کنیم که یک پین خروجی قابل مشاهده در فضای کار خود داریم.

عمل انتشار فایل هایی تولید می کند که به وسیله ی SSDT استفاده می شوند تا تعیین کنند چه تغییراتی در دیتابیس به کار گرفته شوند. چه فایل هایی تولید شوند؟

همانطور که در بخش های قبل مشاهده کردیم انتشار دیتابیس ما بسیار آسان بود. به هرحال تعداد زیادی گزینه های انتشار پیشرفته وجود دارند و ما تمایل نداریم هر چه را که می خواهیم تغییر دهیم در زمان انتشار دوباره به کار بریم.

دیتابیس ها ساخته می شوند تا دوباره فاکتور شوند. آبجکت ها همیشه به عنوان خروجی های یک دیتابیس اصلاح می شوند. تغییرات چگونه تکمیل می شوند؟

بسیاری از دیتابیس ها از ابتدا توسط افراد حرفه ای اما نه مجرب در این کار بسط داده شده اند. در موارد بسیاری یک مهندس برنامه نویس، به خاطر کمبود منابع دیتابیس موجود، در واقع با عملکرد طراحی یک جدول یا دیتابیس آماده شده است.

مدل سازی داده های منطقی جایی است که در آن ورودی های تجاری، مولفه های آن (ستون ها) و چگونگی ارتباط داخلی ورودی ها با یکدیگر که در نهایت جدول خواهند شد، را تعریف می کنید.

صفحات داده ی SQL Server داده ی ردیف (row data) را در خود دارد و تقریبا در 8060 بایت پوشانده می شود، گرچه یک مکانیزم سرریز ردیف وجود دارد که می توانید مشارکت داشته باشد.

شما همیشه باید راهی خاص برای شناسایی و دسترسی به یک ردیف داشته باشید. این یکی از اصول در پشت اولین فرم نرمال (First Normal Form) می باشد.

ممکن است آن را قبلا خوانده باشید و یا ممکن است در مورد آن چیزی ندانید، به هرحال من دوباره آن را در اینجا مطرح می کنم.

داستانی که همیشه استفاده می کنم برای تکمیل بحث خود در مورد ترکیب محدودیت های داخلی (native constraints) حول یک تعامل مشاوره ( consulting engagement) می چرخد که سال ها پیش به بررسی آن پرداختم.

در مورد کلید اولیه و clustered index برای جدول ها و همچنین محدودیت ها و حفاظت داده ها صحبت کرده ایم. اما شاخص های اضافه چطور؟ لازم است خیلی سریع داده را از دیتابیس خارج کنیم. چگونه می توانیم آنها را تعریف کنیم؟

ما طراحی منطقی و فیزیکی را بررسی کرده ایم. اکنون زمان آن رسیده تا از دیتابیس داده بگیریم. روش های انجام این کار چه هستند؟

توسعه دهنده هایی که کلا با query های اظهاری آشنا نیستند، معمولا به سمت لوپ کردن مکانیزم ها پیش می روند، به عنوان مثال مکان نماهایی (cursor) که داده های یک سطر را در یک زمان بازیابی می کنند، منجر به ناکارآمدی در query می شوند.

Query های منتشر شده تلاش می کنند تا از شاخص های در دسترس استفاده کنند، زیرا آنها query ها را با مکانیزمی تولید می کنند که نتایج شما را تا حد ممکن سریع گزارش می دهند.

مانطور که query های خود را نمایش دادید، دریافتید که به دلایل اجرا ممکن است مجبور باشید نتایج متوسط را در یک ساختار موقت ذخیره کنید.

Trigger ها نوع خاصی از برنامه ی ذخیره شده می باشند که می توانند برای عمل روی فعالیت یک جدول مانند INSERT, UPDATE, یا DELETE نوشته شوند. اگر زیاد از حد استفاده شوند، به طور بالقوه می توانند منجر به عملکردهای اجرایی مانند بلاک کردن (blockin) شوند و اگر به درستی نوشته نشوند ممکن است شما داده ای را از دست بدهید.

چنین ورژنی از برنامه های query در واقع Graphical Execution Plans می باشد که به شما اجازه می دهد یک نمایش گرافیکی از مراحل پردازش query برای یافت نوع بهینه ی آن، پیدا کنید.

قبل از اینکه به چگونگی خواندن برنامه ها بپردازیم، متذکر می شوم که علاوه بر برنامه های گرافیکی، گزینه های دیگری از جمله برنامه های متن محور و xml وجود دارند. این ها روش های مختلفی است که SQL Server می تواند یک برنامه ی query را نمایش دهد.

طرح های برآورد شده بدون اجرا ایجاد می شوند و حاوی یک طرح اجرایی approximate نیز می باشند. این طرح می تواند روی هرگونه کد T-SQL بدون اجرای حقیقی query اجرا شود. بنابراین اگر برای مثال یک UPDATE query داشته باشید، می توانید طرح Estimated Query را بدون اجرای حقیقی UPDATE به دست آورید.

در این بخش ما از دیتابیس AdventureWorksDW برای توضیح بخش هایی از یک طرح Graphical Query استفاده می کنیم. نمونه ی DB از سایت Codeplex site قابل دانلود می باشد.

یک query ساده را اجرا کرده و طرح Actual Graphical Execution را مورد بررسی قرار خواهیم داد.

یک پنجره ی query جدید باز کرده و CTRL+M را فشار دهید تا Actual Execution Plan ( طرح اجرای حقیقی) را وارد کنید و سپس query بالا را اجرا کنید.

سعی می کنیم برخی داده ها را در مورد تولیدات و مولفه های تولید ردیف کنیم. می توانیم از ProductKey (کلید تولید) و Product Subcategory Key (کلید زیرمجموعه ی تولید) برای اتصال داده ها از جدول های مختلف استفاده کنیم. بنابراین query مانند زیر به نظر خواهد رسید.

برای ذخیره ی این طرح های گرافیکی روی پنجره ی Execution Plan راست کلیک کنید و Save Execution Plan As... را انتخاب کنید، یا می توانید گزینه ی Save Execution Plan As... را از منوی File انتخاب کنید. این فایل ها معمولا با گستره ی .sqlplan ذخیره می شوند

ویوهای INFORMATION_SCHEMA به شما اجازه می دهد تا متادیتا مربوط به آبجکت ها را در داخل یک دیتابیس بازیابی کنید. این ویوها در دیتابیس اصلی زیر Views / System Views یافت می شوند و از هر دیتابیس در نمونه ی SQL Server شما فراخوانده می شوند

ویو به شما اجازه می دهد تا اطلاعاتی را در مورد چک کردن محدودیت هایی که در دیتابیس شما هستند، به دست آورید. check constraint محدودیتی است که روی یک ستون خاص اعمال می شود تا اطمینان حاصل شود که قوانین خاص داده توسط ستون دنبال می شود.

ویو INFORMATION_SCHEMA.COLUMN_DOMAIN_USAGE به شما اجازه می دهد تا اطلاعاتی در مورد انواع داده های مستعار به دست آورید که برای ستون ها استفاده می شوند. به طور پیش فرض این اطلاعات در مورد هر جدول و ویو موجود در دیتابیس با نوع داده ی مستعار، نشان داده می شود.

ویو INFORMATION_SCHEMA.COLUMNS به شما اجازه می دهد اطلاعاتی در مورد همه ی ستون ها مربوطبه همه ی جدول ها و ویوهای داخل یک دیتابیس به دست آورید. این ویو این اطلاعات را به طور پیش فرض برای هر جدول مجزا و ویو در دیتابیس، نشان می دهد.

ویو INFORMATION_SCHEMA.TABLES به شما اجازه می دهد تا اطلاعاتی در مورد همه ی جدول ها و همه ی ویوهای داخل یک دیتابیس داشته باشید. به طور پیش فرض این ویو این اطلاعات را برای هر جدول و ویو در داخل دیتابیس ارائه می دهد.

لازم است بتوانم داده هایی را در جدول های خود وارد کنم. فرمان INSERT برای این کار مناسب است، اما باید مثال هایی مربوط به آن نیز ارائه شود. امیدوارم مثال هایی از کدهایی ببینم که بتوانم از آن نکته یا راه حلی دریافت کنم. این آموزش را بررسی کنید تا در مورد SQL Server INSERT نکات بیشتری دریافت کنید.

رای این نکته اجازه بدهید از این نمونه جدول مشتریان، به شکلی در زیر مشاهده می کنید، استفاده کنیم. اطمینان حاصل کنید که برای کامل کردن بخش های باقیمانده ی این نکته، این جدول را در محیط گستزش خود ایجاد کنید.

برای اینکه یک فرمان INSERT بنویسید، لازم است که نام جدول و نام های ستون و مقادیری را که می خواهید به جدول اضافه کنید، بدانید. اجازه بدهید چند مثال از SQL Server INSERT را بررسی کنیم.

همه ی ستون ها دارای مقادیری از فرمان INSERT می باشند، به جز ستون CreateDate که هنگامی ثبت می شود که رکورد وارد می شود.

متغیرها به عنوان وسیله ای برای تعیین مقادیر در کد به جای مقادیر در برنامه نویسی سخت (hard coding) استفاده می شوند. در مثال های ساده ممکن است متغیرها بیش از حد به نظر برسند، اما در هنگام بهبود توسعه، مفاهیم خوبی برای درک می باشند.

به طور کلی متغیرهای یک برنامه با stored procedures برای وارد کردن رکوردها در جدول استفاده می شوند. از آنجایی که چگونگی ایجاد و تعیین متغیرها را بررسی کردیم، اجازه بدهید چگونگی عملکرد آن را در یک برنامه ی ذخیره شده نیز بررسی کنیم.

اجازه بدهید چگونگی استفاده از SQL Server Management Studio را برای ساخت یک عبارت INSERT ساده برای شما بررسی کنیم.

در جدول dbo.Customer که طرح کلی آن را در این آموزش ارائه دادیم، ستون CustomerID یک identity ( ماهیت) می باشد. در اینجا توضیحاتی مربوط به ستون را مشاهده می کنید که قبلا ارائه دادیم:

در برخی از مثال های قبلی از یک SELECT statement برای تایید نتایج عبارت های INSERT استفاده می کنیم. همانطور که می دانید، فرمان INSERT رکوردها را به یک جدول اضافه می کند و عبارت SELECT داده ها را از یک جدول یا بیشتر از یک جدول بازیابی می کند

از آنجایی که تقریبا فرمان SELECT را در آموزش INSERT بیان کرده ایم، اجازه بدهید چگونگی استفاده از فرمان SELECT را برای ایجاد یک جدول جدید و پر کردن آن با داده از جدول موجود، استفاده کنیم.

SQL Server سکوی بزرگی برای دریافت برنامه ی دیتابیس و اجررای سریع آن می باشد. اینترفیس گرافیکی Server Management Studio به شما اجازه ی ایجاد جدول، وارد کردن داده، توسعه ی برنامه های ذخیره شده و غیره را به هیچ عنوان نمی دهد.

ابزار اجرا در sql server

DMVها ابزار بسیار خوبی برای کمک به اجرای عملکرد عیب یابی مربوط به مسائل می باشد و زمانی که قدرت آنها را درک کنید، جزء اصلی Database Administration شما خواهند شد.

SQL Server ابزار بسیار خوبی ارائه می کند که به شما اجازه می دهد تا وضعیت های در حال اجرا را روی SQL Server خود مشاهده کنید،

Windows Performance Monitor or PerfMon ابزار دیگری است برای گرفتن مقیاس ها برای کل سرور شما. تاکنون در مورد DMVs و Profiler بحث کردیم که ابزاری مفید برای دریافت اتفاقاتی است که در داخل نمونه ی SQL Server در حال اجرا می باشند. اما گاهی اوقات مواردی خارج از SQL Server وجود دارند که ممکن است منجر به برخی موارد اجرایی شوند. در این بخش نگاهی به PerfMon چگونگی استفاده از این ابزار خواهیم داشت.

گزارش ها اطلاعات مفیدی را ارائه می دهند که می توانند در تعیین مکان اجرای bottlenecks استفاده شوند. داده ی این گزارش ها از DMVها و همچنین طرح پیش فرض که همیشه در حال اجراست، گرفته می شود.

در هنگام آغاز به کار با طرح های اجرایی، Graphical Plansطرح گرافیکی معمولا ساده ترین راه برای آغاز می باشد، مگر اینکه بسیار پیچیده باشد. پس ازخواندن Text Plans آیانتر می باشد. در اینجا یک query و طرح اجرایی آن را می بینید. برای وارد کردن Actual Execution Plan روی CTRL + M در پنجره ی query فشار داده و سپس کد TSQL را اجرا کنید.

SQL Server دارای ابزار اجرایی دیگری به نام Database Engine Tuning Advisor یا DTA می باشد. این ابزار به شما اجازه می دهد تا SQL Server را وادار به تجزیه ی یک وضعیت یا گروهی از وضعیت ها کنید که با اجرای یک Profiler یا طرح جانبی یک سرور دریافت کرده اید. بنابراین این ابزار وارد هر وضعیت می شود تا تعیین کند پیشرفت ها در کجا می توانند انجام شوند و سپس گزینه هایی را برای پیشرفت به شما ارائه می دهد.

فاکتورهای زیادی وجود دارند که منجر به تنزل اجرای SQL Server می شوند، در این بخش ما برخی از حوزه های متداول را که روی اجرا تاثیر می گذارند، مورد بررسی قرار می دهیم. ابزاری را مورد بررسی قرار خواهیم داد که می توانید برای شناسایی مسائل و همچنین مرور کردن برخی روش های ممکن برای اصلاح این مسائل اجرایی از آنها استفاده کنید.

برای اینکه SQL Server تمامیت داده ها (data integrity) را برای خواندن ها و نوشتن ها استفاده کند، از قفل هایی استفاده می کند، طوریکه تنها یک فرایند در هر زمان کنترل داده را دارد. قفل های زیادی وجود دارند که مورد استفاده قرار می گیرند، از جمله Shared, Update, Exclusive, Intent و غیره و هر کدام از آنها یک رفتار تاثیر متفاوت روی داده ی شما دارند.

یک مسئله ی متداول در مورد SQL Server مسئله ی deadlock می باشد. deadlock زمانی اتفاق می افتد که یک یا چند فرایند روی یک منبع مشترک در انتظار هستند و هر فرایند منتظر تکمیل شدن فرایند دیگر می باشد. وقتی چنین موقعیتی اتفاق می افتد و راهی برای حل این تضاد وجود ندارد، SQL Server یکی از این فرایندها را به عنوان قربانی deadlock انتخاب خواهد کرد و آن را به عقب باز می گرداند. بنابراین فرایند و یا فرایندهای دیگر می توانند به جلو پیش بروند.

روش های زیادی برای بهبود اجرا با قرار دادن سخت افزار وجود دارد، اما موثریت راه زمانی است که query های خود را هماهنگ سازی می کنید. یک مشکل متداول نبود ایندکس ها یا وجود ایندکس های نادرست می باشد، بنابراین SQL Server باید داده های بیشتری را پردازش کند تا رکوردهایی را که با معیارهای query ها مناسب هستند، پیدا کند. این موارد Index Scans و Table Scans نامیده می شوند.

وقتی بخش مربوط به اسکن ایندکس و اسکن جدول را بررسی می کردیم، قادر به حذف اسکنی بودیم که توسط یک Index Seek جایگزین شده بود، اما این امر نیز یک Key Lookup معرفی کرد که مورد دیگری است که ممکن است تمایل به حذف آن برای بهبود اجرا داشته باشید.

بری اینکه اطمینان حاصل کنید که دسترسی به داده تا جایی که ممکن است سریع می باشد، SQL Server مانند سیستم های مرتبط دیتابیس دیگر از نمایه سازی (indexing) برای یافتن سریع داده استفاده می کند. SQL Server ایندکس های مختلفی دازد که ایجاد می شوند، مانند clustered indexes، non-clustered indexes، XML indexes و Full Text indexes.

روش های متفاوت بسیاری وجود دارند که برای مسیریابی اجرای I/O استفاده می شوند، اما همانطور که در بالا ذکر شد با فضای ذخیره سازی NAS/SAN و محیط های مجازی SQL Server. مسیریابی دشوارتر می شود، همچنین قوانین تغییر می کنند و اگر یک I/O bottleneck وجود داشته باشد، برای تعیین چه چیزی باید پیگیری شود. مزیت آن این است که در هر دو سطح ذخیره سازی و سطح مجازی ابزار زیادی برای کمک به اجرا در دسترس می باشند، اما این موارد را در اینجا بررسی نخواهیم کرد.

در طول دوره ای که DBA بودم، اشتباهات متداولی را در هنگام مرور query های SQL مشاهده کردم که برخلاف سیستم هایی که تنظیم می کردم، اجرا می شدند. با این تجربه دریافتم که دستورالعمل های کلی وجود دارند که باید درهنگام نوشتن query ها و همچنین طراحی یک نمودار دیتابیس دنبال شوند.

ترتیبی که طبق آن جدول ها در query های شما به یکدیگر متصل هستند، می تواند یک تاثیر نمایشی روی چگونگی اجراهای query شما داشته باشد. اگر query در ابتدا به جدول های بزرگتر و سپس به جدول های کوچکتر متصل شود، این امر باعث انجام پردازش های غیرضروری بسیاری توسط موتور SQL می شود.

استفاده از عملکردها به عنوان نوعی از برنامه نویسی معمولا تمرین خوبی است، چرا که به طور کل کد را خواناتر کرده و به شما اجازه می دهد که بارها بارها از آن استفاده کنید. این مسئله در مورد queryهای SQL هم درست میباشد، به جز در این مورد که مواردی وجود دارند که در هنگام اجراهای پشت سر هم یک وضعیت، ممکن است راه موثری برای رسیدن به نتیجه نباشد.

در بسیاری از موارد وقتی از اپراتور <> استفاده می کنیم (یا هر اپراتور دیگری در ارتباط با NOT، به عنوان مثال NOT IN) جستجوهای ایندکس اجرا نخواهند شد و در عوض اسکن یک جدول یا ایندکس لازم می باشد.

همانطور که در موضوعات قبلی ذکر کردیم، فراخوانی عملکردها کد را خواناتر کرده، اما در برخی موارد باعث تاثیرات ناخواسته ی دیگری می شوند که اجرای queryهای ما را کاهش می دهد. سناریوهای خاص استفاده از یک عملکرد در یک عبارت WHERE یکی از این موارد می باشد.

هنگامی که از اپراتور LIKE استفاده می کنید و اولین کاراکتر در رشته ی جستجو یک کاراکتر wildcraft باشد، % یا SQL Optimizer مجبور خواهند بود که اسکن یک جدول یا ایندکس را در هنگام اجرای query انجام دهند.

استفاده از یک جدول مشتق شده به جای IN predicate زمانیکه در حال گردآوری داده هستیم، به ما اجازه می دهد تا فقط رکوردهای خاصی از جدول را پردازش کنیم، بنابراین کاهش منابع نیاز به اجرای یک query دارد.

وقتی که یک ایندکس می تواند به اجرای یک query و ستون هایی که JOIN predicate شما را تشکیل می دهند، کمک کند سناریوهای مختلفی وجود دارد و مسئله ی مهمی می باشد.

ترتیبی که ستون ها در ایندکس های شما تعیین می شوند، بر این موضوع تاثیر دارد که هنگامی که SQL Optimizer، query شما را تجزیه می کند، آیا کل ایندکس مورد استفاده قرار می گیرد یا نه.

دو نوع ذخیره سازی برای جدول ها درSQL Server وجود دارد، جدول های Heap و جدول های Clustered. جدول های Heap جدول هایی هستند که clustered index روی خود ندارند و جدول های Clustered جدول هایی هستند که دارای clustered index می باشند. دلایل کمی وجود دارند که علت توصیه شدن به اینکه جدول ها دارای clustered index باشند را توضیح می دهند.

استفاده از گزینه ی DELETE CASCADE در تعاریف محدودیت کلید خارجی به معنای اجرای بهتر و کد کمتر در هنگام حذف رکدوردها از جدول هایی است که دارای یک رابطه ی parent-child تعریف شده می باشند.

نمودار denormalize گاهی اجرای بهتری برای query ارائه می دهد، گرچه ممکن است به معنای ذخیره ی داده های غیرضروری باشد. تنها سوال که مطرح می شود این است که فضای اضافه استفاده شده به سود اجرا می افزاید.

یکی از سخت ترین کارهایی که برنامه نویسان و مدیران پایگاه داده همواره با آن مواجه هستند، نگهداشت اسکریپت های نصب و بروز رسانی پایگاه داده از یک نسخه به نسخه ی دیگر است. برای این منظور متدها و ابزارها مختلفی همچون اسکریپت های SQL که از طریق پنجره ی فرمان SQLCMD اجرا می شوند یا حتی نوشتن سیستم های اختصاصی که فرایند ایجاد و بروز رسانی پایگاه داده را مدیریت می کند، مورد استفاده قرار می گیرند. بی شک رصد dependency ها بین اشیا (object ها) برای کسب اطمینان از نصب یا بروز رسانی (upgrade) موفقیت آمیز و همچنین ایجاد اسکریپت هایی که یک بانک اطلاعاتی را از schema version جاری به آخرین ویرایش ارتقا می دهند، جزء پردردسرترین بخش ها و عملیات است. این دست فرایندها معمولا دستی بوده و می توانند بسیار پر زحمت باشند. با توجه به آنچه گفته شد، متاسفانه احتمال بروز خطا نیز در آن ها پایین نیست.

پنجره ای به نام New Project مانند زیر پدیدار می شود. همان طور که مشاهده می کنید مقدار فیلدهای Name و Solution Name از پیش تعیین شده است. می توانید مقادیر پیش فرض این فیلدها را مطابق میل تنظیم نمایید. اگر ورژن مورد استفاده ی شما Visual Studio 2010 Professional یا ویرایش جدیدتر است، در آن صورت گزینه ای به نام Database را در آن مشاهده خواهید کرد. بر روی گزینه ی Advanced در کادر کناری Recent Templates کلیک نمایید. در این آموزش می خواهیم یک پروژه ی جدید پایگاه داده (database project) به نام namedDemoDB و یک solution جدید به نام Tips برای میزبانی آن ایجاد کنیم.

این صفحه جایی است که می توانید گزینه های مختلفی در آن تعریف کنید، از جمله تلفیق دیتابیس پیشفرض و مدل ریکاوری پیش فرض برای هر استقرار (deployment).

اکنون پروژه را ایجاد کرده و برخی از تنظیمات آن را بررسی/تعریف کردیم. در این آموزش خواهیم آموخت چگونه می توان رفتار ایجاد و بازطراحی (refactor) فرایند deployment را کنترل کرد.

پایگاه داده ی خود را ایجاد کرده، خاصیت های مربوط به نصب و مستقر سازی (deployment properties) و نیز تنظیمات پایگاه داده را (تعریف و) پیکربندی کردیم. حال زمان آن فرا رسیده تا یک جدول ایجاد و به پایگاه داده ی خود اضافه کنیم.

جدول مورد نظر را در پایگاه داده ایجاد کردیم و اکنون می خواهیم کلید اصلی (primary key) را به آن اضافه نماییم. علاوه بر آن می خواهیم با استفاده از تعدادی رویه ی ذخیره شده (stored procedure)، به داده هایی که در جدول مزبور درج می کنیم دسترسی داشته باشیم.

گاهی لازم است به هنگام ایجاد و بروز رسانی پایگاه داده، داده هایی را به آن اضافه کرده، داده های جاری را ویرایش یا آن ها را حذف کنید. علاوه بر آن، ممکن است لازم باشد عملیات خاصی قبل و/یا بعد از اتمام فرایند مورد نظر بر روی پایگاه داده انجام شود. برای مدیریت چنین سناریویی کافی است از deployment script استفاده نمایید.

قبل از ساخت و گسترش حقیقی، باید مطکئن شویم که پراپرتی های ساخت و گسترش پروژه ی ما تنظیم شده اند. قبل از گسترش لازم است پروژه را برای عملکردهای Build و Deploy آماده کنیم. ابتدا لازم است پراپرتی های پروژه را با انتخاب DemoDB Properties... از منوی Project ویرایش کنیم.

تمامی عملیات مورد نیاز (و اولیه) جهت آماده سازی اولین نصب یا deployment پایگاه داده را انجام دادیم. حال می خواهیم به فرایند ایجاد خود پایگاه داده بپردازیم.

در یک برهه ای از زمان، پایگاه داده بایستی با اضافه شدن اشیا جدید یا حذف اشیا جاری از آن و نیاز کد پایگاه داده به ویرایش، بروز رسانی شود.

یک برنامه ی ذخیره شده چیزی جز کد SQL که ذخیره کرده اید، نیست بنابراین می توانید از این کد بارها و بارها استفاده کنید. بنابراین اگر به جای اینکه مجبور باشید query را هر زمان که به عنوان یک برنامه ذخیزه (stored procedure) کردید بنویسید، به یک query که بارها و بارها نوشته اید، فکر می کنید، می توانید برنامه ی ذخیره شده را فرابخوانید تا کد SQL ذخیره شده را به عنوان بخشی از برنامه ی ذخیره شده اجرا کنید.

گزینه های مختلفی وجود دارند که می توانند برای ایجاد برنامه های ذخیره (stored procedures) شده استفاده شوند. در موضوعات بعدی در مورد ایجاد یک برنامه ی ذخیره شده ی ساده با گزینه های پیشرفته می باشد.

همانطور که قبلا ذکر شده یک روش ذخیره شده چیزی به جز یک کد ذخیره شده ی SQL نیست که از آن بارها و بارها استفاده می کنید. در این قسمت ایجاد یک روش ذخیره شده ی ساده را بررسی می کنیم.

قدرت واقعی روش های ذخیره شده توانایی انتقال پارامترها و واداشتن روش ذخیره شده به بررسی درخواست های متفاوتی که انجام می شود، می باشد. در این قسمت انتقال مقادیر پارامتر را به یک روش ذخیره شده بررسی می کنیم.

در بخش قبل در مورد چگونگی انتقال پارامترها به یک روش ذخیره شده (stored procedure) صحبت کردیم، اما گزینه ی دیگر انتقال مقادیر پارامتر از یک روش ذخیره شده به عقب می باشد. یک گزینه ی ممکن برای این کار این است که روش ذخیره شده ی دیگری را فرابخوانید که هیچ داده ای را گزارش نمی دهد، اما مقادیر پارامتر مورد استفاده با فراخوانی stored procedure را گزارش می دهد.

یک گزینه ی بسیار خوب که به SQL Server 2005 اضافه شد، توانایی استفاده از نمونه ی Try..Catch بود که در دیگر زبان های توسعه وجود دارد. انجام برطرف کردن خطاها در SQL Server همیشه کار آسانی نبوده است، بنابراین این گزینه قطعا برنامه ی رسیدگی و رفع خطاها را آسانتر می کند.

کار ساده ای که انجام آن با stored procedures موثر خواهد بود، افزودن کامنت ها به کد می باشد. این به شما کمک می کند تا بدانید که چه کاری و چرا انجام شده و همچنین به دیگر DBAها و توسعه دهنده ها کمک می کند تا اگر لازم است اصلاحاتی روی کد انجام دهند.

کار خوبی که می توان در مورد همه ی آبجکت های SQL Server انجام داد، نام گذاری یک مکالمه برای استفاده می باشد. قانون سخت و سریعی در این مورد وجود ندارد، بنابراین این فقط یک راهنمایی برای آنچه باید انجام شود، می باشد.

تکنیک های زیادی در هنگام نوشتن کد T-SQL وجود دارد. یکی از آنها کاهش مقدار داده ی شبکه برای هر عبارت می باشد که در داخل روش های ذخیره شده ی شما اتفاق می افتند. هر زمان که یک عبارت SQL اجرا می شود، تعداد ردیف هایی را که تحت تاثیر بوده اند، گزارش می دهد. با استفاده از "SET NOCOUNT ON" در داخل روش ذخیره شده می توانید این پیغام ها را مسدود کرده و ترافیک را کاهش دهید

علاوه بر ایجاد روش های ذخیره شده، نیاز به حذف این روش ها نیز میباشد. این بخش چگونگی حذف روش های ذخیره شده که دیگر مورد نیاز نیستند را نشان می دهد.

اصلاح یا تغییر یک روش ذخیره شده کاملا ساده می باشد. وقتی که یک روش ذخیره شده یجاد می شود، در یکی از جدول های سیستم در دیتابیسی که ایجاد شده بود، ذخیره می شود. وقتی که یک روش ذخیره شده را اصلاح می کنید، آن ورودی که در ابتدا در جدول سیستم ساخته شده بود، به وسیله ی این کد جدید جایگزین می شود. SQL Server نیز دفعه ی بعد که اجرا شود، روش ذخیره شده را مجددا کامپایل می کند، بنابراین یوزرهای شما در حال استفاده از منطق جدید هستند. فرمان برای اصلاح یک روش ذخیره شده ALTER PROCEDURE یا ALTER PROC می باشد.

Report Builder ابزار نوشتن گزارش برای یوزرهای تجاری در مایکروسافت می باشد. این برنامه دارای یک یوزر اینترفیس ساده می باشد که شبیه Microsoft Office است. این آموزش تمام آنچه را که برای نوشتن Report Builder 3.0 نیاز دارید، به شما آموزش خواهد داد که با SQL Server 2008 R2 منتشر شد.

Report Builder 3.0 درواقع برنامه ای است که با یک بار کلیک کردن به شما اجازه ی اجرا بدون نصب می دهد. وقتی که SQL Server Reporting Services (SSRS) 2008 R2 را نصب می کنید، باید سرویس های گزارش (Reporting Services) را پیکر بندی کنید تا یک سبک داخلی و یا سبک SharePoint

Report Builder 3.0 دارای یک یوزر هوشمند و آشنا می باشد که به شما اجازه ی ایجاد سریع گزارش ها را می دهد. این بخش نگاهی اجمالی به اینترفیس یوزر Report Builder دارد و حاوی موضوعات زیر می باشد:

برای شروع Report Builder را از گروه برنامه ی Microsoft SQL Server 2008 R2 Report Builder آغاز کنید. به طور پیش فرض این صفحه فورا پس از آغاز به کار Report Builder نمایش داده می شود.

معمولا هر برنامه دارای یک منوی اصلی با گزینه هایی برای ایجاد، باز کردن، ذخیره و غیره می باشد. این منو معمولا File نامیده می شود. در Report Builder یک منوی File پیدا نخواهید کرد، اما همان قابلیت وجود دارد. این بخش منوی اصلی Report Builder را بررسی می کند.

صفحه ی Getting Started تنها زمانی نمایش داده می شود که Report Builder آغاز به کار کرده است ( و فقط در Report Options تعیین می شود). پس از اینکه انتخاب هایی از صفحه ی Getting Started انجام دادید یا آن را بستید، نمی توانید به آن صفحه بازگردید. این بخش صفحات New Report یا Dataset را بررسی می کند که از منوی Report Builder در دسترس می باشد.

Report Editor تجربه ی طراح برای ایجاد، ویرایش و مشاهده ی گزارش ها ارائه می دهد. یوزر اینترفیس دارای ظاهر Microsoft Office می باشد. این بخش یک دید اجمالی از بخش های مختلف report editor ارائه می دهد.

یک منبع داده جزئیات لازم برای انتشار یک اتصال به یک ارائه دهنده ی داده را تامین می کند. یک Report Builder ازطریق برخی ارائه دهنده ها مانند دیتابیس SQL Server و یا مکعب SQL Server Analysis Services می تواند به داده دسترسی داشته باشد. در این بخش در مورد انواع مانبع داده بحث می شود و ایجاد یک نمونه از آنها که در ساخت نمونه ی گزارشات استفاده می شود، بررسی خواهد شد.

یک دیتاست حاوی یک query یا یک روش ذخیره شده می باشد که داده را برای نمایش روی گزارشما بازمی گرداند. این بخشدو نوع دیتاست را بررسی کرده و به ایجاد یک دیتاست می پردازد که برای ساخت نمونه ی گزارش ها استفاده خواهد شد.

Report Builder دارابی تنظیماتی است که باید از آنها آگاه باشید. این قسمت در مورد صفحه ی Report Builder Options بحث می کند.

Report Builder 3.0 در واقع wizard هایی را ارائه می دهد که به شما اجازه می دند که خیلی سریع گزارش هایی را ایجاد کنید. دیدگاه wizard به شما در ایجاد مرحله به مرحله ی یک گزارش کمک می کند. وقتی که شما در حال ایجاد اولین گزارش ها هستید، بهره بردن از wizard ها نیز فکر خوبیست. همانطور که تجربه ی بیشتری در مورد Report Builder به دست می آورید، ممکن است انتخاب کنید که wizard ها عبور کرده و گزارشات خود را از scratch طراحی کنید که به شما اجازه می دهدتا گزارش هایی به روش خود ایجاد کنید و ورای آنچه wizard ها ارائه می دهند بروید.

جدول یا ماتریکس wizard شما را در ایجاد مرحلخ به مرحله ی گزارش کمک می کند. در این بخش اولین گزارش خود را با استفاده wizard ایجاد خواهیم کرد.

Chart Wizard شما را در ایجاد یک گزارش که حاوی چارت می باشد، مرحله به مرحله راهنمایی می کند. در این بخش با استفاده از wizard یک چارت ایجاد خواهیم کرد.

Wizard guides شما را مرحله به مرحله در ایجاد یک گزارش که حاوی نقشه باشد، راهنمایی می کند. این بخش یک نقشه با استفاده از wizard ایجاد می کند.

در بخش قبل با استفاده از wizard سه نمونه گزارش ایجاد کردیم که مرحله به مرحله ما را در ایجاد گزارش راهنمایی می کردند. این یک روش بسیار خوب برای آغاز می باشد، اما ممکن است بخواهید در هنگام ایجاد کنترل بیشتری در طراحی گزارش داشته باشید.

Report Header قسمت بالای گزارش میباشد و معمولا حاوی تیتر گزارش، شماره ی صفحه، تاریخ و ساعت اجرا و غیره می شود. این بخش در مورد افزودن تیتر به یک گزارش می باشد.

Report Footer قسمت پایین یک گزارش می باشد که ممکن است حاوی شماره ی صفحه، تاریخ و ساعت اجرا، اطلاعیه ی محرمانه و غیره باشد. این مبحث به بررسی مراحل افزودن report footer به یک گزارش می پردازد.

Report Body بخشی از گزارش است که بین Report Header و the Report Footer قرار دارد و حاوی محتوای گزارش است. این مبحث مراحل ایجاد بدنه ی گزارش را بررسی می کند. ما یک ماتریکس داده به گزارش اضافه خواهیم کرد و داده هایی از دیتاست مشترک که در بخش Getting Started ایجاد کردیم، در آن قرار می دهیم.

وقتی توسعه ی گزارش را به پایان رساندید، نیاز به گسترش آن دارید تا آن را در دسترس افراد مناسب قرار دهید. این بخش نگاه اجمالی به گزینه های گسترش در Report Builder 3.0 دارد.

اگر در حال یادگیری زبان T-SQL هستید، آغاز کردن با وضعیت SELECT بسیار موثر خواهد بود. وضعیت SELECT فرمان مرکزی برای دسترسی به داده در SQL Server می باشد. مهمترین مولفه های یک وضعیت SELECT عبارتند از:

در پایه ترین سطوح، یک ستون مجزا از یک لیست SELECT قابل دسترسی می باشد. در این محیط تمام مقادیر از ستون از یک جدول بازگردانده خواهند شد. اجازه بدهید مثالی را بررسی کنیم.

برای توضیح بیشتر در مورد بخش قبل ستون های چندگانه از طریق یک وضعیت مجزای SELECT قابل دسترسی می باشند. در این محیط تعداد کمی ستون های مختلف را از یک جدول انتخاب می کنیم و همه ی ردیف های مرتبط بازگردانده خواهند شد. اجازه بدهید یک مثال ساده را بررسی کنیم.

در این مثال یک ستون مجزا از عبارت SELECT خود باز می گردانیم و برای محدود کردن رکوردهای بازگشت داده شده، یک عبارت WHERE اضافه می کنیم. در این محیط همه ی مقادیر مربوط به ستون تنها زمانی از جدول بازگردانده می شوند که معیارهای WHERE حاصل می شوند. اجازه بدهید مثالی را مورد بررسی قرار بدهیم.

در این آموزش وضعیت های مختلفی از SELECT را اب عبارات ORDERED BY انتشار می دهیم تا نشان دهیم که چگونه داده می تواند هم در حالت صعودی و هم نزولی ذخیره شود. قصد داریم مثال هایی ارائه دهیم با ستون های ع ددی، ستون های بر اساس کاراکتر و تاریخ. همچنین مثال هایی از ترکیب این ستون ها و منطق ORDERED BY نیز ارائه خواهیم داد. اجازه بدهید یک مثال را بررسی کنیم.

در مثال زیر در حال انتخاب ستون LoginID از جدول HumanResources.Employee هستیم که در آن ستون VacationHours برابر 8 می باشد و ما داده را با HireDate در یک ترتیب صعودی به کار گرفته شده مرتب می کنیم.

هدف از نام مستعار گذاشتن برای یک جدول داشتن یک مخفف از آن جدول می باشد. معمولا نام بلند یک جدول به راحتی با یک تا سه کاراکتر مخفف می شود. با انجام چنین کاری کد مربوط به آن جدول کوتاه تر و خواندن آن نیز در هنگام مشکا راحت تر می باشد. انجام این مرحله ی کوتاه منجر به مرحله ی ساده تر بعدی با JOINS می شود در آن نام گذاری جدول بسیار مهم است. اجازه بدهید نگاهی به یک مثال بیندازیم.

از مثال های قبلی تصمیم داشتم پی ببرم که چگونه SQL Server Management Studio (SSMS) را دریافت کنم تا برای من کاری انجام دهد. چگونه می توانم به جای تایپ کردن هر ستون، این ابزار را وادار به تولید یک وضعیت SELECT کنم؟

ترکیب JOIN در SQL Server برای ساخت یک مجموعه ی نتیجه ی مجزا از بیشتر از یک جدول استفاده می شود. در پایه ترین سطح دو جدول براساس یک مجموعه ی متداول بین جدول ها به هم متصل می شوند. اتصالات به روش های مختلفی کد گذاری می شوند، اما در این مثال ما از منطق INNER JOIN برای بازگردانی ردیف های هماهنگ شده از هر دو جدول استفاده می کنیم. جدول های مشمول در منطق JOIN در عبارت FROM مشخص می شوند. یک وضعیت ON برای نشان دادن ستون های هماهنگ استفاده می شود. اجازه بدهید به بررسی مسئله بپردازیم.

اگر بازگدانی بک آپ را نمی دانید، گرفتن بک آپ خوب می باشد. در این بخش بررسی خواهیم کرد که چه گزینه هایی از بک آپ در دسترس می باشند و کدام گزینه ها تنها با استفاده از فرمان های T-SQL قابل دسترسی می باشند. همانطور که مشاهده خواهید کرد، گزینه های بسیاری می توانند مورد استفاده قرار بگیرند، اما درست مانند فرمان های BACKUP، تنها بخشکمی از فرمان RESTORE وجود دارد که برای انجام یک بازگردانی موفق لازم می باشند. زمانی را برای مرور هرکدام از این گزینه ها بگذارید تا درک خوبی از آنچه در دسترس است داشته باشید.

زمانی را بگذارید تا از گزینه های موجود و آنچه می تواند با استفاده از SQL Server Management Studio و گزینه هایی که فقط از طریق فرمان های T-SQL در دسترس هستند، انجام شود، درک بهتری داشته باشیم.

گزینه ی RESTORE HEADERONLY به شما اجازه می دهد تا اطلاعات تیتر بک آپ را برای همه ی بک آپ های یک دستگاه بک آپ خاص مشاهده کنید. بنابراین در یسیاری موارد هر بک آپ که شما ایجاد می کنید، دارای تنها یک بک آپ ذخیره شده در یک فایل فیزیکی می باشد، بنابراین شما احتمالا تنها یک تیتر می بینید، اما اگر اگر چند بک آپ در یک فایل داشته باشید، اطلاعاتی در مورد هر بک آپ مشاهده خواهید کرد. توضیحات: گزینه ی RESTORE HEADERONLY می تواند به سادگی برای یک بک آپ موجود روی دیسک مانند زیر منتشر شود. دریافت اطلاعات headeronly از یک بک آپ کامل

گزینه ی به شما اجازه می دهد تا اطلاعات بک آپ مدیا را برای دستگاه بک آپ ببینید. بنابراین اگر یک دستگاه بک آپ مانند یک فایل بک آپ، دارای بک آپ های متعددی است، شما تنها رکورد یکی را دریافت خواهید کرد که به شما اطلاعاتی در مورد مجموعه ی مدیا از قبیل نرم افزاری که برای ایجاد بک آپ استفاده شد، تاریخ ایجاد مدیا و غیره را می دهد.

گزینه ی RESTORE FILELISTONLY به ما اجازه می دهد تا لیستی از فایل هایی که بک آپ گرفته شده اند را مشاهده کنیم. بنابراین برای مثال اگر شما یک بک آپ کامل داشته باشید، تمام فایل های داده (mdf) و فایل های log (ldf) را مشاهده خواهید کرد.

گزینه ی RESTORE DATABASE به ما اجازه می دهد تا یک بک آپ کامل، متفاوت و یا filegroup را بازگردانی کند. توضیحات: در هنگام بازگردانی یک دیتابیس به دسترسی مجزا به دیتابیس نیازخواهیم داشت که به این معناست که هیچ یوزر متصل دیگری نمی تواند از دیتابیس استفاده کند. گزینه ی RESTORE DATABASE می تواند با استفاده از T-SQL یا SQL Server Management Studio انجام شود.

فرمان RESTORE LOG به شما اجازه می دهد تا یک بک آپ transaction log را بازگردانی کنید. گزینه ها بازگردانی را وارد کل transaction log می کنند یا به نقطه ی خاصی در زمان یا به یک تراکنش خاص اختصاص می دهند.

فرمان RESTORE VERIFYONLY بک آپ را چک می کند تا اطمینان حاصل شود که این بک آپ کامل بوده و کل آن خوانا می باشد. این فرمان یک بازگردانی حقیقی انجام نمی دهد، اما فایل را خوانده تا مطمئن شود که SQL Server می تواند آن را در رویدادی بخواند که یک بازگردانی با استفاده از این بک آپ اتفاق می افتد.

علاوه بر فرمان هایی که تقریبا مورد بحث قرار دادیم، گزینه های بسیار دیگری نیز وجود دارند که می توانند به همراه این این فرمان ها استفاده شوند.

گزینه ی RESTORE ... WITH RECOVERY دیتابیس را در یک وضعیت قابل استفاده قرار می دهد، بنابراین یوزرها می توانند به یک دیتابیس ترمیم شده ( restored database ) دسترسی داشته باشند. توضیحات: وقتی که شما فرمان RESTORE DATABASE یا RESTORE LOG را منتشر می کنید، گزینه ی WITH RECOVERY به طور پیش فرض استفاده می شود. این گزینه لازم نیست به این عملکرد اختصاص داده شود تا اتفاق بیفتد.

وقتی که شما یک فرمان RESTORE DATABASE یا RESTORE LOG را منتشر می کنید، گزینه ی WITH NORECOVERY به شما اجازه میدهد تا قبل از بهبود دیتابیس فایل های بک آپ بیشتری را بازگردانی کنید. بنابراین این برنامه به شما اجازه می دهد تا قبل از اینکه به یوزرهای نهایی خود اجازه ی دسترسی به داده را بدهید، تا جایی که ممکن است آخرین دیتابیس را دریافت کنید.

گزینه ی RESTORE WITH STATS به شما اجازه می دهد تا مشاهده کنید تا چه حد همراه فرایند بازگردانی می باشید، این امر میتواند برای RESTORE DATABASE, RESTORE LOG, RESTORE VERIFYONLY استفاده شود.

گزینه ی RESTORE ... WITH REPLACE به شما اجازه می دهد تا هنگام انجام یک بازگردانی، یک دیتابیس موجود را چندین بار بنویسید. در برخی موارد هنگامی که سعی در انجام یک (بازگردانی) restore دارید، ممکن است خطایی دریافت کنید که می گوید: "The tail of the log for the database .. has not been backed up" ( دنباله ی log برای دیتابیس .... بک آپ گرفته نشده است.)

گزینه ی RESTORE ... WITH MOVE به شما اجازه خواهد داد تا دیتابیس خود را بازیابی کنید، اما یک موقعیت جدید نیز برای فایل های دیتابیس تعیین می کند (mdf و ldf). اگر درحال بازگردانی یک دیتابیس موجود از بک آپ آن دیتابیس می باشید، این مسئله لازم نیست، اما اگر درحال بازگردانی دیتابیس از یک نمونه ی متفاوت با موقعیت های متفاوت هستید، به این گزینه نیاز خواهید داشت.

گزینه ی RESTORE ... WITH STOPAT اجازه ی بازگردانی دیتابیس را در یک نقطه اززمان به شما می دهد. این امر به شما توانایی بازگردانی یک دیتابیس به قبل از یک رویداد را می دهد که برای دیتابیس شما مفید نبود. برای اینکه این گزینه کار کند، دیتابیس نیاز به مدل ریکاوری FULL یا Bulk-Logged دارد و شما نیز لازم است بک آپ های transaction log را انجام دهید.

در هنگام بازگردانی یک دیتابیس، کاری که لازم است انجام دهید، این است که اطمینان حاصل کنید که به دیتابیس دسترسی دارید. اگر یوزر دیگری در دیتابیس باشد، بازگردانی شکست خواهد خورد. توضیحات: وقتی سعی می کنید یک بازگردانی را انجام دهید، اگر یوزر دیگری در دیتابیس باشد، پیغام های خطایی مشابه زیر دریافت خواهید کرد:

ميدانيم كه بعضي از مقادير مثل 242 يا james kningt مقاديري ثابت هستند چون قبل و بعد از اجراي برنامه دست نخورده باقي ميمانند.

هر مدل ریکاوری اجازه بکاپ گرفتن از کل یا جزیی از دیتابیس SQL Server یا فایل های مستقل یا گروهی از فایل های دیتابیس را می دهد. ولی بکاپ های در سطح جدول (Table-level backups) را نمی توان ایجاد کرد.

همتاسازی (replication)، راه حلی مناسب برای مشکل انتقال داده ها بین سرورهای همیشه متصل است. با استفاده از ویزارد همتاسازی می توانید مکان شناسی (topology) همتاسازی را براحتی پیکربندی و مدیریت کنید. این مقاله به شما چگونگی پیکربندی توپولوژی سرورهای همیشه متصل را نشان می دهد.

Replication

تراکنشی replication تراکنشی به طور عمده توزیع یک طرفه تراکنش ها از منتشر کننده به مشترک را امکان پذیر می کند. از replication های تراکنشی می توان با پیکره بندی ها و option های مختلف استفاده کرد.

Replication ادغامی جایگزین دیگری است که می توان برای سیستم های با درجه دسترس پذیری بالا استفاده کرد. Replication ادغامی به طور عمده برای کاربران سیار نامتصل (disconnected) طراحی شده. مکانیسم هایی به صورت تو کار قرار داده شده که تغییرات هر مکانی را سنکرون می کند، بعلاوه در برابر failure ها مقاوم بوده و پردازش را ادامه می دهد.

این مقاله چگونگی ایجاد یک Transact-SQL stored procedure را با استفاده از Object Explorer در SQL Server Management Studio توضیح می دهد و مثالی آورده که یک stored procedure ساده را در AdventureWorks database ایجاد میکند.

SQL server، ویژگی هایی را در اختیار می گذارد که می توانید برای رهگیری (auditing) فعالیت ها و تغییراتی که روی سیستم روی می دهد استفاده کنید. این مقاله لینک هایی را در اختیار شما می گذارد که بشما کمک می کنند اطلاعاتی را که برای رهگیری در موتور بانک اطلاعاتی SQL Server نیاز دارید، پیدا کنید.

این مقاله چگونگی حذف کردن یک stored procedure را با استفاده از Explorer در SQL Server Management Studio توضیح می دهد...

این مقاله چگونگی اصلاح کردن یک Transact-SQL Stored procedure را با استفاده از Object Explorer در SQL Server Management Studio توضیح می دهد... این مقاله چگونگی اصلاح کردن یک Transact-SQL Stored procedure را با استفاده از Object Explorer در SQL Server Management Studio توضیح می دهد.

این مقاله مفاهیم پایه ای فشرده سازی بکاپ در SQL Server، شامل اجرای فشرده سازی بکاپ ها را مورد بحث قرار می دهد.

چگونگی مشاهده Dependencyهای یک Stored Procedure (SQL Server Management Studio) این مقاله چگونگی مشاهده Dependencyهای یک Stored Procedure را با استفاده از Explorer در SQL Server Management Studio توضیح می دهد.

این مقاله چگونگی تغییر نام یک Stored Procedure را با استفاده از Explorer در SQL Server Management Studio توضیح می دهد...

شرکت ماکروسافت، Language Integrated Query یا LINQ را همراه با.NET Framework 3.5 معرفی کرد. LINQ، برنامه نویسان را قادر به query کردن منبع داده ها با استفاده از یک query مانند syntax با C# و VB.NET می کند. این منبع داده ها می توانند collectionها، بانک های اطلاعاتی SQL Server، XML، و datasetها باشند.

SQL Server Integration Services یا SSIS، ابزاری است که برای اجرای عملیات های ETL مانند extract کردن، transform کردن، و load کردن داده ها مورد استفاده قرار می گیرد.

در این بخش مراحل زیر را مورد بررسی قرار خواهیم داد: ایجاد یک پکبج SSIS جدید و بررسی بعضی از پراپرتی های پکیج اضافه کردن Connection Managers به منبع و مقصد داده ها .....

LINQ to SQL به برنامه نویسان .NET اجازه نوشتن queryها را درزبان .NET می دهد تا بتوانند داده ها را از بانک اطلاعاتیSQL Server بازیابی و تغییر دهند...

بسیاری از دستورات اجرایی روی پایگاه داده نیاز به پارامترهای داده ای دارند که لازم است فراهم شده و هنگام اجرای دستور مقادیرشان به دستور مربوطه ارسال شده باشد. در این بخش از آموزش سی شارپ و مباحث پایگاه داده در سی شارپ (ADO.NET) به این موضوع و کار با کلاس SqlParameter خواهیم داشت.

این مقاله ویژگیهای جدید CLR integration در SQL Server 2005 را توصیف می کند و توضیح می دهد که چگونه یک database application developer و architectها می توانند از آنها جهت نوشتن رویه ها(procedure)، functionها، و triggerهایی که توسط کاربر تعریف شده اند، استفاده کنند.

حل کردن مشکلات رایج در Database Programming بخش قبلی، برنامه نویسی بر پایه CLR را در سطحی بالاتر که راجع به T-SQL، extended stored procedures XPها(، و کدی در middle-tier است، قرار داد. در این بخش، ما نگاهی به دسته ای از taskها و الگوهایی (pattern) که یک database application developer ممکن است با آن مواجه شود، خواهم انداخت

اگر فرض کنیم که متد GetStrings() تحت عنوان یک TVF با همان نام ثبت شده است، آنگاه مثلا زیر، قطعه ای از T-SQL از یک stored procedure است که از این TVF برای بیرون کشیدن (extract) line items ، در شکل جدولی استفاده می کند.

پایگاه داده رابطه‌ای به آن دسته از پایگاه‌های داده اطلاق می‌شود که بر اساس مدل رابطه‌ای طراحی و ایجاد شده باشند. پس از پایگاه‌های داده‌ای سلسله مراتبی و شبکه‌ای، که هر یک دارای ضعف‌هایی بودند، متخصصان در جستجوی مدلی بودند که دارای ساختار داده‌ای با انتزاع قوی ابداع گردید