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

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

توسط admin | گروه SQL Server | 1405/04/29

نظرات 0

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

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

دستور SET IDENTITY_INSERT یکی از موضوع‌های مهم مجموعه دستورات کاربردی Microsoft SQL Server است. اجازه می‌دهد مقدار ستون Identity به‌صورت صریح درج شود و برای مهاجرت، بازیابی شناسه‌های تاریخی و Seed داده کنترل‌شده کاربرد دارد. شناخت این دستور زمانی ارزشمند می‌شود که علاوه بر شکل نوشتن، محدوده اثر، نیازمندی مجوز، رفتار در تراکنش و پیامد عملیاتی آن نیز روشن باشد.

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

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

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

تعریف دستور SET IDENTITY_INSERT

اجازه می‌دهد مقدار ستون Identity به‌صورت صریح درج شود و برای مهاجرت، بازیابی شناسه‌های تاریخی و Seed داده کنترل‌شده کاربرد دارد.

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

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

Syntax استاندارد

SET IDENTITY_INSERT [ database_name . schema_name . ] table { ON | OFF };

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

  • نام دقیق جدول دارای ستون Identity
  • ON برای اجازه مقدار صریح
  • OFF برای بازگشت به تولید خودکار
  • فهرست ستون‌های صریح در INSERT

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

خروجی مستقیمی ندارد و وضعیت Session را تغییر می‌دهد؛ در هر Session فقط یک جدول می‌تواند IDENTITY_INSERT روشن داشته باشد.

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

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

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

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

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

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

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

مثال شماره 1: درج شناسه صریح

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY(1,1) PRIMARY KEY, Title nvarchar(50));
SET IDENTITY_INSERT #IdentityDemo ON;
INSERT #IdentityDemo(Id, Title) VALUES (10, N'رکورد تاریخی');
SET IDENTITY_INSERT #IdentityDemo OFF;
SELECT * FROM #IdentityDemo;
خروجی نمونهتفسیر نتیجه
Id = 10نتیجه مورد انتظار نشان می‌دهد سناریوی درج شناسه صریح با موفقیت طی شده است.

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

مثال شماره 2: بازگشت به تولید خودکار

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY(1,1), Title nvarchar(50));
SET IDENTITY_INSERT #IdentityDemo ON;
INSERT #IdentityDemo(Id, Title) VALUES (5, N'صریح');
SET IDENTITY_INSERT #IdentityDemo OFF;
INSERT #IdentityDemo(Title) VALUES (N'خودکار');
SELECT * FROM #IdentityDemo ORDER BY Id;
خروجی نمونهتفسیر نتیجه
شناسه‌های 5 و سپس 6نتیجه مورد انتظار نشان می‌دهد سناریوی بازگشت به تولید خودکار با موفقیت طی شده است.

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

مثال شماره 3: پرکردن شکاف شناسه

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY(1,1) PRIMARY KEY);
INSERT #IdentityDemo DEFAULT VALUES;
INSERT #IdentityDemo DEFAULT VALUES;
DELETE #IdentityDemo WHERE Id = 2;
SET IDENTITY_INSERT #IdentityDemo ON;
INSERT #IdentityDemo(Id) VALUES (2);
SET IDENTITY_INSERT #IdentityDemo OFF;
SELECT * FROM #IdentityDemo ORDER BY Id;
خروجی نمونهتفسیر نتیجه
شناسه‌های 1 و 2نتیجه مورد انتظار نشان می‌دهد سناریوی پرکردن شکاف شناسه با موفقیت طی شده است.

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

مثال شماره 4: مدیریت امن با TRY/CATCH

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY PRIMARY KEY);
BEGIN TRY
    SET IDENTITY_INSERT #IdentityDemo ON;
    INSERT #IdentityDemo(Id) VALUES (20);
    SET IDENTITY_INSERT #IdentityDemo OFF;
END TRY
BEGIN CATCH
    SET IDENTITY_INSERT #IdentityDemo OFF;
    THROW;
