آموزش جامع جمع‌بندی دستورات کاربردی در SQL Server

مقدمه و مسیر یادگیری

جمع‌بندی دستورات کاربردی یکی از موضوع‌های مهم مجموعه دستورات کاربردی Microsoft SQL Server است. نقشه راهی برای انتخاب، ترکیب و ایمن‌سازی PRINT، مدیریت خطا، WAITFOR، SET، USE، DECLARE، دستورات نگهداری و عملیات Backup/Restore است. شناخت این دستور زمانی ارزشمند می‌شود که علاوه بر شکل نوشتن، محدوده اثر، نیازمندی مجوز، رفتار در تراکنش و پیامد عملیاتی آن نیز روشن باشد.

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

پیش از اجرای نمونه‌های مدیریتی روی سرور واقعی، نام Database، مسیر فایل، شناسه Session و سطح دسترسی را با محیط خود تطبیق دهید. نمونه‌ای که شامل Backup، Restore، DBCC یا KILL باشد باید ابتدا در آزمایشگاه و با برنامه بازگشت بررسی شود.

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

تعریف جمع‌بندی دستورات کاربردی

نقشه راهی برای انتخاب، ترکیب و ایمن‌سازی PRINT، مدیریت خطا، WAITFOR، SET، USE، DECLARE، دستورات نگهداری و عملیات Backup/Restore است.

در SQL Server هر فرمان در یک Scope مشخص اجرا می‌شود. هنگام استفاده از Summary باید مشخص باشد اثر آن فقط روی عبارت فعلی، Batch، Session، Database یا کل Instance است. همین تشخیص، پایه جلوگیری از اجرای ناخواسته و طراحی درست آزمون است.

از دید مهندسی، Syntax صحیح شرط لازم است اما کافی نیست. داده ورودی، Collation، نوع داده، تنظیمات SET، سطح جداسازی، مجوز و وضعیت Connection می‌توانند نتیجه را تغییر دهند. بنابراین مثال حرفه‌ای باید پیش‌شرط و خروجی کنترلی داشته باشد.

Syntax استاندارد

-- الگوی عمومی
USE [TargetDatabase];
SET NOCOUNT ON;
SET XACT_ABORT ON;
BEGIN TRY
    BEGIN TRANSACTION;
    -- عملیات
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
    THROW;
END CATCH;

پارامترها و اجزای مهم

Context مقصد و Guard مربوط به DB_NAME
گزینه‌های نشست استاندارد
مرز تراکنش کوتاه و روشن
پیام و ثبت خطا
کنترل دسترسی عملیات مدیریتی

خروجی و اثر اجرایی

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

اگر این دستور در Procedure، Job یا ابزار استقرار استفاده شود، Caller باید بداند موفقیت چگونه اعلام می‌شود و خطا از چه مسیری برمی‌گردد. استفاده از Result Set کنترلی، پیام کوتاه، Error Number مشخص یا رکورد لاگ باید بر اساس قرارداد پروژه انتخاب شود.

کاربردهای واقعی در پروژه

سه کاربرد پرتکرار این موضوع عبارت‌اند از ساخت Runbook عملیاتی، استانداردسازی Deployment، مرور آموزشی و آمادگی مصاحبه SQL Server. در هر سه حالت، مالک عملیات و معیار پذیرش باید قبل از اجرا تعیین شود و تغییر مهم بدون نسخه پشتیبان یا مسیر Rollback انجام نشود.

در پروژه سازمانی بهتر است فرمان داخل یک Runbook یا اسکریپت نسخه‌بندی‌شده قرار گیرد. نام سرور و Database از محیط دریافت شود، ولی Identifier پویا فقط پس از اعتبارسنجی و QUOTENAME ساخته شود. مقادیر داده نیز در Dynamic SQL به‌صورت پارامتر ارسال شوند.

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

مثال‌های عملی مستقل

ده مثال زیر جنبه‌های متفاوت Summary را پوشش می‌دهند. هر نمونه هدف، Query، خروجی مورد انتظار و نکته عملیاتی دارد. فرمان‌های دارای اثر مدیریتی با نام‌ها و مسیرهای نمونه نوشته شده‌اند و باید پیش از اجرا شخصی‌سازی و تأیید شوند.

مثال شماره 1: پیش‌درآمد استاندارد Deployment

