مقدمه

@@SERVERNAME یکی از قابلیت‌های سیستمی Transact-SQL است که در عیب‌یابی، کنترل عملیات و ثبت Metadata کاربرد دارد. این مقاله از تعریف پایه شروع می‌کند و سپس با ده مثال مستقل، رفتار واقعی آن را در SQL Server توضیح می‌دهد.

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

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

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

تعریف، کاربرد و مرز عملکرد

نوع خروجی @@SERVERNAME برابر nvarchar است. هنگام ذخیره در ستون یا متغیر، نوع مقصد را آگاهانه انتخاب کنید؛ تبدیل ضمنی ممکن است در حجم بالا، مقدار بزرگ یا تغییر Schema باعث خطای سرریز یا رفتار پیش‌بینی‌نشده شود.

پس از تغییر نام ماشین ممکن است تا اصلاح Metadata و Restart با نام واقعی میزبان متفاوت باشد؛ برای سناریوهای دقیق SERVERPROPERTY را هم بررسی کنید. این نکته به‌ویژه زمانی مهم است که Trigger، Dynamic SQL، Stored Procedure تو‌در‌تو، Connection Pooling یا چند دستور تشخیصی در مسیر اجرا وجود دارد.

خروجی صفر، NULL یا مقدار قدیمی الزاماً خطای موتور نیست؛ گاهی تعریف تابع دقیقاً چنین رفتاری دارد. برای تحلیل درست، یک آزمایش کوچک در همان اتصال بسازید و قبل و بعد از هر Statement مقدارهای مرتبط را ثبت کنید.

قاعده طلایی: پس از تغییر نام ماشین ممکن است تا اصلاح Metadata و Restart با نام واقعی میزبان متفاوت باشد؛ برای سناریوهای دقیق SERVERPROPERTY را هم بررسی کنید. نتیجه را همراه با زمینه اجرا تفسیر کنید و از تبدیل یک مقدار سیستمی به فرض تجاری بدون آزمون پرهیز نمایید.

Syntax و نوع خروجی

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

SELECT @@SERVERNAME AS ConfiguredServerName;

نوع بازگشتی nvarchar است. برای API یا لایه داده، نوع C# یا مقصد پایگاه داده را مطابق همین نوع و دامنه مقادیر انتخاب کنید و حالت NULL را، هرجا از نظر معنایی ممکن است، صریح مدیریت نمایید.

مثال‌های عملی از پایه تا حرفه‌ای

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

SELECT @@SERVERNAME AS ConfiguredServerName;

SELECT @@SERVERNAME AS ConfiguredName,
           CONVERT(nvarchar(128), SERVERPROPERTY('ServerName')) AS ServerPropertyName;

SELECT CONVERT(nvarchar(128), SERVERPROPERTY('MachineName')) AS MachineName,
           COALESCE(CONVERT(nvarchar(128), SERVERPROPERTY('InstanceName')), N'MSSQLSERVER') AS InstanceName;

DECLARE @Server nvarchar(128) = @@SERVERNAME;
    SELECT @Server AS ServerForAudit;

SELECT @@SERVERNAME AS ServerName, DB_NAME() AS DatabaseName, ORIGINAL_LOGIN() AS LoginName;

SELECT CASE WHEN @@SERVERNAME IS NULL THEN N'نیازمند بررسی پیکربندی' ELSE N'پیکربندی موجود است' END AS Status;

SELECT CONCAT(COALESCE(CONVERT(nvarchar(128),@@SERVERNAME),N'UNKNOWN'),N'/',DB_NAME()) AS EnvironmentLabel;

SELECT @@SERVERNAME AS ServerName, @@SPID AS SessionId, GETDATE() AS LocalTime;

-- مقایسه مستقیم نام می‌تواند پس از مهاجرت بشکند
    SELECT CASE WHEN SERVERPROPERTY('EngineEdition') IN (5,8)
                THEN N'محیط ابری' ELSE N'محیط SQL Server' END AS PortableCheck;