END CATCH;
خروجی نمونهتفسیر نتیجه
درج موفق Id برابر 20نتیجه مورد انتظار نشان می‌دهد سناریوی مدیریت امن با TRY/CATCH با موفقیت طی شده است.

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

مثال شماره 5: کنترل شناسه تکراری

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY PRIMARY KEY);
INSERT #IdentityDemo DEFAULT VALUES;
BEGIN TRY
    SET IDENTITY_INSERT #IdentityDemo ON;
    INSERT #IdentityDemo(Id) VALUES (1);
END TRY
BEGIN CATCH
    SET IDENTITY_INSERT #IdentityDemo OFF;
    SELECT ERROR_NUMBER() AS ErrorNumber;
END CATCH;
خروجی نمونهتفسیر نتیجه
خطای کلید تکراری 2627 یا 2601نتیجه مورد انتظار نشان می‌دهد سناریوی کنترل شناسه تکراری با موفقیت طی شده است.

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

مثال شماره 6: درج چند ردیف مهاجرتی

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY PRIMARY KEY, Code char(1));
SET IDENTITY_INSERT #IdentityDemo ON;
INSERT #IdentityDemo(Id, Code) VALUES (101, 'A'), (105, 'B'), (110, 'C');
SET IDENTITY_INSERT #IdentityDemo OFF;
SELECT COUNT(*) AS MigratedRows, MAX(Id) AS MaxId FROM #IdentityDemo;
خروجی نمونهتفسیر نتیجه
3 ردیف و MaxId برابر 110نتیجه مورد انتظار نشان می‌دهد سناریوی درج چند ردیف مهاجرتی با موفقیت طی شده است.

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

مثال شماره 7: درج داخل تراکنش

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY PRIMARY KEY);
BEGIN TRANSACTION;
SET IDENTITY_INSERT #IdentityDemo ON;
INSERT #IdentityDemo(Id) VALUES (50);
SET IDENTITY_INSERT #IdentityDemo OFF;
ROLLBACK TRANSACTION;
SELECT COUNT(*) AS RemainingRows FROM #IdentityDemo;
خروجی نمونهتفسیر نتیجه
RemainingRows = 0نتیجه مورد انتظار نشان می‌دهد سناریوی درج داخل تراکنش با موفقیت طی شده است.

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

مثال شماره 8: مقایسه با CHECKIDENT

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY(1,1));
INSERT #IdentityDemo DEFAULT VALUES;
DBCC CHECKIDENT('#IdentityDemo', RESEED, 100);
INSERT #IdentityDemo DEFAULT VALUES;
SELECT MAX(Id) AS NewId FROM #IdentityDemo;
خروجی نمونهتفسیر نتیجه
NewId = 101نتیجه مورد انتظار نشان می‌دهد سناریوی مقایسه با CHECKIDENT با موفقیت طی شده است.

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