در این سناریو هدف آن است که «پیش‌درآمد استاندارد Deployment» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

USE [tempdb];
SET NOCOUNT ON;
SET XACT_ABORT ON;
IF DB_NAME() <> N'tempdb' THROW 51100, N'مقصد اشتباه است.', 1;
PRINT N'محیط تأیید شد';

خروجی نمونه	تفسیر نتیجه
پیام تأیید محیط	نتیجه مورد انتظار نشان می‌دهد سناریوی پیش‌درآمد استاندارد Deployment با موفقیت طی شده است.

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

مثال شماره 2: الگوی تراکنش و THROW

در این سناریو هدف آن است که «الگوی تراکنش و THROW» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

SET XACT_ABORT ON;
BEGIN TRY
    BEGIN TRANSACTION;
    SELECT N'عملیات نمونه' AS StepName;
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
    THROW;
END CATCH;

خروجی نمونه	تفسیر نتیجه
عملیات نمونه و تراکنش بسته	نتیجه مورد انتظار نشان می‌دهد سناریوی الگوی تراکنش و THROW با موفقیت طی شده است.

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

مثال شماره 3: مهاجرت شناسه با Cleanup

در این سناریو هدف آن است که «مهاجرت شناسه با Cleanup» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

DROP TABLE IF EXISTS #Seed;
CREATE TABLE #Seed(Id int IDENTITY PRIMARY KEY, Title nvarchar(30));
BEGIN TRY
    SET IDENTITY_INSERT #Seed ON;
    INSERT #Seed(Id, Title) VALUES (100, N'داده مرجع');
    SET IDENTITY_INSERT #Seed OFF;
END TRY
BEGIN CATCH
    SET IDENTITY_INSERT #Seed OFF;
    THROW;
END CATCH;
SELECT * FROM #Seed;

خروجی نمونه	تفسیر نتیجه
رکورد مرجع با Id برابر 100	نتیجه مورد انتظار نشان می‌دهد سناریوی مهاجرت شناسه با Cleanup با موفقیت طی شده است.

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

مثال شماره 4: بازبینی 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;

خروجی نمونه	تفسیر نتیجه
Metadata فایل‌ها و نتیجه Verify	نتیجه مورد انتظار نشان می‌دهد سناریوی بازبینی Backup پیش از Restore با موفقیت طی شده است.

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

مثال شماره 5: تشخیص Blocking پیش از KILL

در این سناریو هدف آن است که «تشخیص Blocking پیش از KILL» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

SELECT r.session_id, r.blocking_session_id, r.wait_type, 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;

خروجی نمونه	تفسیر نتیجه
درخواست‌های مسدود و متن Query	نتیجه مورد انتظار نشان می‌دهد سناریوی تشخیص Blocking پیش از KILL با موفقیت طی شده است.

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

مثال شماره 6: کنترل سلامت و Log

در این سناریو هدف آن است که «کنترل سلامت و Log» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

DBCC CHECKDB(N'master') WITH NO_INFOMSGS;
DBCC SQLPERF(LOGSPACE);

خروجی نمونه	تفسیر نتیجه
نتیجه سلامت master و درصد مصرف Logها	نتیجه مورد انتظار نشان می‌دهد سناریوی کنترل سلامت و Log با موفقیت طی شده است.

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

مثال شماره 7: Checkpoint و پایش IO

در این سناریو هدف آن است که «Checkpoint و پایش IO» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

USE [tempdb];
CHECKPOINT;
SELECT mf.name, vfs.num_of_writes, vfs.io_stall_write_ms
FROM sys.dm_io_virtual_file_stats(DB_ID(), NULL) AS vfs
JOIN sys.database_files AS mf ON mf.file_id = vfs.file_id;

خروجی نمونه	تفسیر نتیجه
آمار تجمعی نوشتن فایل‌های tempdb	نتیجه مورد انتظار نشان می‌دهد سناریوی Checkpoint و پایش IO با موفقیت طی شده است.

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

مثال شماره 8: WAITFOR محدود در Polling

در این سناریو هدف آن است که «WAITFOR محدود در Polling» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

