آموزش جامع تابع FILE_NAME در SQL Server با ۱۰ مثال عملی
بخش مهمی از کار با SQL Server به خواندن درست Metadata و تفسیر محتاطانه مقادیر سیستمی وابسته است. در این مقاله، FILE_NAME از سطح مقدماتی تا سناریوهای حرفهای بررسی میشود و هر مثال با خروجی نمونه ارائه شده است.
این تابع در گزارش مصرف فایل، تحلیل رشد، پشتیبانگیری و نگهداری برای نمایش نام قابل فهم فایل بهجای file_id کاربرد دارد. تمرکز آموزش بر این است که FILE_NAME در چه Contextی اجرا شود، نتیجه آن چگونه تفسیر شود و چه زمانی باید از یک DMV یا کاتالوگویوی جایگزین کمک گرفت.
برای مشاهده جایگاه FILE_NAME میان سایر توابع و شمارندهها، راهنمای جامع توابع کمکی کارایی و Metadata در SQL Server را نیز مطالعه کنید.
تعریف و کاربرد اصلی FILE_NAME
تابع FILE_NAME شناسه یک فایل در پایگاه داده جاری را به نام منطقی همان فایل تبدیل میکند. این تعریف در ظاهر کوتاه است، اما استفاده درست از FILE_NAME به درک مفاهیمی مانند file_id، logical file name و sys.database_files وابسته است.
قاعده عملی FILE_NAME: ابتدا ورودی و Context را معتبر کنید، سپس خروجی را با نوع داده و معنای واقعی آن تفسیر کنید.
Syntax تابع یا متغیر FILE_NAME
SELECT FILE_NAME ( file_id ) AS Result;
پارامترهای FILE_NAME
| پارامتر | توضیح |
|---|
| file_id | شناسه فایل در پایگاه داده جاری که از sys.database_files یا توابع مرتبط بهدست میآید. |
نوع خروجی و رفتار NULL در FILE_NAME
nvarchar(128)؛ برای شناسه نامعتبر یا خارج از Context جاری مقدار NULL. در کد تولیدی بهتر است نوع مقصد بهصورت صریح تعیین شود؛ زیرا تبدیل ضمنی میتواند مقایسه، مرتبسازی یا ذخیره نتیجه FILE_NAME را مبهم کند.
مفاهیم کلیدی مرتبط با FILE_NAME
- file_id در مبحث FILE_NAME
- logical file name در مبحث FILE_NAME
- sys.database_files در مبحث FILE_NAME
- data file
- log file
- database context
- NULL در مبحث FILE_NAME
تصویر نخست، ارتباط FILE_NAME را با مفاهیم اختصاصی file_id، logical file name، sys.database_files و data file نشان میدهد؛ این روابط مبنای انتخاب ورودی و تفسیر خروجی هستند.
سناریوهای واقعی استفاده از FILE_NAME
سناریوی 1 برای FILE_NAME، «گزارش فضای فایل» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونهبرداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیبیابی بعدی ارزش داشته باشد.
سناریوی 2 برای FILE_NAME، «تشخیص فایل لاگ» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونهبرداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیبیابی بعدی ارزش داشته باشد.
سناریوی 3 برای FILE_NAME، «خواناسازی خروجی DBCC» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونهبرداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیبیابی بعدی ارزش داشته باشد.
سناریوی 4 برای FILE_NAME، «بررسی رشد فایل» است. در این حالت باید نتیجه همراه Context پایگاه داده، زمان نمونهبرداری و در صورت نیاز شناسه نشست ثبت شود تا داده برای عیبیابی بعدی ارزش داشته باشد.
مثالهای عملی FILE_NAME از ساده تا حرفهای
مثال 1: نام فایل اصلی
شناسه فایل 1 را در پایگاه جاری به نام منطقی تبدیل میکنیم. این سناریو بهطور اختصاصی برای درک رفتار FILE_NAME طراحی شده است.
SELECT FILE_NAME(1) AS PrimaryLogicalFileName;
| PrimaryLogicalFileName |
|---|
| a00b |
فایل 1 معمولاً فایل داده اصلی است، اما گزارش را با sys.database_files تأیید کنید. هنگام استفاده سازمانی از FILE_NAME، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.
مثال 2: نمایش همه فایلها
FILE_NAME را کنار Metadata فایلهای جاری میآوریم. این سناریو بهطور اختصاصی برای درک رفتار FILE_NAME طراحی شده است.
SELECT file_id,
FILE_NAME(file_id) AS LogicalFileName,
type_desc,
size
FROM sys.database_files
ORDER BY file_id;
| file_id | LogicalFileName | type_desc | size |
|---|
| 1 | a00b | ROWS | 131072 |
size بر حسب Page است و با نام منطقی تفاوت دارد. هنگام استفاده سازمانی از FILE_NAME، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.
مثال 3: نام فایل لاگ
شناسه فایل لاگ را از sys.database_files گرفته و تبدیل میکنیم. این سناریو بهطور اختصاصی برای درک رفتار FILE_NAME طراحی شده است.
SELECT FILE_NAME(file_id) AS LogLogicalName
FROM sys.database_files
WHERE type_desc = N'LOG';
در پایگاههایی با چند فایل لاگ، چند ردیف ممکن است برگردد. هنگام استفاده سازمانی از FILE_NAME، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.
مثال 4: مدیریت file_id نامعتبر
برای شناسه ناموجود پیام مناسب میسازیم. این سناریو بهطور اختصاصی برای درک رفتار FILE_NAME طراحی شده است.
SELECT COALESCE(FILE_NAME(9999), N'فایل یافت نشد') AS SafeFileName;
| SafeFileName |
|---|
| فایل یافت نشد |
NULL را در داشبورد به معنای فایل صفر تفسیر نکنید. هنگام استفاده سازمانی از FILE_NAME، خروجی نمونه را با داده واقعی محیط خود تطبیق دهید.
تصویر دوم، جریان اجرای FILE_NAME را از ورودی و اعتبارسنجی تا تولید خروجی نمایش میدهد و نشان میدهد که log file در کدام مرحله باید کنترل شود.
ادامه مثالهای پیشرفته FILE_NAME
مثال 5: ترکیب با FILEPROPERTY
نام حاصل را برای محاسبه صفحات مصرفشده استفاده میکنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون FILE_NAME است.
SELECT
df.file_id,
FILE_NAME(df.file_id) AS LogicalFileName,
FILEPROPERTY(FILE_NAME(df.file_id), N'SpaceUsed') AS UsedPages
FROM sys.database_files AS df
WHERE df.type_desc = N'ROWS';
| file_id | LogicalFileName | UsedPages |
|---|
| 1 | a00b | 99840 |
نام منطقی ورودی مناسب FILEPROPERTY است. این نکته از تفسیر سطحی یا استفاده تکراری و بیهدف از FILE_NAME جلوگیری میکند.
مثال 6: تفاوت نام منطقی و فیزیکی
دو مفهوم را کنار هم نمایش میدهیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون FILE_NAME است.
SELECT file_id,
FILE_NAME(file_id) AS LogicalName,
physical_name AS PhysicalPath
FROM sys.database_files;
| file_id | LogicalName | PhysicalPath |
|---|
| 1 | a00b | D:\SQLData\a00b.mdf |
برای ALTER DATABASE معمولاً نام منطقی و برای عملیات سیستمعامل مسیر فیزیکی مطرح است. این نکته از تفسیر سطحی یا استفاده تکراری و بیهدف از FILE_NAME جلوگیری میکند.
مثال 7: ساخت گزارش ظرفیت فایل
نام فایل را با اندازه MB ترکیب میکنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون FILE_NAME است.
SELECT FILE_NAME(file_id) AS LogicalFileName,
CAST(size * 8.0 / 1024 AS decimal(18,2)) AS SizeMB
FROM sys.database_files
ORDER BY file_id;
| LogicalFileName | SizeMB |
|---|
| a00b | 1024.00 |
ضریب 8 به علت اندازه 8KB هر Page است. این نکته از تفسیر سطحی یا استفاده تکراری و بیهدف از FILE_NAME جلوگیری میکند.
مثال 8: فیلتر فایل داده
فقط نام فایلهای ROWS را در خروجی نگه میداریم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون FILE_NAME است.
SELECT FILE_NAME(file_id) AS DataFileName
FROM sys.database_files
WHERE type = 0
ORDER BY file_id;
type=0 فایل داده و type=1 فایل لاگ را نشان میدهد. این نکته از تفسیر سطحی یا استفاده تکراری و بیهدف از FILE_NAME جلوگیری میکند.
مثال 9: روش اشتباه با مسیر فیزیکی
نشان میدهیم FILE_NAME شناسه میخواهد، نه مسیر. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون FILE_NAME است.
DECLARE @FileId int =
(
SELECT TOP (1) file_id
FROM sys.database_files
WHERE type = 0
ORDER BY file_id
);
SELECT FILE_NAME(@FileId) AS CorrectLogicalName;
مسیر MDF را به FILE_NAME ندهید؛ ابتدا file_id را از کاتالوگ بخوانید. این نکته از تفسیر سطحی یا استفاده تکراری و بیهدف از FILE_NAME جلوگیری میکند.
مثال 10: کاهش فراخوانی تابع
در گزارش بزرگ، ستون name مستقیم را با نتیجه تابع مقایسه میکنیم. در این مثال، هدف تنها اجرای Query نیست؛ بلکه نشان دادن یک تصمیم فنی صحیح پیرامون FILE_NAME است.
SELECT df.file_id,
df.name AS CatalogLogicalName,
FILE_NAME(df.file_id) AS FunctionLogicalName
FROM sys.database_files AS df;
| file_id | CatalogLogicalName | FunctionLogicalName |
|---|
| 1 | a00b | a00b |
برای Scan مجموعه فایلها، df.name سادهتر است؛ FILE_NAME برای تبدیل یک شناسه پراکنده ارزش دارد. این نکته از تفسیر سطحی یا استفاده تکراری و بیهدف از FILE_NAME جلوگیری میکند.
خطاهای رایج در کار با FILE_NAME
خطای 1 در استفاده از FILE_NAME
FILE_NAME فقط در Context پایگاه داده جاری کار میکند. برای رفع این مشکل، ورودی و Context را از منبع معتبر بخوانید و نتیجه FILE_NAME را پیش از ادامه منطق با شرط صریح کنترل کنید.
خطای 2 در استفاده از FILE_NAME
نام منطقی با مسیر فیزیکی فایل تفاوت دارد؛ مسیر را از sys.database_files بخوانید. برای رفع این مشکل، ورودی و Context را از منبع معتبر بخوانید و نتیجه FILE_NAME را پیش از ادامه منطق با شرط صریح کنترل کنید.
خطای 3 در استفاده از FILE_NAME
برای گزارش چندپایگاهدادهای باید Context هر پایگاه بهطور صریح مدیریت شود. برای رفع این مشکل، ورودی و Context را از منبع معتبر بخوانید و نتیجه FILE_NAME را پیش از ادامه منطق با شرط صریح کنترل کنید.
ملاحظات Performance برای FILE_NAME
از نظر کارایی، FILE_NAME زمانی کمهزینه باقی میماند که روی یک مقدار هدفمند یا مجموعه محدود اجرا شود. فراخوانی آن روی هزاران ردیف بدون Predicate اولیه میتواند CPU و زمان گزارش را افزایش دهد.
اگر گزارش به چند Property از چندین شیء نیاز دارد، استفاده Set-based از کاتالوگویو یا DMV مرتبط با file_id معمولاً بهتر از تکرار FILE_NAME برای هر سلول است.
در Jobهای دورهای، نتیجه FILE_NAME را همراه Timestamp ذخیره کنید، اما Frequency نمونهبرداری را متناسب با سرعت تغییر داده انتخاب کنید. جمعآوری بیش از حد، جدول تاریخچه را بدون ارزش تحلیلی بزرگ میکند.
برای محاسبات عددی پیرامون FILE_NAME، نوع داده را قبل از ضرب یا تفریق ارتقا دهید و در سناریوهای تجمعی، Restart و بازنشانی Baseline را در نظر بگیرید.
Best Practiceهای اختصاصی FILE_NAME
- ورودی FILE_NAME را از نام یا شناسه معتبر و دارای Schema یا Context روشن تأمین کنید.
- نتیجه NULL در FILE_NAME را از مقدار صفر، false یا رشته خالی جدا نگه دارید.
- نوع خروجی FILE_NAME را پیش از ذخیره یا مقایسه به نوع مقصد مناسب تبدیل کنید.
- در گزارشهای بزرگ، گزینه Set-based مرتبط با file_id را ارزیابی کنید.
- زمان Capture، نام Database و در صورت نیاز @@SPID را کنار نتیجه FILE_NAME ثبت کنید.
- مجوز مشاهده Metadata یا DMV را با حداقل سطح دسترسی لازم تنظیم کنید. در مبحث FILE_NAME
- مثالهای FILE_NAME را روی نسخه و Edition واقعی محیط هدف آزمایش کنید.
- برای SQL پویا، خروجی نامی FILE_NAME را با QUOTENAME و پارامترسازی ایمن مصرف کنید.
تصویر سوم، تفاوت روش پرخطر و Best Practice در استفاده از FILE_NAME را مقایسه میکند؛ هدف آن جلوگیری از خطاهای مربوط به FILE_NAME فقط در Context پایگاه داده جاری کار میکند. و بهبود تصمیمگیری فنی است.
سؤالات متداول اختصاصی FILE_NAME
FILE_NAME دقیقاً چه مسئلهای را در SQL Server حل میکند؟
تابع FILE_NAME شناسه یک فایل در پایگاه داده جاری را به نام منطقی همان فایل تبدیل میکند. در عمل، این تابع در گزارش مصرف فایل، تحلیل رشد، پشتیبانگیری و نگهداری برای نمایش نام قابل فهم فایل بهجای file_id کاربرد دارد. بنابراین استفاده از FILE_NAME زمانی ارزشمند است که خروجی آن در یک تصمیم فنی روشن مصرف شود، نه اینکه فقط برای نمایش عدد یا نام به کار رود.
نوع خروجی FILE_NAME چیست و چگونه باید آن را مدیریت کرد؟
نوع خروجی این ابزار چنین است: nvarchar(128)؛ برای شناسه نامعتبر یا خارج از Context جاری مقدار NULL. بهتر است پیش از تبدیل نوع، مقایسه یا درج در جدول گزارش، حالت NULL و محدوده مقدار را صریح کنترل کنید تا رفتار FILE_NAME قابل پیشبینی بماند.
آیا FILE_NAME در گزارشهای سازمانی کاربرد تجاری دارد؟
بله. در سناریوهایی مانند گزارش فضای فایل و تشخیص فایل لاگ، خروجی FILE_NAME میتواند کیفیت گزارش مدیریتی را بالا ببرد. ارزش تجاری زمانی ایجاد میشود که این داده به هشدار، ظرفیتسنجی یا کاهش زمان عیبیابی متصل شود.
استفاده از FILE_NAME در پروژههای بزرگ چه مزیتی دارد؟
در پروژه بزرگ، استانداردسازی نحوه استفاده از FILE_NAME باعث میشود تیم توسعه، DBA و پشتیبانی یک تعریف مشترک از file_id و logical file name داشته باشند. این هماهنگی خطاهای تفسیر و دوبارهکاری را کاهش میدهد.
تفاوت FILE_NAME با گزینه نزدیک آن چیست؟
FILE_NAME شناسه فایل را به نام منطقی تبدیل میکند؛ FILE_ID مسیر برعکس را انجام میدهد. انتخاب صحیح باید بر اساس حجم داده، نیاز به خروجی Set-based و سطح جزئیات گزارش انجام شود؛ یک تابع scalar همیشه جایگزین کاتالوگویو یا DMV کامل نیست.
برای طراحی اسکریپت حرفهای مبتنی بر FILE_NAME چه خدماتی لازم میشود؟
در پروژههای حساس میتوان منطق FILE_NAME را در قالب رویه مانیتورینگ، Dashboard، گزارش زمانبندیشده یا کنترل Deployment پیاده کرد. تحلیل نیاز، تست روی نسخه واقعی SQL Server و مستندسازی خروجی، بخشهای مهم خدمات مشاوره و انجام پروژه هستند.
رایجترین خطا هنگام کار با FILE_NAME چیست؟
یکی از خطاهای مهم این است که FILE_NAME فقط در Context پایگاه داده جاری کار میکند. همچنین نادیده گرفتن NULL یا Context اجرای Query میتواند نتیجهای ظاهراً معتبر ولی از نظر عملیاتی اشتباه تولید کند.
آیا فراخوانی زیاد FILE_NAME بر Performance اثر میگذارد؟
یک فراخوانی منفرد معمولاً سبک است، اما اجرای FILE_NAME روی مجموعه بسیار بزرگ یا در شرطی که برای هر ردیف محاسبه شود میتواند هزینه ایجاد کند. ابتدا ردیفها را محدود کنید و در گزارشهای وسیع، جایگزین Set-based را ارزیابی کنید.
بهترین روش استفاده از FILE_NAME چیست؟
بهترین روش این است که ورودی FILE_NAME اعتبارسنجی، نوع خروجی صریح، حالت NULL مدیریت و نتیجه همراه زمان و Context ثبت شود. همچنین باید مشخص باشد که خروجی برای نمایش، کنترل ایمنی یا تصمیم کارایی مصرف میشود.
FILE_NAME با کدام نسخههای SQL Server سازگار است؟
در نسخههای مختلف SQL Server قابل استفاده است و برای Metadata فایلهای پایگاه جاری طراحی شده است. با این حال، هنگام انتقال اسکریپت به Azure SQL یا Edition دیگر، Propertyها، مجوزهای Metadata و تفاوتهای پلتفرم را روی همان محیط آزمایش کنید.
سؤالات مصاحبه درباره FILE_NAME
در مصاحبه چگونه تفاوت ورودی و خروجی FILE_NAME را توضیح میدهید؟
پاسخ مناسب باید Syntax یعنی FILE_NAME ( file_id )، نوع خروجی و شرایط NULL را توضیح دهد و یک نمونه از گزارش فضای فایل ارائه کند.
چه زمانی بهجای FILE_NAME از کاتالوگویو یا DMV استفاده میکنید؟
وقتی گزارش چندین ردیف و چند Property نیاز دارد، روش Set-based معمولاً مناسبتر است؛ FILE_NAME برای تبدیل یا بررسی هدفمند یک مقدار بسیار خواناست.
چگونه نتیجه نامعتبر FILE_NAME را از مقدار false یا صفر جدا میکنید؟
با بررسی صریح IS NULL، اعتبارسنجی ورودی و در صورت نیاز Join با Metadata منبع، علت نتیجه را روشن میکنم. این توضیح بهطور اختصاصی به FILE_NAME مربوط است.
چه نکته Performance درباره FILE_NAME مهم است؟
فراخوانی را پس از محدود کردن مجموعه داده انجام میدهم و از محاسبه تکراری FILE_NAME در SELECT و WHERE جلوگیری میکنم.
یک سناریوی واقعی برای FILE_NAME بیان کنید.
سناریوی مناسب میتواند خواناسازی خروجی DBCC باشد؛ در آن خروجی همراه Timestamp، نام Database و شناسه نشست ثبت میشود تا قابل پیگیری باشد.
چکلیست نهایی استفاده از FILE_NAME
- Syntax FILE_NAME و ورودیهای آن با نسخه هدف تطبیق داده شده است.
- Context پایگاه داده یا Instance برای FILE_NAME روشن است.
- مجوز لازم برای Metadata یا DMV بررسی شده است. در مبحث FILE_NAME
- NULL، مقدار نامعتبر و حالت مرزی FILE_NAME تست شده است.
- نمونه خروجی با نوع داده واقعی مقایسه شده است. در مبحث FILE_NAME
- در Query بزرگ، هزینه فراخوانی تکراری FILE_NAME اندازهگیری شده است.
- جایگزین Set-based برای گزارش انبوه ارزیابی شده است. در مبحث FILE_NAME
- نتیجه نهایی همراه Timestamp و توضیح عملیاتی ثبت میشود. در مبحث FILE_NAME
جمعبندی آموزش FILE_NAME
FILE_NAME ابزاری کوچک اما مؤثر برای در گزارش مصرف فایل، تحلیل رشد، پشتیبانگیری و نگهداری برای نمایش نام قابل فهم فایل بهجای file_id کاربرد دارد. است. استفاده حرفهای از آن به اعتبارسنجی ورودی، تفسیر نوع خروجی، کنترل NULL و انتخاب Scope مناسب وابسته است.
پس از تسلط بر FILE_NAME، برای مقایسه آن با سایر ابزارهای این مجموعه به مقاله مادر توابع کمکی Performance و Metadata در SQL Server بازگردید.
خدمات برنامهنویسی و پایگاه داده
برنامهنویسی در اصفهان
قبول سفارشهای برنامهنویسی و پایگاه داده: 09131253620
انجام پروژههای برنامهنویسی، آموزش برنامهنویسی و آموزش پایگاه داده SQL Server با رویکرد حرفهای، مستند و قابل توسعه انجام میشود.
مجموعهای معتبر با سابقه فعالیت حرفهای از سال ۱۳۷۵ شمسی
از سال ۱۳۷۵ شمسی تاکنون در زمینه طراحی و اجرای پروژههای برنامهنویسی، پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری فعالیت میکنیم.
برای سفارش پروژههای برنامهنویسی و پایگاه داده، سیستمهای تحت وب، وبسایت و راهکارهای نرمافزاری جدید، با شماره تلفن همراه 09131253620 تماس حاصل فرمایید.
ایتا، واتساپ و تماس مستقیم: +989131253620
تماس با ما