آموزش جامع دستور RAISERROR در SQL Server

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

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

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

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

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

تعریف دستور RAISERROR

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

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

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

Syntax استاندارد

RAISERROR ( { msg_id | msg_str | @local_variable }, severity, state [ , argument [ ,...n ] ] ) [ WITH option [ ,...n ] ];

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

msg_str یا msg_id برای متن یا شناسه پیام
severity برای سطح شدت از ۰ تا ۲۵ با محدودیت مجوز
state برای مشخص‌کردن محل منطقی رخداد
آرگومان‌های قالب مانند درصد s و درصد d
گزینه‌های NOWAIT، LOG و SETERROR

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

بسته به شدت، پیام اطلاع‌رسانی یا خطا ایجاد می‌کند. برخلاف THROW همیشه از رفتار SET XACT_ABORT پیروی نمی‌کند.

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

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

سه کاربرد پرتکرار این موضوع عبارت‌اند از اعتبارسنجی قواعد تجاری، ارسال پیشرفت فوری عملیات طولانی، حفظ رفتار سامانه‌های قدیمی مبتنی بر شدت خطا. در هر سه حالت، مالک عملیات و معیار پذیرش باید قبل از اجرا تعیین شود و تغییر مهم بدون نسخه پشتیبان یا مسیر Rollback انجام نشود.

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

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

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

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

مثال شماره 1: ایجاد خطای سفارشی پایه

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

BEGIN TRY
    RAISERROR(N'مقدار ورودی نامعتبر است.', 16, 1);
END TRY
BEGIN CATCH
    SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_MESSAGE() AS ErrorMessage;
END CATCH;

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

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

مثال شماره 2: جای‌گذاری مقدار در پیام

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

DECLARE @OrderId int = 42;
RAISERROR(N'سفارش شماره %d پیدا نشد.', 10, 1, @OrderId);

خروجی نمونه	تفسیر نتیجه
سفارش شماره 42 پیدا نشد	نتیجه مورد انتظار نشان می‌دهد سناریوی جای‌گذاری مقدار در پیام با موفقیت طی شده است.

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

مثال شماره 3: پیام فوری بدون خطا

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

RAISERROR(N'مرحله اول کامل شد.', 0, 1) WITH NOWAIT;
WAITFOR DELAY '00:00:01';
RAISERROR(N'مرحله دوم کامل شد.', 0, 1) WITH NOWAIT;

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

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

مثال شماره 4: کنترل State خطا

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

BEGIN TRY
    RAISERROR(N'خطای اعتبارسنجی', 16, 7);
END TRY
BEGIN CATCH
    SELECT ERROR_STATE() AS ErrorState;
END CATCH;

خروجی نمونه	تفسیر نتیجه
ErrorState = 7	نتیجه مورد انتظار نشان می‌دهد سناریوی کنترل State خطا با موفقیت طی شده است.

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

مثال شماره 5: استفاده از متغیر متن

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

DECLARE @ErrorText nvarchar(200) = N'موجودی کافی نیست.';
BEGIN TRY
    RAISERROR(@ErrorText, 16, 1);
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE() AS Message;
END CATCH;

خروجی نمونه	تفسیر نتیجه
موجودی کافی نیست	نتیجه مورد انتظار نشان می‌دهد سناریوی استفاده از متغیر متن با موفقیت طی شده است.

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

مثال شماره 6: اعتبارسنجی پیش از درج

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

DECLARE @Amount decimal(12,2) = -10;
BEGIN TRY
    IF @Amount < 0
        RAISERROR(N'مبلغ نمی‌تواند منفی باشد.', 16, 2);
    SELECT N'معتبر' AS Status;
END TRY
BEGIN CATCH
    SELECT ERROR_MESSAGE() AS Status;
END CATCH;

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

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

مثال شماره 7: تفاوت شدت ۱۰ و ۱۶

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

RAISERROR(N'این فقط هشدار است.', 10, 1);
BEGIN TRY
    RAISERROR(N'این خطای اجرایی است.', 16, 1);
END TRY
BEGIN CATCH
    SELECT N'CATCH اجرا شد' AS Flow;
END CATCH;

خروجی نمونه	تفسیر نتیجه
فقط شدت 16 وارد CATCH می‌شود	نتیجه مورد انتظار نشان می‌دهد سناریوی تفاوت شدت ۱۰ و ۱۶ با موفقیت طی شده است.

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

مثال شماره 8: ثبت شماره خط در CATCH

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

BEGIN TRY
    RAISERROR(N'خطای نمونه', 16, 3);
END TRY
BEGIN CATCH
    SELECT ERROR_LINE() AS ErrorLine, ERROR_STATE() AS ErrorState;
END CATCH;

خروجی نمونه	تفسیر نتیجه
شماره خط و State برابر 3	نتیجه مورد انتظار نشان می‌دهد سناریوی ثبت شماره خط در CATCH با موفقیت طی شده است.

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

مثال شماره 9: بازگردانی تراکنش پس از خطا

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

BEGIN TRY
    BEGIN TRANSACTION;
    RAISERROR(N'لغو عملیات', 16, 1);
    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF XACT_STATE() <> 0 ROLLBACK TRANSACTION;
    SELECT XACT_STATE() AS FinalState;
END CATCH;

خروجی نمونه	تفسیر نتیجه
FinalState = 0	نتیجه مورد انتظار نشان می‌دهد سناریوی بازگردانی تراکنش پس از خطا با موفقیت طی شده است.

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

مثال شماره 10: نسخه جدید با THROW

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

BEGIN TRY
    THROW 51000, N'نسخه مدرن خطای سفارشی', 1;
END TRY
BEGIN CATCH
    SELECT ERROR_NUMBER() AS ErrorNumber, ERROR_MESSAGE() AS ErrorMessage;
END CATCH;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

دستور RAISERROR خطا یا پیام سفارشی را با شدت، State و قالب‌بندی کنترل‌شده ایجاد می‌کند و در سامانه‌های قدیمی هنوز بسیار دیده می‌شود. دامنه اثر آن باید پیش از اجرا شناخته شود و نمونه نخست در محیط آزمایش بررسی شود تا انتظار تیم از پیام، Result Set یا تغییر وضعیت Session دقیق باشد.

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

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

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

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

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

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

سؤال 5: تفاوت RAISERROR با THROW برای کد جدید و مدیریت خطای مدرن چیست؟

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

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

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

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

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

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

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

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

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

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

برای سازگاری عقب‌رو حفظ شده است؛ برای توسعه جدید معمولاً THROW پیشنهاد می‌شود، مگر قابلیت قالب‌بندی یا NOWAIT لازم باشد. علاوه بر شماره نسخه، Compatibility Level، Edition، سیستم‌عامل، سرویس ابری و مجوز حساب اجرا نیز باید در محیط مقصد آزموده شود؛ مستندات همان نسخه مرجع نهایی تصمیم است.

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

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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

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