DECLARE @Attempt int = 0, @MaxAttempt int = 2;
WHILE @Attempt < @MaxAttempt
BEGIN
    SET @Attempt += 1;
    PRINT N'بررسی شماره ' + CONVERT(nvarchar(10), @Attempt);
    IF @Attempt < @MaxAttempt WAITFOR DELAY '00:00:01';
END;

خروجی نمونه	تفسیر نتیجه
دو پیام با فاصله کنترل‌شده	نتیجه مورد انتظار نشان می‌دهد سناریوی WAITFOR محدود در Polling با موفقیت طی شده است.

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

مثال شماره 9: Dynamic SQL پارامتری

در این سناریو هدف آن است که «Dynamic SQL پارامتری» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

DECLARE @Sql nvarchar(max) = N'SELECT name FROM sys.databases WHERE database_id = @Id;';
DECLARE @Id int = 1;
EXEC sys.sp_executesql @Sql, N'@Id int', @Id = @Id;

خروجی نمونه	تفسیر نتیجه
نام Database با شناسه 1	نتیجه مورد انتظار نشان می‌دهد سناریوی Dynamic SQL پارامتری با موفقیت طی شده است.

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

مثال شماره 10: گزارش نهایی اجرای Batch

در این سناریو هدف آن است که «گزارش نهایی اجرای Batch» به شکلی روشن و قابل بازتولید بررسی شود. Query زیر یک Batch کامل ارائه می‌دهد و می‌توان آن را پس از کنترل Context و مجوزها در محیط آزمایش اجرا کرد.

DECLARE @StartedAt datetime2(0) = SYSDATETIME();
SET NOCOUNT ON;
SELECT COUNT(*) AS DatabaseCount FROM sys.databases;
PRINT N'مدت اجرا بر حسب ثانیه: ' + CONVERT(nvarchar(20), DATEDIFF(second, @StartedAt, SYSDATETIME()));

خروجی نمونه	تفسیر نتیجه
تعداد Databaseها و پیام مدت اجرا	نتیجه مورد انتظار نشان می‌دهد سناریوی گزارش نهایی اجرای Batch با موفقیت طی شده است.

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

خطاهای رایج و روش پیشگیری

ترکیب دستورهای مدیریتی بدون ترتیب روشن ریسک توقف سرویس دارد. این خطا معمولاً زمانی رخ می‌دهد که نمونه آموزشی بدون بررسی Context یا Scope به Production منتقل می‌شود. افزودن Guard، نمایش مقصد و توقف سریع با THROW راه پیشگیری قابل اتکایی است.

کپی نمونه بدون جایگزینی نام و مسیر می‌تواند مقصد اشتباه را تغییر دهد. برای کنترل این وضعیت، ورودی‌ها را پیش از اجرا اعتبارسنجی کنید و نتیجه مرحله حساس را با Query مستقل بسنجید. اگر عملیات قابل Rollback نیست، تأیید دوم و Backup معتبر ضروری است.

نبود آزمون Restore، راهبرد Backup را ناقص می‌کند. مستندسازی رفتار مورد انتظار و ثبت Error Number، Message، State و زمان اجرا باعث می‌شود تیم به جای آزمون و خطای تکراری، علت را بر اساس شواهد پیدا کند.

نام Database و Instance پیش از اجرا کنترل شود.
مجوز حساب اجرا با اصل کمترین دسترسی تعیین شود.
در مسیر CATCH وضعیت تراکنش و تنظیمات Session تعیین تکلیف شود.
Query کنترلی پس از عملیات، نتیجه واقعی را ثابت کند.

ملاحظات Performance و هم‌زمانی

عملیات را اندازه‌گیری و در بازه کم‌بار اجرا کنید. ارزیابی کارایی باید بر اساس Baseline و در بازه زمانی مشخص باشد؛ یک Execution Plan یا عدد تجمعی بدون مقایسه، برای تصمیم Production کافی نیست.

پیام‌های تشخیصی را محدود و قابل جست‌وجو نگه دارید. اگر فرمان روی IO، Transaction Log، Worker Thread یا قفل اثر دارد، Wait Type و Blocking هم‌زمان بررسی شود. افزایش سرعت یک Batch نباید با طولانی‌شدن توقف کاربران جبران شود.

