راهنمای جامع دستورات کاربردی SQL Server
مقدمه
دستورات کاربردی SQL Server حلقه اتصال میان کدنویسی T-SQL، مدیریت Session، کنترل خطا، نگهداری پایگاه داده و بازیابی حادثه هستند. دانستن شکل ظاهری فرمان کافی نیست؛ متخصص باید بداند دستور در چه Scopeی اثر میگذارد، چه مجوزی لازم دارد، چه خروجیای تولید میکند و شکست آن چگونه کنترل میشود.
این راهنما چهارده موضوع مستقل را در یک مسیر منظم گردآوری میکند: PRINT، RAISERROR، THROW، WAITFOR، SET، USE، DECLARE، SET IDENTITY_INSERT، DBCC، CHECKPOINT، BACKUP، RESTORE، KILL و یک مقاله جمعبندی. برای هر موضوع، صفحهای مستقل با ده مثال، خروجی نمونه، FAQ، Performance و Best Practice در دسترس است.
فرمانهای سادهای مانند DECLARE یا PRINT معمولاً در Scope یک Batch کار میکنند، اما فرمانهایی مانند RESTORE و KILL میتوانند سرویس یا کاربران را تحت تأثیر قرار دهند. بنابراین سطح کنترل، تأیید و آزمایش باید متناسب با دامنه اثر افزایش یابد.
در همه نمونهها، متن فارسی با رشته یونیکد، تاریخ فنی با قالب مستقل از زبان و خطا با TRY/CATCH مدیریت میشود. فرمانهای عملیاتی دارای مسیر و نام نمونهاند و قبل از اجرا در محیط واقعی باید با زیرساخت مقصد تطبیق داده شوند.
اصل راهنما: هر دستور باید مقصد روشن، ورودی معتبر، مسیر خطا، معیار موفقیت و مالک عملیاتی مشخص داشته باشد.
دسترسی سریع به مقالههای تخصصی
جدول مقایسه دستورات
| دستور یا موضوع | کاربرد اصلی | خروجی یا نکته مهم | لینک آموزش کامل |
|---|
| PRINT | نمایش پیام متنی و اطلاعات تشخیصی در پنجره Messages کلاینت SQL است و برای ردگیری اجرای اسکریپتهای مدیریتی و استقرار کاربرد دارد. | Result Set برنمیگرداند و پیام را در کانال Messages ارسال میکند. طول پیام برای varchar حدود ۸۰۰۰ و برای nvarchar حدود ۴۰۰۰ کاراکتر محدود است. | مطالعه دستور PRINT |
| RAISERROR | خطا یا پیام سفارشی را با شدت، State و قالببندی کنترلشده ایجاد میکند و در سامانههای قدیمی هنوز بسیار دیده میشود. | بسته به شدت، پیام اطلاعرسانی یا خطا ایجاد میکند. برخلاف THROW همیشه از رفتار SET XACT_ABORT پیروی نمیکند. | مطالعه دستور RAISERROR |
| THROW | روش مدرن SQL Server برای ایجاد خطای سفارشی یا پرتاب دوباره خطای جاری در TRY/CATCH است و با XACT_ABORT هماهنگی بهتری دارد. | یک Exception با شدت ۱۶ یا مشخصات خطای اصلی ایجاد میکند و جریان اجرای Batch را به CATCH یا فراخواننده منتقل میکند. | مطالعه دستور THROW |
| WAITFOR | اجرای Batch، Procedure یا تراکنش را تا زمان مشخص یا به اندازه یک تأخیر معین متوقف میکند و در Service Broker نیز برای انتظار پیام به کار میرود. | خروجی مستقیمی ندارد؛ اجرای نشست را متوقف میکند یا نتیجه RECEIVE را پس از دریافت/Timeout برمیگرداند. | مطالعه دستور WAITFOR |
| SET | خانوادهای از دستورات پیکربندی نشست و انتساب مقدار است که رفتار Query، تراکنش، زبان، تاریخ، قفل و پیامهای اجرایی را کنترل میکند. | بیشتر SETها Result Set ندارند و فقط وضعیت Session یا متغیر را تغییر میدهند؛ برخی اثرشان در زمان Parse و برخی در زمان Execute اعمال میشود. | مطالعه دستور SET |
| USE | Context پایگاه داده نشست را تغییر میدهد تا نامهای دوبخشی و اشیای بدون نام Database در پایگاه هدف تفسیر شوند. | Result Set ندارد و Context پایگاه داده را برای دستورات بعدی همان اتصال تغییر میدهد. | مطالعه دستور USE |
| DECLARE | متغیر محلی، Cursor یا Table Variable را در محدوده Batch تعریف میکند و پایه نگهداری حالت موقت در T-SQL است. | DECLARE خروجی مستقیمی ندارد؛ متغیر ایجادشده تا پایان Batch یا Scope معتبر است. | مطالعه دستور DECLARE |
| SET IDENTITY_INSERT | اجازه میدهد مقدار ستون Identity بهصورت صریح درج شود و برای مهاجرت، بازیابی شناسههای تاریخی و Seed داده کنترلشده کاربرد دارد. | خروجی مستقیمی ندارد و وضعیت Session را تغییر میدهد؛ در هر Session فقط یک جدول میتواند IDENTITY_INSERT روشن داشته باشد. | مطالعه دستور SET IDENTITY_INSERT |
| DBCC | مجموعه فرمانهای Database Console Commands برای بررسی سازگاری، نگهداری، عیبیابی و مشاهده وضعیت داخلی SQL Server است. | بسته به فرمان، پیام تشخیصی، Result Set یا تغییر مدیریتی ایجاد میشود؛ DBCC یک Return Type واحد ندارد. | مطالعه دستورات DBCC |
| CHECKPOINT | صفحات Dirty پایگاه جاری را به دیسک هدایت و نقطه بازیابی ایجاد میکند تا زمان Recovery پس از Crash کنترل شود. | Result Set ندارد و عملیات Checkpoint را برای Database جاری درخواست میکند؛ پایان دقیق به بار IO و موتور ذخیرهسازی وابسته است. | مطالعه دستور CHECKPOINT |
| BACKUP | نسخه پشتیبان کامل، تفاضلی یا Transaction Log را روی رسانه مشخص ایجاد میکند و ستون اصلی راهبرد بازیابی SQL Server است. | پیام پیشرفت و تکمیل Backup ایجاد میکند و Backup Set در رسانه و تاریخچه msdb ثبت میشود. | مطالعه دستور BACKUP |
| RESTORE | Backup Set را بازخوانی میکند تا Database، Log، File یا Page بازیابی شود و امکان Point-in-time Recovery و Disaster Recovery را فراهم میسازد. | پیام پیشرفت، نتیجه Metadata یا Database بازیابیشده برمیگرداند؛ خروجی دقیق به نوع RESTORE وابسته است. | مطالعه دستور RESTORE |
| KILL | یک Session کاربری را متوقف میکند یا وضعیت Rollback آن را گزارش میدهد و ابزار آخر برای رفع Block جدی یا نشست مخرب است. | پیام خاتمه نشست یا گزارش پیشرفت Rollback ایجاد میکند؛ Query جاری و تراکنش باز ممکن است وارد Rollback طولانی شوند. | مطالعه دستور KILL |
| Summary | نقشه راهی برای انتخاب، ترکیب و ایمنسازی PRINT، مدیریت خطا، WAITFOR، SET، USE، DECLARE، دستورات نگهداری و عملیات Backup/Restore است. | خروجی این موضوع به ترکیب دستورات وابسته است؛ هدف، Batch قابل تکرار، قابل مشاهده و ایمن برای اجراست. | مطالعه جمعبندی دستورات کاربردی |
دستهبندی مفهومی
پیامرسانی و مدیریت خطا
PRINT برای پیام تشخیصی ساده مناسب است، RAISERROR امکانات قدیمی شدت، قالببندی و NOWAIT را نگه میدارد و THROW مسیر مدرن ایجاد یا پرتاب دوباره Exception است.
در کد جدید، قرارداد خطا باید Error Number، State، پیام قابل فهم و رفتار تراکنش را مشخص کند. پیام تشخیصی نباید جای Exception یا لاگ پایدار را بگیرد.
کنترل زمان و رفتار Session
WAITFOR اجرای نشست را متوقف میکند و SET گزینههایی مانند NOCOUNT، XACT_ABORT، زبان، DATEFIRST، Timeout و سطح جداسازی را تنظیم میکند.
Connection Pool میتواند تنظیم Session را به درخواست بعدی منتقل کند؛ بنابراین Procedure و لایه دسترسی داده باید گزینههای حساس را آگاهانه تنظیم یا بازنشانی کنند.
Context و متغیرهای محلی
USE پایگاه داده جاری را تعیین میکند و DECLARE متغیر، Table Variable یا Cursor را در Scope محلی میسازد. این دو فرمان پایه اسکریپتهای قابل فهم و پارامتری هستند.
Guard با DB_NAME و انتخاب نوع داده سازگار با ستون، از دو کلاس مهم خطا یعنی مقصد اشتباه و تبدیل ضمنی جلوگیری میکند.
مهاجرت شناسه و نگهداری سلامت
SET IDENTITY_INSERT برای حفظ کلید تاریخی و DBCC برای کنترل سازگاری، Seed، Log و تشخیص داخلی استفاده میشود.
این ابزارها باید با مجوز محدود، خروجی کنترلی و برنامه بازگشت اجرا شوند. گزینه Repair یا پاکسازی Cache بدون تحلیل و Backup معتبر انتخاب عادی نیست.
Checkpoint و زنجیره بازیابی
CHECKPOINT نقطه بازیابی داخلی ایجاد میکند، BACKUP نسخه قابل نگهداری میسازد و RESTORE توان بازگرداندن سرویس را اثبات میکند.
Checkpoint جای Backup نیست و VERIFYONLY جای مانور Restore را نمیگیرد. RPO و RTO فقط با زنجیره Backup مناسب و آزمون بازیابی واقعی قابل دفاع هستند.
کنترل اضطراری Session
KILL برای خاتمه Session یا مشاهده Rollback است و باید آخرین اقدام پس از ثبت شواهد Blocking، Query، Transaction و مالک سرویس باشد.
رفع فوری Block بدون تحلیل علت، رخداد را تکرارپذیر میکند. پس از حادثه باید Query، Index، Timeout و مرز تراکنش اصلاح شوند.
تعامل با تاریخ، زمان محلی، UTC و Offset
گرچه موضوع این مجموعه توابع تاریخ نیست، چند دستور آن مستقیماً با زمان اجرا تعامل دارند. WAITFOR از مقدار time برای تأخیر یا زمان هدف استفاده میکند و اسکریپتهای Backup، Restore و نگهداری باید Timestamp دقیق و مستقل از تنظیم زبان ثبت کنند. datetime2 برای زمان محلی با دقت مناسب و datetimeoffset برای نگهداری Offset گزینههای مهمی هستند.
GETDATE زمان محلی Instance، SYSUTCDATETIME زمان UTC با دقت بالاتر و SYSDATETIMEOFFSET زمان همراه Offset را ارائه میکند. در سامانه چندمنطقهای، رخداد عملیاتی را با UTC ثبت و منطقه زمانی کاربر را در لایه نمایش اعمال کنید. تبدیل رشته تاریخ نیز بهتر است با ISO 8601 انجام شود تا LANGUAGE و DATEFORMAT نتیجه را تغییر ندهند.
نوع date فقط روز، time فقط ساعت، datetime2 تاریخ و زمان با دقت قابل انتخاب و datetimeoffset تاریخ و زمان همراه اختلاف UTC را نگه میدارد. انتخاب نوع بیش از حد دقیق حجم Index را افزایش میدهد و انتخاب نوع کمدقت میتواند ترتیب رخدادها را مبهم کند؛ بنابراین دقت باید از نیاز تجاری بیاید.
برای زمانبندی Job از SQL Server Agent یا سرویس زمانبندی استفاده کنید و WAITFOR را جایگزین Scheduler نکنید. تأخیر داخل تراکنش Worker و قفل را نگه میدارد. در گزارش عملیاتی نیز زمان شروع، پایان، Duration و منطقه زمانی بهصورت جداگانه ذخیره شوند.
دستور PRINT در SQL Server
نمایش پیام متنی و اطلاعات تشخیصی در پنجره Messages کلاینت SQL است و برای ردگیری اجرای اسکریپتهای مدیریتی و استقرار کاربرد دارد. خروجی و اثر مهم آن چنین است: Result Set برنمیگرداند و پیام را در کانال Messages ارسال میکند. طول پیام برای varchar حدود ۸۰۰۰ و برای nvarchar حدود ۴۰۰۰ کاراکتر محدود است.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور PRINT را بخوانید.
دستور RAISERROR در SQL Server
خطا یا پیام سفارشی را با شدت، State و قالببندی کنترلشده ایجاد میکند و در سامانههای قدیمی هنوز بسیار دیده میشود. خروجی و اثر مهم آن چنین است: بسته به شدت، پیام اطلاعرسانی یا خطا ایجاد میکند. برخلاف THROW همیشه از رفتار SET XACT_ABORT پیروی نمیکند.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور RAISERROR را بخوانید.
دستور THROW در SQL Server
روش مدرن SQL Server برای ایجاد خطای سفارشی یا پرتاب دوباره خطای جاری در TRY/CATCH است و با XACT_ABORT هماهنگی بهتری دارد. خروجی و اثر مهم آن چنین است: یک Exception با شدت ۱۶ یا مشخصات خطای اصلی ایجاد میکند و جریان اجرای Batch را به CATCH یا فراخواننده منتقل میکند.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور THROW را بخوانید.
دستور WAITFOR در SQL Server
اجرای Batch، Procedure یا تراکنش را تا زمان مشخص یا به اندازه یک تأخیر معین متوقف میکند و در Service Broker نیز برای انتظار پیام به کار میرود. خروجی و اثر مهم آن چنین است: خروجی مستقیمی ندارد؛ اجرای نشست را متوقف میکند یا نتیجه RECEIVE را پس از دریافت/Timeout برمیگرداند.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور WAITFOR را بخوانید.
دستور SET در SQL Server
خانوادهای از دستورات پیکربندی نشست و انتساب مقدار است که رفتار Query، تراکنش، زبان، تاریخ، قفل و پیامهای اجرایی را کنترل میکند. خروجی و اثر مهم آن چنین است: بیشتر SETها Result Set ندارند و فقط وضعیت Session یا متغیر را تغییر میدهند؛ برخی اثرشان در زمان Parse و برخی در زمان Execute اعمال میشود.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور SET را بخوانید.
دستور USE در SQL Server
Context پایگاه داده نشست را تغییر میدهد تا نامهای دوبخشی و اشیای بدون نام Database در پایگاه هدف تفسیر شوند. خروجی و اثر مهم آن چنین است: Result Set ندارد و Context پایگاه داده را برای دستورات بعدی همان اتصال تغییر میدهد.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور USE را بخوانید.
دستور DECLARE در SQL Server
متغیر محلی، Cursor یا Table Variable را در محدوده Batch تعریف میکند و پایه نگهداری حالت موقت در T-SQL است. خروجی و اثر مهم آن چنین است: DECLARE خروجی مستقیمی ندارد؛ متغیر ایجادشده تا پایان Batch یا Scope معتبر است.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور DECLARE را بخوانید.
دستور SET IDENTITY_INSERT در SQL Server
اجازه میدهد مقدار ستون Identity بهصورت صریح درج شود و برای مهاجرت، بازیابی شناسههای تاریخی و Seed داده کنترلشده کاربرد دارد. خروجی و اثر مهم آن چنین است: خروجی مستقیمی ندارد و وضعیت Session را تغییر میدهد؛ در هر Session فقط یک جدول میتواند IDENTITY_INSERT روشن داشته باشد.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور SET IDENTITY_INSERT را بخوانید.
دستورات DBCC در SQL Server
مجموعه فرمانهای Database Console Commands برای بررسی سازگاری، نگهداری، عیبیابی و مشاهده وضعیت داخلی SQL Server است. خروجی و اثر مهم آن چنین است: بسته به فرمان، پیام تشخیصی، Result Set یا تغییر مدیریتی ایجاد میشود؛ DBCC یک Return Type واحد ندارد.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستورات DBCC را بخوانید.
دستور CHECKPOINT در SQL Server
صفحات Dirty پایگاه جاری را به دیسک هدایت و نقطه بازیابی ایجاد میکند تا زمان Recovery پس از Crash کنترل شود. خروجی و اثر مهم آن چنین است: Result Set ندارد و عملیات Checkpoint را برای Database جاری درخواست میکند؛ پایان دقیق به بار IO و موتور ذخیرهسازی وابسته است.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور CHECKPOINT را بخوانید.
دستور BACKUP در SQL Server
نسخه پشتیبان کامل، تفاضلی یا Transaction Log را روی رسانه مشخص ایجاد میکند و ستون اصلی راهبرد بازیابی SQL Server است. خروجی و اثر مهم آن چنین است: پیام پیشرفت و تکمیل Backup ایجاد میکند و Backup Set در رسانه و تاریخچه msdb ثبت میشود.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور BACKUP را بخوانید.
دستور RESTORE در SQL Server
Backup Set را بازخوانی میکند تا Database، Log، File یا Page بازیابی شود و امکان Point-in-time Recovery و Disaster Recovery را فراهم میسازد. خروجی و اثر مهم آن چنین است: پیام پیشرفت، نتیجه Metadata یا Database بازیابیشده برمیگرداند؛ خروجی دقیق به نوع RESTORE وابسته است.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور RESTORE را بخوانید.
دستور KILL در SQL Server
یک Session کاربری را متوقف میکند یا وضعیت Rollback آن را گزارش میدهد و ابزار آخر برای رفع Block جدی یا نشست مخرب است. خروجی و اثر مهم آن چنین است: پیام خاتمه نشست یا گزارش پیشرفت Rollback ایجاد میکند؛ Query جاری و تراکنش باز ممکن است وارد Rollback طولانی شوند.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی دستور KILL را بخوانید.
جمعبندی دستورات کاربردی در SQL Server
نقشه راهی برای انتخاب، ترکیب و ایمنسازی PRINT، مدیریت خطا، WAITFOR، SET، USE، DECLARE، دستورات نگهداری و عملیات Backup/Restore است. خروجی و اثر مهم آن چنین است: خروجی این موضوع به ترکیب دستورات وابسته است؛ هدف، Batch قابل تکرار، قابل مشاهده و ایمن برای اجراست.
برای Syntax، پارامترها، ده مثال اجرایی، خطاهای رایج و نکات کارایی، مقاله تخصصی جمعبندی دستورات کاربردی را بخوانید.
مثالهای ترکیبی و کاربردی
شش نمونه زیر نشان میدهند چند دستور چگونه در یک جریان واقعی کنار هم قرار میگیرند. هر Batch باید ابتدا در محیط آزمایش اجرا شود و نام Database، مسیر Backup و سطح مجوز آن با مقصد واقعی هماهنگ گردد.
مثال شماره 1: اسکریپت قابل مشاهده با PRINT و SET
در این سناریو هدف آن است که «اسکریپت قابل مشاهده با PRINT و SET» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
SET NOCOUNT ON;
DECLARE @StartedAt datetime2(0) = SYSDATETIME();
PRINT N'شروع گزارش';
SELECT COUNT(*) AS DatabaseCount FROM sys.databases;
PRINT N'پایان در ' + CONVERT(nvarchar(19), SYSDATETIME(), 126);
| خروجی نمونه | تفسیر نتیجه |
|---|
| تعداد Databaseها و دو پیام اجرایی | نتیجه مورد انتظار نشان میدهد سناریوی اسکریپت قابل مشاهده با PRINT و SET با موفقیت طی شده است. |
این الگو برای Job و Deployment ساده، مشاهدهپذیری اولیه ایجاد میکند. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 2: تراکنش امن با THROW
در این سناریو هدف آن است که «تراکنش امن با THROW» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
SET XACT_ABORT ON;
BEGIN TRY
BEGIN TRANSACTION;
IF DB_NAME() IS NULL THROW 51200, N'Context معتبر نیست.', 1;
SELECT DB_NAME() AS CurrentDatabase;
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
THROW;
END CATCH;
| خروجی نمونه | تفسیر نتیجه |
|---|
| نام Database و تراکنش بسته | نتیجه مورد انتظار نشان میدهد سناریوی تراکنش امن با THROW با موفقیت طی شده است. |
ساختار TRY/CATCH و XACT_STATE از تراکنش معلق جلوگیری میکند. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 3: مهاجرت داده مرجع با Identity
در این سناریو هدف آن است که «مهاجرت داده مرجع با Identity» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
DROP TABLE IF EXISTS #ReferenceData;
CREATE TABLE #ReferenceData(Id int IDENTITY PRIMARY KEY, Title nvarchar(30));
SET IDENTITY_INSERT #ReferenceData ON;
INSERT #ReferenceData(Id, Title) VALUES (10, N'فعال'), (20, N'غیرفعال');
SET IDENTITY_INSERT #ReferenceData OFF;
SELECT * FROM #ReferenceData ORDER BY Id;
| خروجی نمونه | تفسیر نتیجه |
|---|
| دو ردیف با شناسههای 10 و 20 | نتیجه مورد انتظار نشان میدهد سناریوی مهاجرت داده مرجع با Identity با موفقیت طی شده است. |
فهرست ستونها و خاموشکردن گزینه، اجرای مهاجرت را قابل کنترل میکند. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 4: پایش سلامت و Log
در این سناریو هدف آن است که «پایش سلامت و Log» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
DBCC CHECKDB(N'master') WITH NO_INFOMSGS;
DBCC SQLPERF(LOGSPACE);
| خروجی نمونه | تفسیر نتیجه |
|---|
| گزارش سلامت و درصد مصرف Log | نتیجه مورد انتظار نشان میدهد سناریوی پایش سلامت و Log با موفقیت طی شده است. |
این بررسی باید در زمانبندی مشخص اجرا و نتیجه آن نگهداری شود. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 5: بازبینی زنجیره Backup و Restore
در این سناریو هدف آن است که «بازبینی زنجیره Backup و Restore» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
RESTORE HEADERONLY FROM DISK = N'C:\SQLBackups\YourDatabase_Full.bak';
RESTORE FILELISTONLY FROM DISK = N'C:\SQLBackups\YourDatabase_Full.bak';
RESTORE VERIFYONLY FROM DISK = N'C:\SQLBackups\YourDatabase_Full.bak' WITH CHECKSUM;
| خروجی نمونه | تفسیر نتیجه |
|---|
| Header، فهرست فایل و نتیجه Verify | نتیجه مورد انتظار نشان میدهد سناریوی بازبینی زنجیره Backup و Restore با موفقیت طی شده است. |
اطلاعات حاصل، ورودی طراحی Restore با MOVE و مانور بازیابی است. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
مثال شماره 6: بررسی Blocking پیش از تصمیم KILL
در این سناریو هدف آن است که «بررسی Blocking پیش از تصمیم KILL» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه میدهد و میتوان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.
SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time, t.text
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.blocking_session_id > 0;
| خروجی نمونه | تفسیر نتیجه |
|---|
| نشستهای مسدود و متن فرمان | نتیجه مورد انتظار نشان میدهد سناریوی بررسی Blocking پیش از تصمیم KILL با موفقیت طی شده است. |
قبل از اقدام اضطراری، زنجیره Blocking، مالک نشست و هزینه Rollback ثبت میشود. در محیط عملیاتی بهتر است ورودی، زمان اجرا، نام پایگاه داده و نتیجه نهایی نیز در یک لاگ ساختاریافته ثبت شود تا عیبیابی و ممیزی بعدی قابل اتکا باشد.
معماری اسکریپت عملیاتی امن
اسکریپت حرفهای با تعیین Database و تنظیمات Session شروع میشود، پیششرطهایی مانند وجود کاربر، جدول، فضای دیسک و Backup معتبر را کنترل میکند و سپس Transaction را در کوچکترین محدوده لازم باز میکند. تغییر اصلی داخل TRY انجام میشود و CATCH وظیفه Rollback، پاکسازی تنظیم موقت و پرتاب دوباره خطا را دارد.
قابلیت اجرای مجدد باید از ابتدا طراحی شود. IF EXISTS و IF NOT EXISTS، کلید طبیعی، ثبت نسخه Migration و Query کنترل نهایی ابزارهای مهم هستند. اجرای دوباره نباید داده تکراری بسازد یا تنظیم Session را روشن باقی بگذارد.
برای فرمانهایی که Transactional نیستند یا روی کل Instance اثر دارند، جایگزین Rollback باید Runbook بازگشت باشد. Backup معتبر، مانور Restore، ثبت تنظیم قبل از تغییر و تأیید مالک سرویس، اجزای این Runbook هستند.
امنیت نیز بخشی از کیفیت SQL است. حساب اجرای Backup، Restore، DBCC یا KILL نباید مجوز بیش از نیاز داشته باشد. فرمان Dynamic SQL برای Identifier تنها بعد از White-list و QUOTENAME ساخته میشود و داده همیشه از پارامتر عبور میکند.
سؤالات متداول
سؤال 1: دستورات کاربردی SQL Server چه گروههایی دارند؟
این مجموعه شامل پیام و خطا، کنترل اجرای Session، تعریف متغیر و Context، نگهداری سلامت، مدیریت Checkpoint، Backup و Restore و کنترل اضطراری Session است. گروهبندی بر اساس Scope و اثر عملیاتی، انتخاب فرمان را ساده میکند.
سؤال 2: برای یادگیری این مجموعه از کجا شروع کنیم؟
از PRINT، DECLARE، SET و USE آغاز کنید؛ سپس TRY/CATCH، RAISERROR و THROW را بیاموزید. فرمانهای DBCC، CHECKPOINT، BACKUP، RESTORE و KILL باید در آزمایشگاه و همراه درک Recovery و مجوز تمرین شوند.
سؤال 3: کدام دستورات برای توسعهدهنده روزمره مهمترند؟
DECLARE، SET، THROW و گاهی PRINT بیشترین حضور را در کد کاربردی دارند. USE در اسکریپت استقرار مهم است و بقیه بیشتر در حوزه DBA و عملیات قرار میگیرند، هرچند توسعهدهنده باید اثر آنها را بشناسد.
سؤال 4: چگونه اجرای اشتباه روی Production را کم کنیم؟
Guard با DB_NAME و SERVERPROPERTY، اصل کمترین مجوز، پارامتر تأیید، Transaction کوتاه، خروجی Preview و بازبینی دو نفره برای فرمان حساس مؤثرند. فایل اجرا باید نسخهبندی و نتیجه آن ثبت شود.
سؤال 5: THROW بهتر است یا RAISERROR؟
برای توسعه جدید معمولاً THROW به دلیل حفظ بهتر خطای اصلی و هماهنگی با XACT_ABORT انتخاب مناسبتری است. RAISERROR برای NOWAIT، قالببندی قدیمی یا سازگاری سامانه موجود همچنان کاربرد دارد.
سؤال 6: آیا میتوان این اسکریپتها را به تیم مشاوره سپرد؟
برای مهاجرت، Disaster Recovery، Performance Tuning یا Runbook Production، بازبینی متخصص میتواند ریسک و زمان توقف را کاهش دهد. خروجی مطلوب شامل اسکریپت، Rollback، تست، معیار پذیرش و مستند اجرای واقعی است.
سؤال 7: رایجترین خطای مشترک این دستورات چیست؟
اشتباه در Context، مجوز یا Scope است. کاربر فرمان درست را روی Database یا Session اشتباه اجرا میکند. نمایش مقصد، Guard و توقف صریح پیش از تغییر، مهمترین کنترل پیشگیرانه است.
سؤال 8: چگونه Performance عملیات مدیریتی سنجیده میشود؟
Duration، CPU، IO، Log، Blocking، Wait و اثر بر SLA پیش و پس از اجرا اندازهگیری میشوند. Baseline باید از بازه مشابه و بار نماینده گرفته شود و نتیجه تنها به یک Snapshot محدود نباشد.
سؤال 9: بهترین روش مشترک برای همه فرمانها چیست؟
هدف، Scope، ورودی، مجوز، Timeout، مسیر خطا و معیار موفقیت را پیشاپیش مشخص کنید. نمونه را در محیط غیرتولیدی اجرا، تغییر را نسخهبندی و نتیجه نهایی را با Query کنترلی ثبت کنید.
سؤال 10: سازگاری این دستورات با نسخهها چگونه است؟
هسته بسیاری از فرمانها قدیمی و پایدار است، اما گزینهها، مجوزها و رفتار Cloud تغییر میکند. نسخه موتور، Compatibility Level، Edition و سرویس مقصد باید جداگانه با مستندات همان نسخه بررسی شود.
سؤالات مصاحبه
پرسش مصاحبه 1: تفاوت Scope در SET، USE و DECLARE چیست؟
بسته به گزینه، SET روی Session یا عبارت اثر میگذارد، USE Context Database اتصال را تغییر میدهد و DECLARE متغیر را تا پایان Batch یا Scope معتبر نگه میدارد. پاسخ دقیق باید استثناهای گزینه خاص را نیز در نظر بگیرد.
پرسش مصاحبه 2: چرا THROW برای کد جدید ترجیح داده میشود؟
Syntax روشن، حفظ جزئیات خطای اصلی در rethrow و رفتار هماهنگتر با XACT_ABORT دلایل اصلیاند. RAISERROR برای NOWAIT و سازگاری کد موجود همچنان جایگاه دارد.
پرسش مصاحبه 3: Checkpoint چه تفاوتی با Backup دارد؟
Checkpoint صفحات Dirty را برای Recovery داخلی مدیریت میکند، اما نسخه مستقل و قابل انتقال نمیسازد. Backup رسانه بازیابی ایجاد میکند و فقط Restore آزمایشی قابلیت استفاده آن را ثابت میکند.
پرسش مصاحبه 4: پیش از KILL چه شواهدی جمع میکنید؟
Session، Login، Host، Program، Query Text، Plan، Blocking Chain، Wait، عمر Transaction و برآورد Rollback ثبت میشوند. سپس مالک سرویس و اثر کسبوکار در تصمیم دخالت دارند.
پرسش مصاحبه 5: یک Deployment قابل اعتماد چه ویژگیهایی دارد؟
مقصد صریح، Guard، گزینه Session، Transaction کوتاه، TRY/CATCH، اسکریپت برگشت، اجرای مجدد کنترلشده، لاگ و Query پذیرش از ویژگیهای اصلی هستند.
جمعبندی و مسیر مطالعه
این مجموعه از پیام ساده تا بازیابی کامل را پوشش میدهد و یک اصل مشترک دارد: دستور درست بدون Context، مجوز، کنترل خطا و معیار پذیرش هنوز یک عملیات قابل اعتماد نیست. یادگیری را از فرمانهای Session و خطا آغاز کنید و سپس با آزمایشگاه Backup/Restore و سناریوهای Blocking به سطح عملیاتی برسید.
برای ادامه، مقالههای تخصصی زیر را بهترتیب نیاز پروژه باز کنید. هر صفحه ده مثال مستقل، خروجی نمونه، نکات Performance، Best Practice، FAQ و سؤالات مصاحبه دارد.