مثال شماره 9: جلوگیری از درج دوباره

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY PRIMARY KEY, Title nvarchar(20));
SET IDENTITY_INSERT #IdentityDemo ON;
IF NOT EXISTS (SELECT 1 FROM #IdentityDemo WHERE Id = 7)
    INSERT #IdentityDemo(Id, Title) VALUES (7, N'مرجع');
SET IDENTITY_INSERT #IdentityDemo OFF;
SELECT * FROM #IdentityDemo;
خروجی نمونهتفسیر نتیجه
یک ردیف با Id برابر 7نتیجه مورد انتظار نشان می‌دهد سناریوی جلوگیری از درج دوباره با موفقیت طی شده است.

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

مثال شماره 10: کنترل Seed پس از مهاجرت

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

DROP TABLE IF EXISTS #IdentityDemo;
CREATE TABLE #IdentityDemo(Id int IDENTITY PRIMARY KEY);
SET IDENTITY_INSERT #IdentityDemo ON;
INSERT #IdentityDemo(Id) VALUES (200);
SET IDENTITY_INSERT #IdentityDemo OFF;
DBCC CHECKIDENT('#IdentityDemo', NORESEED);
INSERT #IdentityDemo DEFAULT VALUES;
SELECT MAX(Id) AS LatestId FROM #IdentityDemo;
خروجی نمونهتفسیر نتیجه
LatestId = 201 و پیام Seedنتیجه مورد انتظار نشان می‌دهد سناریوی کنترل Seed پس از مهاجرت با موفقیت طی شده است.

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

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

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

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

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

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

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

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

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

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

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

  1. هدف و Scope دستور SET IDENTITY_INSERT را در ابتدای اسکریپت توضیح دهید.
  2. از نام Schema، نوع داده و تبدیل صریح استفاده کنید.
  3. مقادیر فارسی را با N و نوع nvarchar نگه دارید.
  4. برای خطای واقعی از TRY/CATCH و THROW استفاده کنید.
  5. تراکنش را کوتاه نگه دارید و XACT_STATE را در CATCH کنترل کنید.
  6. اسکریپت را تا حد ممکن قابل اجرای مجدد طراحی کنید.
  7. خروجی کنترلی و معیار پذیرش را در همان فایل قرار دهید.
  8. نسخه SQL Server و تفاوت محیط Cloud را پیش از استقرار بررسی کنید.

مقایسه SET IDENTITY_INSERT با DBCC CHECKIDENT برای مشاهده یا تغییر Seed بدون درج رکورد تاریخی باید بر اساس نیاز واقعی انجام شود. انتخاب فناوری یا فرمان صرفاً به دلیل آشنایی قبلی، ممکن است خوانایی، سازگاری یا قابلیت پشتیبانی آینده را کاهش دهد.

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

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

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

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

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

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

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

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

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

سؤال 5: تفاوت SET IDENTITY_INSERT با DBCC CHECKIDENT برای مشاهده یا تغییر Seed بدون درج رکورد تاریخی چیست؟

SET IDENTITY_INSERT برای اجازه می‌دهد مقدار ستون Identity به‌صورت صریح درج شود و برای مهاجرت، بازیابی شناسه‌های تاریخی و Seed داده کنترل‌شده کاربرد دارد. گزینه تخصصی‌تری است، درحالی‌که DBCC CHECKIDENT برای مشاهده یا تغییر Seed بدون درج رکورد تاریخی دامنه یا هدف متفاوتی دارد. انتخاب باید بر اساس نیاز به سازگاری نسخه، اثر روی Session، مدیریت خطا، امکان Rollback و نتیجه قابل مشاهده انجام شود.

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

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

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

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

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

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

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

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

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

در نسخه‌های رایج SQL Server پشتیبانی می‌شود و به مالکیت جدول یا مجوز ALTER نیاز دارد. علاوه بر شماره نسخه، Compatibility Level، Edition، سیستم‌عامل، سرویس ابری و مجوز حساب اجرا نیز باید در محیط مقصد آزموده شود؛ مستندات همان نسخه مرجع نهایی تصمیم است.

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

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

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

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

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

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

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

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

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

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

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

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

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

جمع‌بندی

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

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

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

نظرات محترم شما در خدمات رسانی بهتر ما را یاری می نمایند. لطفا اگر مایل بودید یک نظر ما را مهمان فرمائید. آدرس ایمیل و وب سایت شما نمایش داده نخواهد شد.

حرف 500 حداکثر

اطلاعات تماس

  • آدرس:اصفهان-خیابان ام کلثوم غربی - بعد خیابان تخم چی - بیست متر بعد از پیتزا ننه شب - کوچه تعمیر گاه سمار زغالی - پلاک 354 - درب مشکی - طبقه هفتم
  • آدرس ایمیل:najafzade@gmail.com
  • وب سایت:http://www.a00b.com/
  • تلفن ثابت:(+98)9131253620
  • تلفن همراه:09131253620