SELECT @@SERVERNAME AS ConfiguredName,
           SERVERPROPERTY('ProductVersion') AS ProductVersion,
           SERVERPROPERTY('Edition') AS Edition;

خطاهای رایج

بخش مهم یادگیری @@SERVERNAME شناخت خطاهایی است که Syntax صحیح دارند اما منطق نادرست تولید می‌کنند. این خطاها ممکن است در تست تک‌کاربره دیده نشوند و فقط زیر بار یا با Trigger آشکار گردند.

• 1. برابر فرض کردن آن با MachineName در همه محیط‌ها. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 2. نادیده گرفتن Named Instance. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 3. تغییر نام سرور بدون برنامه Restart. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.
• 4. Hard-code کردن نام Production در Queryهای برنامه. برای اصلاح، مرز تابع و ترتیب Statementها را مستند و با یک تست قابل تکرار کنترل کنید.

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

Performance و بهینه‌سازی

ثابت سیستمی سبکی است، اما نباید شرط‌های پرتکرار تجاری یا مسیر اتصال را بر مبنای رشته‌ای شکننده طراحی کرد.

برای سنجش اثر واقعی، قبل و بعد از تغییر کد از Query Store، Actual Execution Plan، SET STATISTICS IO/TIME و در صورت نیاز Extended Events استفاده کنید. اندازه‌گیری باید روی Query اصلی، تعداد Logical Read، زمان CPU، مدت قفل و حجم Log متمرکز باشد.

از اجرای Query اضافی فقط برای بازسازی اطلاعاتی که موتور همان لحظه در اختیار گذاشته اجتناب کنید. در عین حال، تابع سیستمی را جایگزین کنترل صحت داده، Constraint، ایندکس مناسب یا طراحی Transaction نکنید.

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

بهترین روش‌ها و کاربرد سازمانی

• مقدار @@SERVERNAME را در نزدیک‌ترین نقطه به دستور مرجع بخوانید.
• نوع خروجی nvarchar و امکان NULL یا صفر را صریح در مدل داده لحاظ کنید.
• برای خطا از TRY...CATCH، THROW و XACT_STATE با قرارداد یکسان استفاده کنید.
• کد را زیر هم‌زمانی واقعی و در حضور Trigger یا Connection Pooling آزمایش کنید.
• از Hard-code کردن نام محیط و فرض‌های وابسته به ترتیب اجرا خودداری کنید.
• در لاگ، SPID، زمان، نام دیتابیس و شناسه همبستگی را بدون داده حساس نگه دارید.

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

برای مهاجرت نسخه یا انتقال به محیط جدید، مجموعه تست سازگاری بسازید. Compatibility Level، مجوز DMVها، رفتار Driver و تنظیمات Connection Pool می‌توانند روی مشاهده‌پذیری پیرامون تابع اثر بگذارند، حتی اگر Syntax خود تابع ثابت مانده باشد.

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

پرسش 1: @@SERVERNAME دقیقاً چه کاری انجام می‌دهد؟

@@SERVERNAME نام محلی پیکربندی‌شده برای نمونه SQL Server را برمی‌گرداند و ممکن است نام Instance را نیز شامل شود. خروجی باید در متن همان Batch و با توجه به Scope، Session و دستور قبلی تفسیر شود؛ جدا کردن آن از زمینه اجرا می‌تواند نتیجه‌ای ظاهراً درست اما از نظر تجاری اشتباه بسازد.

پرسش 2: بهترین زمان خواندن @@SERVERNAME چه موقع است؟

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

پرسش 3: آیا @@SERVERNAME برای سامانه‌های سازمانی مناسب است؟

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

پرسش 4: برای پیاده‌سازی صحیح آن به مشاوره SQL Server نیاز است؟

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

پرسش 5: تفاوت @@SERVERNAME با گزینه‌های نزدیک چیست؟