سلامت، Duration و اثر IO را پیش و پس از اجرا ثبت کنید. برای اجرای دوره‌ای، Duration، نتیجه، تعداد ردیف، حجم داده و خطاها در جدول تاریخچه ثبت شود. این تاریخچه ظرفیت‌سنجی و تشخیص تغییر رفتار پس از ارتقای نسخه را ممکن می‌کند.

بهترین روش‌ها

هدف و Scope دستور Summary را در ابتدای اسکریپت توضیح دهید.
از نام Schema، نوع داده و تبدیل صریح استفاده کنید.
مقادیر فارسی را با N و نوع nvarchar نگه دارید.
برای خطای واقعی از TRY/CATCH و THROW استفاده کنید.
تراکنش را کوتاه نگه دارید و XACT_STATE را در CATCH کنترل کنید.
اسکریپت را تا حد ممکن قابل اجرای مجدد طراحی کنید.
خروجی کنترلی و معیار پذیرش را در همان فایل قرار دهید.
نسخه SQL Server و تفاوت محیط Cloud را پیش از استقرار بررسی کنید.

مقایسه Summary با اجرای دستی پراکنده بدون Guard، Transaction و ثبت نتیجه باید بر اساس نیاز واقعی انجام شود. انتخاب فناوری یا فرمان صرفاً به دلیل آشنایی قبلی، ممکن است خوانایی، سازگاری یا قابلیت پشتیبانی آینده را کاهش دهد.

سؤالات متداول

سؤال 1: جمع‌بندی دستورات کاربردی در SQL Server دقیقاً چه کاری انجام می‌دهد؟

جمع‌بندی دستورات کاربردی نقشه راهی برای انتخاب، ترکیب و ایمن‌سازی PRINT، مدیریت خطا، WAITFOR، SET، USE، DECLARE، دستورات نگهداری و عملیات Backup/Restore است. دامنه اثر آن باید پیش از اجرا شناخته شود و نمونه نخست در محیط آزمایش بررسی شود تا انتظار تیم از پیام، Result Set یا تغییر وضعیت Session دقیق باشد.

سؤال 2: برای شروع یادگیری Summary چه پیش‌نیازی لازم است؟

آشنایی با Batch، Session، نوع داده، مجوز و تفاوت محیط توسعه و تولید کافی است. ابتدا Syntax و مثال‌های پایه را اجرا کنید، سپس رفتار خطا و تراکنش را با داده کوچک بسنجید و در پایان سراغ سناریوی سازمانی بروید.

سؤال 3: Summary چه ارزش تجاری برای یک سامانه داده دارد؟

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

سؤال 4: آیا استفاده حرفه‌ای از Summary هزینه پروژه SQL Server را کم می‌کند؟

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

سؤال 5: تفاوت Summary با اجرای دستی پراکنده بدون Guard، Transaction و ثبت نتیجه چیست؟

Summary برای نقشه راهی برای انتخاب، ترکیب و ایمن‌سازی PRINT، مدیریت خطا، WAITFOR، SET، USE، DECLARE، دستورات نگهداری و عملیات Backup/Restore است. گزینه تخصصی‌تری است، درحالی‌که اجرای دستی پراکنده بدون Guard، Transaction و ثبت نتیجه دامنه یا هدف متفاوتی دارد. انتخاب باید بر اساس نیاز به سازگاری نسخه، اثر روی Session، مدیریت خطا، امکان Rollback و نتیجه قابل مشاهده انجام شود.

سؤال 6: چه زمانی برای پیاده‌سازی Summary از خدمات مشاوره SQL Server استفاده کنیم؟

اگر فرمان بخشی از مهاجرت، بازیابی، نگهداری Production، تغییر امنیتی یا عملیات دارای SLA است، بازبینی متخصص ارزشمند است. مشاور می‌تواند پیش‌نیاز، اسکریپت برگشت، مانیتورینگ، تست بار و معیار پذیرش را قبل از اجرا مشخص کند.

سؤال 7: رایج‌ترین خطا هنگام کار با Summary چیست؟

ترکیب دستورهای مدیریتی بدون ترتیب روشن ریسک توقف سرویس دارد. همچنین بی‌توجهی به Context، مجوز و Scope باعث می‌شود نمونه‌ای که در آزمایش موفق بوده در Production رفتار دیگری نشان دهد. راه‌حل، Guard صریح، TRY/CATCH و ثبت ورودی‌های واقعی است.

