اندازه و محل قرار فیزیکی از tempdb ده می تواند عملکرد سیستم یا به اصطلاح performance سیستم تاثیر داشته باشد.
به عنوان مثال، اگر اندازه Tempdb بیش از حد کوچک باشد بخشی از بار سیستم پردازش ممکن است صرف autogrowing شود که هربار درخواست فضا زمان لازم دارد.
فایل های TempDB را به چند فایل مساوی تقسیم کنید تا از حد اکثز پهنای باند storage خود استفاده کنید.
توصیه میشود به تعداد هسته های cpu تا 4 تا فایل بسازید اگر بالای 8 تا هسته داشتید تعداد فایل برابر تعداد هسته ها تقسیم بر 2 باشد.
در زمان نصب SQL Server 2016 شما می توانید تعداد فایل های Tempdb را مشخص کنید.
به طور پیش فرض مقدار آن 8 است یا به اندازه تعداد هسته های پردازنده شما می باشد.که می تواند تا تعداد هسته های پردازنده افزایش داد.
داشتن چندین فایل می تواند کمک کند که سیستم منتظر IO نماند و نیاز به آزاد کردن Buffer Pool بزرگ و حجیم نباشد الگوهای IO اساسا تصادفی منجر شود که استخر بافر نیاز به آزاد کردن فضای طریق lazywriter (ایست های بازرسی از Tempdb نمی صفحات داده خیط و پیت کردن) برای سیستم های با استخر بافر بسیار بزرگ نیست اما * تعداد زیادی از داده ها * از Tempdb. اگر زیر سیستم I / O می تواند بار در سراسر چندین فایل رسیدگی نمی کند، آن را شروع به کم کردن سرعت.
recovery mode باید در حالت simple باشد.
با توجه به اینکه اطلاعات موجود در TempDB مهم نیستند دلیل ندارد که حالت Full قرار داده شود و Log را بی مورد اشغال کند .
بهتر است فایل ها بر روی سریعترین دیسک باشد ترجیحا raid صفر .
در TempDB سرعت برای ما مهم است و خطر از دست رفتن دیتا مارو تهدید نمیکند چون دیتای با اهمیتی در این دیتابیس وجود ندارد بنابر این بهتر است فایل ها روی دیسکی که بصورت Raid صفر بسته شده اند ایجاد شوند.
tempDB با شرینک خالی نمیشود و تنها راه خالی کردن آن restart کردن sql server است
[sql]
SELECT name AS FileName,
size*1.0/128 AS FileSizeinMB,CASE max_size
WHEN 0 THEN ‘Autogrowth is off.’
WHEN -1 THEN ‘Autogrowth is on.’
ELSE ‘Log file will grow to a maximum size of 2 TB.’
END,
growth AS ‘GrowthValue’,
‘GrowthIncrement’ =
CASE
WHEN growth = 0 THEN ‘Size is fixed and will not grow.’
WHEN growth > 0 AND is_percent_growth = 0
THEN ‘Growth value is in 8-KB pages.’
ELSE ‘Growth value is a percentage.’
END
;FROM tempdb.sys.database_files
GO
[/sql]
منبع: آموزش برنامه نویسی نیک آموز
13 دیدگاه
مسعود طاهری
سلام قاسم جان
قاسم گل میری
سپاسگزارم
مجتبی شهریور
سلام
جناب مهندس مقالتون بسیار خوب بود
غلامحسین عبادی
باسلام
محمد
سلام آقای گل میری عزیز
تشکر از مقاله ای که ارائه دادید.
ابتدای امر باید متذکر بشم که عنوان مقاله ی شما با محتوای مقاله از لحاظ فنی فاصله زیادی دارد.
چون بحث بهینه سازی tempDB فقط این یک مورد نیست بلکه مسائل بسیار دیگری در آن دخیل می باشند.
مانند Latch Contention
بررسی GAM,SGAM,PFS
نحوه سایز دهی به دیتابیس TempDB
تاثیر Aggregation Function ها بر TempDB
مانیتورینگ و بحث مربوط به Wait ها
و…
بهتر بودمقاله رو یا بصورت سری ارائه می کردید یا اینکه عنوان رو تغییر میدادید.
در ضمن پاراگراف پایین تصویر دارای اشکلات ترجمه ای و همینطور نوشتاری است لطفا آن را اصلاح بفرمایید.
با سپاس
قاسم گل میری
سلام
فرشید علی اکبری
سلام
حسین وثوقی
خیلی ممنون
زهرا غیاثوند محمدخانی
سلام
مقالتون خیلی خوب بود.
moahammadbidgoli
با توجه به اینکه اطلاعات tempdb مهم نیست و با ریست کردن پاک می شود درصورتی که در سرور تان رم به اندازه کافی دارین میتونی با استفاده از نرم افزارهایی که رم را به صورت یک هارد در اختیار کاربر میگذارند(مثل ramdisk) کل tempdb رو به داخل رم ببرین و افزایش کارایی را داشته باشین
فقط یه مورد فنی که ممکنه پیش بیاد چون درایو های مجازی ساخته شده توسط این نرمافزار ها با ریست شدن پاک میشوند و مجدد هنگام بالا امدن سیستم عامل ساخته میشوند باید این فایل های دیتابیس در روت این درایو ریخته بشه و داخل پوشه ساخته نشود چون عملا بعد از راه اندازی ،ان پوشه وجود خارجی نخواهد داشت و اس کیو ال استارت نخواهد شد
حسن ضرابی
با سلام و خسته نباشید خدمت شما
از بابت این مقاله مفید بسیار ممنونم البته یک نکته ای را بگم بعضی از کاربران سایت تجربیات خودشونو در اختیار کاربران دیگر قرار می دهند این خیلی خوب هست اما کسی که این مقاله یا مقاله هایی را به این شکل می خواند باید ایده را بگیرد و خودش به دنبال کامل بودن مطالب باشد چون در هیچ سایتی در مورد یک موضوع به صورت کامل توضیح نمی دهند آنهم به صورت رایگان هم باشد چون انقدر sql server وسیع هست که شاید بعضی از کاربران که می خواهند مقاله بنویسند از آن جزییات اطلاع نداشته باشند به نظر من بهتر است کاربران ایده را بگیرند و بعد مطالب خود را تکمیل کنند.
با تشکر
بنیامین
سلام و خسته نباشید
ممنون در خصوص مقاله خوبتان ، سوال که دارم اینه که حجم کل دیتابیس temp رو معمولا چقد باید در نظر گرفت؟؟ با توجه به ایمکه شرایط کاری رو بسنجم و حجم دیتا ها و… آیا 10 گیگ مثلا حجم مناسبیه؟؟ یا نه ؟
مسعود طاهری
افزایش دیتا فایل ها به نسبت CPU Core
در نظر گرفتن سایز یکسان به ازای هر دیتا فایل (مثال 512 مگ یا 1024 مگ)
در نظر گرفتن رشد ثابت و نه به صورت درصدی (مثال 512 مگ یا 1024 مگ)
فعال کردن Trace Flag شماره 1117و1118 در نسخه های قبل از SQL Server 2016