تفاوت اصلی در دامنه مشاهده و نوع اطلاعات است. باید مشخص شود نیاز شما مربوط به آخرین Statement، نشست جاری، Scope جاری، جدول مشخص یا Metadata سرور است؛ سپس تابعی انتخاب شود که دقیقاً همان مرز را پوشش دهد.

پرسش 6: آیا می‌توان این الگو را در Stored Procedure پروژه پیاده کرد؟

بله. بهتر است مقدار در همان Procedure گرفته شود، نوع خروجی صریح باشد، خطا با TRY...CATCH مدیریت شود و نتیجه از طریق Result Set، پارامتر OUTPUT یا قرارداد سرویس بازگردد. تست یکپارچه نیز حالت موفق و شکست را پوشش دهد.

پرسش 7: خطای رایج هنگام استفاده از @@SERVERNAME چیست؟

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

پرسش 8: اثر @@SERVERNAME بر Performance چیست؟

ثابت سیستمی سبکی است، اما نباید شرط‌های پرتکرار تجاری یا مسیر اتصال را بر مبنای رشته‌ای شکننده طراحی کرد. هزینه اصلی معمولاً از Query یا Transaction پیرامون آن می‌آید، نه خود تابع. اندازه‌گیری با Actual Execution Plan، Query Store و Extended Events باید روی کل جریان انجام شود.

پرسش 9: Best Practice اصلی برای @@SERVERNAME چیست؟

مقدار را نزدیک به دستور مرجع بخوانید، در نوع مناسب ذخیره کنید، نتیجه‌های مرزی مانند صفر یا NULL را تست کنید و برای عملیات حساس گزارش ممیزی بسازید. از تکیه بر ترتیب اتفاقی دستورات یا رشته‌های Hard-coded دوری کنید.

پرسش 10: این قابلیت در کدام نسخه‌های SQL Server کار می‌کند؟

این قابلیت در نسخه‌های رایج و پشتیبانی‌شده SQL Server در دسترس است، اما امکانات مکمل مانند SESSION_CONTEXT، THROW یا برخی DMVها به نسخه و سطح سازگاری وابسته‌اند. پیش از استقرار، مستندات همان نسخه و Compatibility Level پایگاه داده را کنترل کنید.

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

سؤال 1: مرز مشاهده @@SERVERNAME چیست؟

پاسخ حرفه‌ای باید مشخص کند تابع به Statement، Scope، Session، Table یا Server مربوط است و یک مثال نقض نیز ارائه دهد. گفتن نام تابع بدون توضیح مرز مشاهده برای مصاحبه فنی کافی نیست.

سؤال 2: چگونه مقدار را بدون Race Condition مصرف می‌کنید؟

مقدار باید نزدیک به عملیات مرجع، در همان اتصال و داخل قرارداد تراکنش خوانده شود. برای چند ردیف یا خروجی‌های حساس، قابلیت OUTPUT یا Metadata ساخت‌یافته می‌تواند انتخاب دقیق‌تری باشد.

سؤال 3: در CATCH چه اطلاعاتی ثبت می‌کنید؟

شماره و متن خطا، Procedure، Line، XACT_STATE، @@TRANCOUNT، نام پایگاه داده، SPID و شناسه همبستگی از اطلاعات مفید هستند. داده حساس نباید بدون پالایش وارد Log شود.

سؤال 4: چطور این کد را تست می‌کنید؟

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

سؤال 5: چه زمانی گزینه دیگری را انتخاب می‌کنید؟

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

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

• تعریف و مرز @@SERVERNAME را با یک مثال توضیح داده‌ام.
• مقدار بلافاصله پس از دستور مرتبط ذخیره می‌شود.
• حالت صفر، NULL، خطا و هم‌زمانی تست شده است.
• تراکنش در مسیر موفق Commit و در مسیر شکست Rollback می‌شود.
• نتیجه با نوع مناسب و نام ستون روشن به لایه مصرف‌کننده می‌رسد.
• لاگ فنی برای عیب‌یابی وجود دارد و داده حساس ثبت نمی‌شود.

جمع‌بندی

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

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