سؤال 8: اثر Summary بر Performance چگونه ارزیابی می‌شود؟

عملیات را اندازه‌گیری و در بازه کم‌بار اجرا کنید. پیش و پس از اجرا باید Duration، CPU، IO، Waitها، Blocking و حجم Log متناسب با موضوع اندازه‌گیری شود. یک Snapshot منفرد کافی نیست و مقایسه با Baseline دوره مشابه نتیجه معتبرتری می‌دهد.

سؤال 9: بهترین روش استفاده از Summary چیست؟

بهترین روش این است که هدف، Context، مجوز، اثر تراکنشی، Timeout و مسیر بازگشت مستند شوند. اسکریپت باید قابل اجرای مجدد یا دست‌کم دارای کنترل جلوگیری از اجرای دوباره باشد و نتیجه نهایی را به‌صورت قابل ممیزی گزارش کند.

سؤال 10: Summary با کدام نسخه‌های SQL Server سازگار است؟

الگو باید با نسخه SQL Server، Edition، Recovery Model، مجوزها و محیط On-premises یا Cloud تطبیق داده شود. علاوه بر شماره نسخه، Compatibility Level، Edition، سیستم‌عامل، سرویس ابری و مجوز حساب اجرا نیز باید در محیط مقصد آزموده شود؛ مستندات همان نسخه مرجع نهایی تصمیم است.

سؤالات مصاحبه SQL Server

پرسش مصاحبه 1: در مصاحبه چگونه کاربرد Summary را توضیح دهیم؟

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

پرسش مصاحبه 2: چه نکته‌ای پاسخ مبتدی و حرفه‌ای درباره Summary را جدا می‌کند؟

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

پرسش مصاحبه 3: اگر اجرای Summary شکست بخورد چه می‌کنید؟

ابتدا Error Number، Message، State، Context، ورودی و وضعیت تراکنش ثبت می‌شود. سپس بدون تکرار کورکورانه، علت بررسی و بر اساس Runbook مسیر Rollback یا Retry کنترل‌شده اجرا می‌شود.

پرسش مصاحبه 4: چگونه Summary را برای Production آماده می‌کنید؟

حداقل مجوز، Guard مقصد، ورودی پارامتری، Timeout، TRY/CATCH، ثبت نتیجه، آزمون روی داده نماینده و تأیید مالک سرویس لازم است. برای عملیات مدیریتی، پنجره اجرا و برنامه بازگشت نیز تعیین می‌شود.

پرسش مصاحبه 5: چه معیارهایی موفقیت Summary را ثابت می‌کنند؟

معیار باید قابل اندازه‌گیری باشد: نتیجه داده، وضعیت Session یا Database، زمان اجرا، نبود خطای جدید، اثر قابل قبول بر IO و Blocking و ثبت خروجی کنترلی. معیار پذیرش پیش از اجرا نوشته می‌شود.

چک‌لیست نهایی

Context پایگاه داده و نام Instance تأیید شد.
Syntax و ورودی‌ها در محیط آزمایش اجرا شدند.
مجوزها و اثر روی Session یا Database مشخص است.
مسیر خطا، Rollback و Timeout بررسی شده است.
اثر کارایی با Baseline مقایسه می‌شود.
خروجی کنترلی و لاگ نهایی تعریف شده است.
برای عملیات حساس، Backup و تأیید مالک سرویس وجود دارد.
اسکریپت و نتیجه اجرا نسخه‌بندی و مستند می‌شوند.

جمع‌بندی

جمع‌بندی دستورات کاربردی زمانی به‌درستی استفاده شده است که علاوه بر نتیجه فنی، ریسک عملیاتی آن هم مدیریت شود. در این مقاله Syntax، پارامترها، ده سناریوی مستقل، خروجی نمونه، خطاها، Performance، Best Practice و پرسش‌های مصاحبه بررسی شد تا بتوانید فرمان را آگاهانه در Query، Procedure، Job یا Runbook به کار ببرید.

برای مرور ارتباط Summary با دیگر موضوع‌های این مجموعه، به مقاله مادر دستورات کاربردی SQL Server بازگردید. پیش از استفاده در Production، نمونه مرتبط را با نام‌ها، مسیرها، مجوزها و SLA واقعی سازمان خود تطبیق دهید.

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