نصب و راه اندازی SQL Server به واسطه وجود Wizard Installation توسط مایکروسافت در این سالها بسیار آسان شده است. به صورت پایه ای چند عملیات باید قبل و بعد از نصب SQL Server بر روی سیستم سخت افزاری و تنظیمات SQL Server توسط مدیران پایگاه داده انجام شود تا از نبود اشکالات پایه ای اطمینان حاصل نمایند. بر اساس تجربه کاری بنده برخی از مشکلات اساسی SQL Server از انجام ندادن این عملیات قبل و بعد از نصب و راه اندازی است.
هیچ وقت این اشتباهات را انجام ندهید. اشتباهات جدید دیگری هستند….
اشتباه ۱: نصب و راه اندازی SQL Server بدون انجام تست های سخت افزاری و نرم افزاری بر روی دیسک سخت.
اصولا مدیران پایگاه داده باید سیستم سخت افزاری اعم از دیسک سخت و قدرت پردازنده را برای استفاده در محیط SQL Server ارزیابی کنند و این ارزیابی باید دقیقأ به صورت باشد که SQL Server از این دو منابع استفاده می کند.
اشتباه ۲: استفاده از تنظیمات پیشفرض در SQL Server.
مدیران پایگاه داده در همه حال از تنظیمات پیشفرض در SQL Server استفاده میکنند. همیشه به یاد داشته باشید که تنظیمات در هر محیط سخت افزاری و طرز استفاده از SQL Server متفاوت است.
اشتباه ۳: استفاده از Primary Filegroup در پایگاه های داده
مدیران پایگاه داده اصولا باید تمامی داده های کاربران را از داده های سیستمی جدا کنند. این عمل چند فواید به همراه دارد.
اشتباه ۴: قرار دادن فایل داده و تراکنش در یک درایو.
قرار دادن این دو فایل بر کاهش سرعت تراکنش و استفاده از منابع سیستم تأثیر بسیاری دارد.
اشتباه ۵: کم حجم کردن فایل تراکنش.
این بدترین عملی است که یک مدیر پایگاه داده می تواند انجام دهد به این صورت که اول Recovery Model را به Simple تغییر داده و بعد فایل تراکنش را کاهش داده و بعد Recovery Model را به Full تغییر داده و در آخر بدون گرفتن Backup پایگاه داده را به امید خدا رها کند. این عمل زنجیره تراکنش را در پایگاه داده از بین میبرد و باعث می شود که در هنگام اختلال و خرابی دیگر نتوانیم داده ها را تا زمان قبل از خرابی بازیابی کنیم.
اشتباه ۶: فعال سازی Auto_Close در پایگاه داده
این تنظیمات استفاده از دیسک سخت را افزایش داده و سرعت کلی سیستم را پایین می آورد.
اشتباه ۷: استفاده و فعال سازی Auto_Growth در پایگاه داده.
این تنظیمات باعث میشود که فایل تراکنش به صورت اصولی و مرتب ساخته نشود.
اشتباه ۸: گرفتن فایل پشتیبان پایگاه داده بدون تست کردن.
گرفتن فایل پشتیبان بر اساس RTO و RPO به تصویب رسیده از طرف مدیریت سازمان بسیار کار پسندیده و عالی است اما در خیلی از موارد مدیران پایگاه داده فایل پشتیبان را تست نکرده و در هنگام بازیابی بعد از اختلال یا خرابی به خطا هایی همچون «فایل پشتیبان خراب است» برخورد می کنند که دیگر برای دانستن این موضوع خیلی دیر است.
متخصص پایگاه داده SQL Server دارای مدارک معتبر مایکروسافت از قبیلMicrosoft Certified Master: SQL Server 2008 و Microsoft Certified Solutions Master: Charter - Data Platform. من در گروههای کاربران SQL Server در کشور مالزی و سنگاپور به صورت فعال صحبت و آموزش می دهم.
سلام مقاله بسیار خوبی بود ولی بخشید نقد میکنم ولی فقط جهت بهتر شدن مقالات هست اونم اینکه ای کاش یه کم کمتر کلی گویی می فرمدین و بیشتر مسائل را باز می فرمودین
مجتبی شهریور: باز کردن مسایلی از این قبیل در مقاله نمی گنجه. چون توضیحات تمام اشتباهات باید در قالب یک دوره آموزشی باشد.
تورج عزیزی:
اصولا در حال حاضر ما دو شرکت سازنده پردازنده داریم Intel و AMD. به دلیل استفاده SQL Server از دستورات منتطقی بسیار سنگین Intel اولین و بهترین پیشنهاد است. دوم اینکه قدرت پردازنده به مقدار حافظه داخلی آن باید به نسبت خوبی باشد (البته این نکته فقط برای SQL Server نیست). سوم اینکه در سالهای گذشته پردازنده ها یک قابلیت جدیدی داشتند که هر هسته در یک لحظه ۲ عدد نخ را اجرا می کرد که این در SQL Server 2005 و SQL Server 2008 باعث بروز Deadlock می شد. که در حال حاضر برطرف شده است.
بابت مقاله ی خوبتون همانند سایر دوستان از شما تشکر میکنم. هرچند فقط در حد تلنگری بود تا کاربران استفاده کننده از SQL SERVER با دقت بیشتری موارد خاص را در نظر بگیرند. متاسفانه سایت شما (دراین آدرس) باز نمیشه، چنانچه کانال های ارتباطی وآموزشی دیگری از خود دارید لطفاً معرفی نموده تا کاربران داخل ایران هم از تجربه و تخصص به اشتراک گذاشته شده شما دوست عزیز استفاده کنند.
با توجه به حوزه تخصصی شما، انشا… شاهد مقالات تخصصی تری در این زمینه ازتون باشیم.
ممنون از نظرتون. البته این تلنگر نه بلکه یک سیلی بود 🙂 به امید خدا وقتی برگشتم ایران یک روز در مورد این موارد گپ و گفتوگو می کنیم البته باید ببینیم آقای طاهری چی دستور می دن!
اون وبسایت خیلی وقت هست که بسته شده. من دیگه در لینکداین مطالب میگذارم.
در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File (VLF) که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.
سلام مهندس جن مقاله عالی بود ایشالا در آینده کمی بیشتر در مورد این چند مورد مقاله هایی که میشه نوشت رو ببینیم تا ما بتونیم تا حد امکان جلوی اشتباهات از این قبیل رو به درستی بگیریم.
مقاله فوق بیشتر یک دید کلی و در سطح کاملا ابتدایی است که به نظر من عنوان مدیران مناسب نیست. و نکته دوم اینکه قبل از نصب دیتابیس نیاز است تا کارهای زیادی بر روی خود ویندوز سرور و یا ماشین مجازی انجام گردد که شاید حتی از نوع نصب SQL هم مهم تر باشد.
سلام دوست عزیز الان محتوایی در دنیای امروز کاملا دیده می شوند که وقت خواننده را تلف نکنند و سریع مطلب را برسانند.
اگر فکر می کنید مباحث ابتدایی است خوشحال می شوم برای این موضوعات شما و سایر دوستان یک مقاله تولید کنید و در اختیار سایر کاربران قرار دهید فکر کنم بسیار شایسته باشد.
درسته. یک دید کلی داره ولی سطح ابتدایی نیست البته برای کسانی که اطلاعات کافی از SQL Server ندارند بله یک سطح بسیار ابتدایی است. نکته دوم اینکه یک سری تنظیمات در سطح ویندوز باید انجام شود که روند اختصاص حافظه و اختصاص فظای دیسک سخت رو برای SQL Server آسان کند.
خیلی خوشحال می شیم که شما توضیحات بیشتری در مورد هر یک از موارد بیان شده را ذکر کنید + تنظیمات ویندوز!
در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.
به امید خدا وقتی برگشتم ایران یک روز در مورد این موارد گپ و گفتوگو می کنیم البته از نیک آموز در خواست دارم که مکانی رو برای ما در رابطه این بحث و گفتوگو ها در نظر بگیرند.
سلام مقاله عالی بود نظر دوستان راهم دیدم به هر حال هریک از دوستان نظر خاصی دارن ولی چه بهتر بود درسایت قسمتی در نظر گرفته می شد تا دوستان راحتر باهم نظرات و دانش خود را به اشتراک بگذارند.. بازم متشکرم
ببخشید شما کل مراحلی که در بند 5 مطرح کردید ، گفتید بدترین عملی هست که یک مدیر پایگاه داده انجام می ده. من خودم همیشه قبل و بعد از تغییر RecoverModel یک BackUp می گیرم که با خوندن مطلب شما فکر کردم که کلاً این روش برای Shrink کردن LogFile اشتباه هست
خانم حجازی: در حقیقت Shrink کردن فایل تراکنش یک عمل اشتباه است به دلیل اینکه حجم فایل تراکنش دقیقا بر میگرده به مقدار RPO و اینکه فایل تراکنش درست مدیریت نشده. اصولا فایل تراکنش برای تراکنشهای بسیار بالا حجمی حدود ۲ تا ۸ گیگابایت را داشته باشه نه بیشتر. مگر اینکه….
حجازی: درسته ولی باید فایل تراکنش همانطور که گفتم به مقدار RPO مدیریت بشه و اینکه مثلا شما یک Bulk Operation دارید در این خصوص Recovery Model را به Bulk Logged تغییر داده و بعد از انجام کار به Full و بعد یک فایل پشتیبان از پایگاه داده می گیرید.
حمید عزیز جواب به جا و مناسبی دادید در تکمیل بحث در برخی مواقع اتفاق می افتاد که کاربران حجم زیادی از رکوردها را می خواهند تغییر (Inser,Update,Delete,Merge) دهند عملیات از خاندان Bulk Operation نمی باشد در این حالت باید از روش هایی استفاده کنیم که حجم لاگ رابیش از اندازه افزایش ندهد. مثلا قرار است 200 میلیون رکورد را حذف کنیم. اگر با یک دستور Delete اینکار را انجام دهید حجم لاگ به شدت افزایش پیدا می کند
مثال زیر روش خوبی برای انجام اینکار است
SET NOCOUNT ON;
DECLARE @r INT;
SET @r = 1;
WHILE @r > 0
BEGIN
BEGIN TRANSACTION;
DELETE TOP (100000) — this will change
dbo.TransactionData WHERE TransType IN (20, 23, 27);
نکته اول: البته این رو بگم که در واقعیت هیچ کسی داده ها حجیم و زیادی را با دستور Delete حذف نمی کنند.
نکته دوم:دستور Delete From با Begin Transaction Delete From تفاوت چندانی در فایل تراکنش ندارد به دلیل آنکه در هر دو دستور تمامی اطلاعات رکوردها در فایل تراکنش ذخیره می شود و بعد از دستورات Checkpoint یا backup Log فایل تراکنش دوباره قابل استفاده قرار می گیرد.
شما می توانید با دستور fn_dblog تغییرات فایل تراکنش را بعد از هر دو دستور مشاهده کنید.
امیدوارم کسی برداشت بد از نظر من نکه. بنده فقط می خواهم که دانسته هایم را با شما در اشتراک بگذارم.
بلی این دو دستور تفاوتی ندارد چون خود دستور Delete به تنهایی Autocommit Transaction است اما در برخی مواقع سناریوهایی دیده ام که داده های زیادی بنا به دلایلی از سیستم پاک می شود یا حتی Update می شود در این گونه مواقع می توان با انجام این نوع کارها تا حدودی از افزایش حجم لاگ جلوگیری کرد. (تهیه لاگ بکاپ یا Chekpoint با توجه به Recovery Model)
در تکمیل صحبت های حمید
–نظارت بر فضای لاگ فایل
DBCC SQLPERF(LOGSPACE)
GO
–مشاهده وی ال اف ها
DBCC LOGINFO
GO
–مشاهده لاگ رکوردها
SELECT * FROM fn_dblog(NULL,NULL)
GO
به تنظیمات پیش فرض اشاره کردین. مشکلی برای ما پیش اومده که شاید به نحوی به این تنظیمات مرتبط بشه اگه راهنمایی کنید ممنون می شم.
مشخصات محیط ما : windows server 2008 R2 – enterprise
sql server 2014 – sp1
Microsoft SQL Server 2014 – 12.0.4100.1 (X64)
Apr 20 2015 17:29:27
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)
و تنظیمات مربوط به استفاده از همه هسته ها هم فعال است اما از 30 هسته CPU فقط 20 تای آن کار می کند.
در گروه های مختلف طرح کردم. و اطلاعات بیشتری از سرور گرفتم به قرار زیر اما هنوز نتیجه عملی نگرفنم. لطفا راهنمایی کنید :
SELECT scheduler_id,
cpu_id,
status
FROM sys.dm_os_schedulers
WHERE status LIKE'VISIBLE%';
نتیجه اجرای این Query :
scheduler_idcpu_idstatus
00VISIBLE ONLINE
11VISIBLE ONLINE
…
1919VISIBLE ONLINE
2020VISIBLE OFFLINE
2121VISIBLE OFFLINE
…
2929VISIBLE OFFLINE
10485760VISIBLE ONLINE (DAC)
و اولین لاگ بعد از استارت sql server هم این است :
SQL Server detected 5 sockets with 6 cores per socket and 6 logical processors per socket, 30 total logical processors; using 20 logical processors based on SQL Server licensing. This is an informational message; no user action is required.
درسته به Licence مربوطه و اگر هست چه راهی با توجه به شرایط نرم افزارها در ایران پیش روم هست ؟ ممنون
بله همانطور که مشهود است مشکل از قسمت لایسنس است. در حال حاضر 10 عدد از Scheduler ها به صورت Offline هستند یعنی SQL Server هیچ گونه Thread را بر روی آن پردازنده ها اجراء نمی کند.
بلی این موضوع صحیح است. بحث لایسنس است. در قسمت SQL Server Logs هم زمانی که سرویس SQL استارت می شود. در خصوص تعداد Coreهای قابل استفاده به ازای لایسنس شما لاگی ثبت می کند ….
این به این معنی است که همه نسخ sql server 2014 enterprise موجود در ایران از همین نسخه با لایسنس های محدود هستند. (ساپورت حداکثر 20 Core CPU) یا اینکه نسخه دیگری وجود دارد که بتوانم از آن استفاده کنم ؟
و یا اینکه با تغییری روی همین نسخه بتوان Licence آنرا ارتقاء دارد؟ قطعا تعویض sql server روی سیستم های عملیاتی بسیار هزینه بر است.
البته نیازی به تغییر SQL Server نیست به این دلیل که شما فقط نیاز دارید کد لایسنس را به روز رسانی کنید و اینکه شما نمی توانید از نماینده گی های خارج از کشور خریداری کنید مگر اینکه از شرکت شما یک نماینده گی در آن کشور باشد در غیر اینصورت غیر قانونی بوده.
در ضمن در نظر داشته باشید که فقط ورژن Upgrade می شود نه Edition.
بلی تغییر را اشتباه نوشتم. باید گزبنه Upgrade را در Setup انتخاب کنیم
راستی حمید در ایران روش های ناسناخته ای برای دور زدن تحریم ها وجود دارد از اینکارهای غیر قانونی خیلی از سازمان ها انجام می دهند و حتی در داخل ایران هم از خدمات مایکروسافت استفاده می کنند. چند تا سازمان دولتی که باهشون درگیر شدم دقیقا همین کار را انجام می دهند. بدون داشتن شرکت در کشور دیگر فقط از طریق واسطه و ….
اتفاقا من هم از دقیقا این موضوع را به سازمان گوشزد کردم و دقیقا صفحه لایسنس و… را که مشاهده کردم شاخ در آوردم به نام خود سازمان و تا به حال که مشکلی نداشته است. شاید خیلی ها نتوانند این کار را انجام دهند اما واسطه و… (مثل ب.ز و امثال آن)
و جالب تر این است که چندین بار هم پشتیبانی Remote از آن طرف داشته اند و حتی در حد ارائه Hotfix و…
وقتی این گونه چیزها را می بیننم به این نتیجه رسیدم آخر الزمان نزدیک است
محمد استقامت
در مورد اشتباه چهارم : قرار دادن فایل های تراکنش و داده روی یک درایو
به احتمال زیاد منظور درایوهایی است که روی دیسک های جداگانه باشند.
حال در اکثر سازمان های بزرگ دیگر سرورها بصورت فیزیکی و جداگانه نیستند بلکه سرورهای مجازی هستند که اکثر آنها هم از SAN استفاده می کنند.
حال سوال من این است : روی درایو هایی که همه از یک SAN هستند و می دانیم که پشت همه این درایو ها یک سخت افزار واقعی است ، ایا هنوز این جداسازی می تواند مزیتی محسوب شود یا نه ؟
چون به نظرم دلیل یکی از دلایل اصلی این جداسازی دسترسی موازی با سرعت بالاست یعنی دو دیسک با هم و بصورت موازی روی داده و تراکنش کار کنند. که در حالت SAN واقعا نمی دانم چه مزیتی می تواند داشته باشد؟
هنگام استفاده از Storage باید نکات زیر را در نظر داشته باشید
1- معمولا در اکثر سازمان ها enclosureهای SAN با دیسک های فیزیکی پر شده و برای بدست آوردن ظرفیت بالا یک RAID مثل 5 استفاده می کنند و روی آن برای همه چیزی DB، VM و… LUN تعریف می کنند که در نهایت تمامی IO فیزیکی مربوط به LUN روی دیسک ها پخش شده که این مورد در برخی مواقع متاسفانه کارایی لازم به ازای DB سرور ها را نخواهد داشت
2- یکی از بهترین کارهای ممکن ایجاد RAID جداگانه به ازای Data File و Log File می باشد. در این حالت شما حداقل دو RAID جداگانه برای دیتا فایل و لاگ فایل تعریف می کند و روی آن LUN خود را ایجاد می کنید. با توجه به این که دیسک های فیزیکی هر کدام از آنها جداگانه می باشد می تواند کارایی لازم را برای شما به ارمغان آورد به دلیل این که مکانیزم دسترسی مربوط به دیتا فایل Random Access و مکانیزیم دسترسی Log File به صورت Sequential Access می باشد. در ضمن باید به این نکته هم توجه داشته باشید که قرار دادن فایل هایی که دسترسی Random Access در LUN مربوط به Log File باعث می شود که رفتار دیسک های مربوط به صورت Random Access شود و… (در خصوص مورد آخر یکی از دوستانم خوب R&D کرده و حتی با یک نرم افزار عملکرد مربوط به دیسک را زیر نظر گرفته بود که جالب بود برام)
در پاسخ به سوال شما باید بگم اگر بتوانید مورد 2 را رعایت کنید نور علی نور است در غیر این صورت ایجاد LUN روی یک RAID زیاد کارایی لازم را ارئه نخواهد داد. چون در آخر همه آنها روی تعدادی دیسک فیزیکی که تحت اختیار یک RAID خاص است ذخیره می شوند.
توجه داشته باشید که تعداد دیسک های موجود در RAID + نوع دیسک های + نوع RAID در این خصوص بی تاثیر نمی باشد.
سلام وقت بخیر
یک سوالی داشتم میخواستم بپرسم برای شیرینک کردن خودکار لاگ فایل باید چیکار کنم ؟
فول بکاپ هم به صورت خودکار گرفته می شود
البته بدون اینکه به دیتابیس آسیبی برسد
سلام دوست عزیز
1- اگر می خواهید که Log Backup داشته باشید می توانید لاگ بکاپ بگیرید (با جاب) در این حالت لاگ فایل شما عموما حجم ش خیلی زیاد رشد نخواهد کرد
2- اگر لزومی به داشتن لاگ بکاپ ندارید می توانید Recovery Model بانک را در حالت Simple قرار دهید
پیشنهاد من به شما استفاده از حالت اول است در این حالت می توانید مزایای Log Backup را بدست آورید
سلام جناب آقای طاهری
بنده یک سیستم حسابداری دارم و میخوام رو حالت cloud اجرا کنم و تمام دیتا های تمام شرکتها در یک دیتابیس ثبت شوند ولی مشکل تو backup و restore کردن هر شرکت به صورت مجزاست آیا این امکان وجود داده که داده های هر شرکت رو جداگانه backup گرفت
سلام
راحت ترین راه
ایجاد دیتابیس جدید – استفاده از دستور Select into برای درج جدول و دیتاهای مورد نیاز در اون دیتابیس جدید است بعدش تهیه بکاپ از اون دیتابیس
سلام خسته نباشید
من یه سوال در رابطه با فایل گروپ ها داشتم
اینکه من الان یک دیتابیس دارم که حجمش 5 گیگه و فقط روی mdf ذخیره میشده دیتاها, الان من میخوام روی یک درایو ssd یک فایل گروپ دیگه بسازم که دیتاها برن اونجا و حجم mdf زیاد تر نشه.
حالا سوال اینه که الان فقط برم فایل گروپ جدید رو primary کنم یا کار دیگه هم باید بکنم؟ و اینکه اگه بخوام همه فایل گروپ ها باهم دیگه رشد کنن چیکار کنم؟
بسیار ممنون
بازسازی ساختار دیتابیس ها هم تاثیر گذار است روی کار شما
یک فایل گروه برای Primary = قرار گرفتن اشیاء سیستمی
یک فایل گروه برای جدوال = همون کلاستر ایندکس ها
یک فایل گروه برای ایندکس های Non Clustered
یک فایل گروه هم برای BLOB
اگر این ها هر کدام چند دیتا فایل داشته باشند می توانید از Trace Flag شماره 1117 کمک بگیرید که البته بسته به نسخه SQL Server با دستور هم قابل راه اندازی است
تمامی این موارد و کلی نکته دیگر در دوره Performance & Tuning به طور مفصل بررسی شده است
درود بر شما
دوست عزیز از چه نسخه ای از ssms استفاده می کنید؟ و اینکه بعد از باز شدن ssms باید به محیط sql server متصل شوید. برای اتصال به sql با استفاده از پنجره Connect to Server اقدام نمایید.
با تشکر
درود وقت بخیر
این مورد هیچ مانعی ندارد. حتی شما می توانید برنامهsql را در یک سرور دریک مکان دیگر نصب کنید زیرا رابط این دو نرم افزار از طریق دریافت ip است.
اما توصیه میکنیم که در صورت انتخاب دو درایو جداگانه، محل ذخیره را پیش فرض نگذارید.
درود و وقت بخیر
من مشکلی دارم که هر موقع یک کوئری نسبتا سنگین در sql 2016 ران می کنم میزان درصد استفاده از رم بالا می رود و هنگامی که کوئری تمام میشود دیگه میزان رم استفاده شده پایین نمیاد .
می خواستم ببینم که علیت این موضوع چی می تونه باشه و ربطی به چی می تونه داشته باشد
این اتفاق کاملا طبیعی است و از خاصیت های SQL Server می باشد.
اگر این اصطلاح رو شنیده باشید.(SQL Server رم خور می باشد!!!)
برای این SQL Server بتواند سرعت واکشی اطلاعات رو بالا ببرد و سریع تر به کاربر پاسخ بدهد با توجه به میزان RAM که در اختیار اش قرار می گیرد. دیتا (Page) ها را از سطح دیسک به یک بخشی از RAM به نام Buffer Pool منتقل می کند.
58 دیدگاه
تورج عزیزی
سلام
مسعود طاهری
تورج جان سلام
فرشید علی اکبری
سلام
مسعود طاهری
حمید جان مقاله شما عالی بود
مجتبی شهریور
سلام
مقاله بسیار خوبی بود ولی بخشید نقد میکنم ولی فقط جهت بهتر شدن مقالات هست اونم اینکه ای کاش یه کم کمتر کلی گویی می فرمدین و بیشتر مسائل را باز می فرمودین
Hamid J. Fard
مسعود طاهری: ممنون.
فرشید علی اکبری
Hamid J. Fard
ممنون از نظرتون. البته این تلنگر نه بلکه یک سیلی بود 🙂 به امید خدا وقتی برگشتم ایران یک روز در مورد این موارد گپ و گفتوگو می کنیم البته باید ببینیم آقای طاهری چی دستور می دن!
علی رحیمیان
سلام.
از بابت مقاله ممنون. از این به بعد به نکات فوق توجه بیشتری می کنم.
اگر امکان دارد مورد 7 رو بیشتر توضیح دهید.
ممنون.
Hamid J. Fard
در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File (VLF) که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.
علی رحیمیان
ممنون از توضیحات خوبتون.
موفق باشد.
ابراهیم رعیت
سلام مهندس جن مقاله عالی بود
ایشالا در آینده کمی بیشتر در مورد این چند مورد مقاله هایی که میشه نوشت رو ببینیم تا ما بتونیم تا حد امکان جلوی اشتباهات از این قبیل رو به درستی بگیریم.
سیدمهدی معصومی
با سلام
فرید طاهری
سلام دوست عزیز
الان محتوایی در دنیای امروز کاملا دیده می شوند که وقت خواننده را تلف نکنند و سریع مطلب را برسانند.
اگر فکر می کنید مباحث ابتدایی است خوشحال می شوم برای این موضوعات شما و سایر دوستان یک مقاله تولید کنید و در اختیار سایر کاربران قرار دهید فکر کنم بسیار شایسته باشد.
Hamid J. Fard
درسته. یک دید کلی داره ولی سطح ابتدایی نیست البته برای کسانی که اطلاعات کافی از SQL Server ندارند بله یک سطح بسیار ابتدایی است. نکته دوم اینکه یک سری تنظیمات در سطح ویندوز باید انجام شود که روند اختصاص حافظه و اختصاص فظای دیسک سخت رو برای SQL Server آسان کند.
علی عبدیان
با سلام ممنون مقاله خوبی بود
فقط گزینه 7 رو یخورده توضیح دهید ممنون میشم
Hamid J. Fard
در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.
Hamid J. Fard
به امید خدا وقتی برگشتم ایران یک روز در مورد این موارد گپ و گفتوگو می کنیم البته از نیک آموز در خواست دارم که مکانی رو برای ما در رابطه این بحث و گفتوگو ها در نظر بگیرند.
فرید طاهری
سلام. در این مورد برای شما ایمیلی ارسال خواهم کرد.
با احترام
رقيه حجازی
سلام
به نکات جالبی اشاره کردید. اگه میشه در مورد نکته 5 بگید که چطور حجم فایل مربوط به تراکنش رو طوری کم کرد که اون اتفاقاتی که گفتید نیفته؟
Hamid J. Fard
خانم حجازی: خب وقتی بعد از تغییر Recovery Modelبه Full یک فایل پشتیبان بگیرید این مشکل حل میشه. جواب توی نکته نهان بود.
تورج عزیزی
Great article!
امیدوارم دوستان عزیزی که در این مباحث شرکت می کنند همیشه در سایت حاضر باشند!
ساناز احمدی
سلام
مقاله عالی بود نظر دوستان راهم دیدم به هر حال هریک از دوستان نظر خاصی دارن ولی چه بهتر بود درسایت قسمتی در نظر گرفته می شد تا دوستان راحتر باهم نظرات و دانش خود را به اشتراک بگذارند..
بازم متشکرم
حجازی
ببخشید شما کل مراحلی که در بند 5 مطرح کردید ، گفتید بدترین عملی هست که یک مدیر پایگاه داده انجام می ده. من خودم همیشه قبل و بعد از تغییر RecoverModel یک BackUp می گیرم که با خوندن مطلب شما فکر کردم که کلاً این روش برای Shrink کردن LogFile اشتباه هست
Hamid J. Fard
خانم حجازی: در حقیقت Shrink کردن فایل تراکنش یک عمل اشتباه است به دلیل اینکه حجم فایل تراکنش دقیقا بر میگرده به مقدار RPO و اینکه فایل تراکنش درست مدیریت نشده. اصولا فایل تراکنش برای تراکنشهای بسیار بالا حجمی حدود ۲ تا ۸ گیگابایت را داشته باشه نه بیشتر. مگر اینکه….
حجازی
ببخشید اینقدر سوال می کنم
بهر حال یکسری عملیات هست که باعث افزایش حجم فایل تراکنش میشه که بعدش مجبور به این کار میشیم. اینو بایستی چیکار کرد؟
Hamid J. Fard
حجازی: درسته ولی باید فایل تراکنش همانطور که گفتم به مقدار RPO مدیریت بشه و اینکه مثلا شما یک Bulk Operation دارید در این خصوص Recovery Model را به Bulk Logged تغییر داده و بعد از انجام کار به Full و بعد یک فایل پشتیبان از پایگاه داده می گیرید.
مسعود طاهری
حمید جان+ خانم حجازی سلام
Hamid J. Fard
مسعود عزیز و خانم حجازی:
نکته اول: البته این رو بگم که در واقعیت هیچ کسی داده ها حجیم و زیادی را با دستور Delete حذف نمی کنند.
نکته دوم:دستور Delete From با Begin Transaction Delete From تفاوت چندانی در فایل تراکنش ندارد به دلیل آنکه در هر دو دستور تمامی اطلاعات رکوردها در فایل تراکنش ذخیره می شود و بعد از دستورات Checkpoint یا backup Log فایل تراکنش دوباره قابل استفاده قرار می گیرد.
شما می توانید با دستور fn_dblog تغییرات فایل تراکنش را بعد از هر دو دستور مشاهده کنید.
امیدوارم کسی برداشت بد از نظر من نکه. بنده فقط می خواهم که دانسته هایم را با شما در اشتراک بگذارم.
مسعود طاهری
بلی این دو دستور تفاوتی ندارد چون خود دستور Delete به تنهایی Autocommit Transaction است اما در برخی مواقع سناریوهایی دیده ام که داده های زیادی بنا به دلایلی از سیستم پاک می شود یا حتی Update می شود در این گونه مواقع می توان با انجام این نوع کارها تا حدودی از افزایش حجم لاگ جلوگیری کرد. (تهیه لاگ بکاپ یا Chekpoint با توجه به Recovery Model)
در تکمیل صحبت های حمید
–نظارت بر فضای لاگ فایل
DBCC SQLPERF(LOGSPACE)
GO
–مشاهده وی ال اف ها
DBCC LOGINFO
GO
–مشاهده لاگ رکوردها
SELECT * FROM fn_dblog(NULL,NULL)
GO
سیامک محمدی
موارد زیر هم میتونن جزو Bad practice ها باشن:
محمد استقامت
سلام
و تنظیمات مربوط به استفاده از همه هسته ها هم فعال است اما از 30 هسته CPU فقط 20 تای آن کار می کند.
Hamid J. Fard
مسعود طاهری
سلام بر حمید عزیز و آقای استقامت
محمد استقامت
سلام بر اساتید عزیز
مسعود طاهری
تهیه نسخه
Hamid J. Fard
مسعود طاهری
بلی تغییر را اشتباه نوشتم. باید گزبنه Upgrade را در Setup انتخاب کنیم
Hamid J. Fard
درسته ولی لایسنس به نام آن شرکت واسطه ثبت شده و برای استفاده در ایران نیست و اینکه مایکروسافت می تواند از آن شرکت واسط شکایت کند
مسعود طاهری
اتفاقا من هم از دقیقا این موضوع را به سازمان گوشزد کردم و دقیقا صفحه لایسنس و… را که مشاهده کردم شاخ در آوردم به نام خود سازمان و تا به حال که مشکلی نداشته است. شاید خیلی ها نتوانند این کار را انجام دهند اما واسطه و… (مثل ب.ز و امثال آن)
مسعود طاهری
و جالب تر این است که چندین بار هم پشتیبانی Remote از آن طرف داشته اند و حتی در حد ارائه Hotfix و…
محمد استقامت
در مورد اشتباه چهارم : قرار دادن فایل های تراکنش و داده روی یک درایو
مسعود طاهری
سلام
محمد استقامت
بسیار سپاس گذارم. توضیح کاملی بود.
جواد
سلام وقت بخیر
یک سوالی داشتم میخواستم بپرسم برای شیرینک کردن خودکار لاگ فایل باید چیکار کنم ؟
فول بکاپ هم به صورت خودکار گرفته می شود
البته بدون اینکه به دیتابیس آسیبی برسد
مسعود طاهری
سلام دوست عزیز
1- اگر می خواهید که Log Backup داشته باشید می توانید لاگ بکاپ بگیرید (با جاب) در این حالت لاگ فایل شما عموما حجم ش خیلی زیاد رشد نخواهد کرد
2- اگر لزومی به داشتن لاگ بکاپ ندارید می توانید Recovery Model بانک را در حالت Simple قرار دهید
پیشنهاد من به شما استفاده از حالت اول است در این حالت می توانید مزایای Log Backup را بدست آورید
برای بدست آوردن اطلاعات بیشتر به این لینک مراجعه کنید
https://nikamooz.com/product/database-maintenance-sql-server/
رضا
سلام جناب آقای طاهری
بنده یک سیستم حسابداری دارم و میخوام رو حالت cloud اجرا کنم و تمام دیتا های تمام شرکتها در یک دیتابیس ثبت شوند ولی مشکل تو backup و restore کردن هر شرکت به صورت مجزاست آیا این امکان وجود داده که داده های هر شرکت رو جداگانه backup گرفت
مسعود طاهری
سلام
راحت ترین راه
ایجاد دیتابیس جدید – استفاده از دستور Select into برای درج جدول و دیتاهای مورد نیاز در اون دیتابیس جدید است بعدش تهیه بکاپ از اون دیتابیس
موفق باشید
شایان میرسلطانی
سلام خسته نباشید
من یه سوال در رابطه با فایل گروپ ها داشتم
اینکه من الان یک دیتابیس دارم که حجمش 5 گیگه و فقط روی mdf ذخیره میشده دیتاها, الان من میخوام روی یک درایو ssd یک فایل گروپ دیگه بسازم که دیتاها برن اونجا و حجم mdf زیاد تر نشه.
حالا سوال اینه که الان فقط برم فایل گروپ جدید رو primary کنم یا کار دیگه هم باید بکنم؟ و اینکه اگه بخوام همه فایل گروپ ها باهم دیگه رشد کنن چیکار کنم؟
بسیار ممنون
مسعود طاهری
بازسازی ساختار دیتابیس ها هم تاثیر گذار است روی کار شما
یک فایل گروه برای Primary = قرار گرفتن اشیاء سیستمی
یک فایل گروه برای جدوال = همون کلاستر ایندکس ها
یک فایل گروه برای ایندکس های Non Clustered
یک فایل گروه هم برای BLOB
اگر این ها هر کدام چند دیتا فایل داشته باشند می توانید از Trace Flag شماره 1117 کمک بگیرید که البته بسته به نسخه SQL Server با دستور هم قابل راه اندازی است
تمامی این موارد و کلی نکته دیگر در دوره Performance & Tuning به طور مفصل بررسی شده است
پوریا
سلام من SQL server management studio رو باز میکنم صفحه اول میاد ولی بعدش باز نمیشه باید uninstall کنم دوباره نصب کنم تا کار کنه چیکار کنم درست شه؟
آرزو محمدزاده
درود بر شما
دوست عزیز از چه نسخه ای از ssms استفاده می کنید؟ و اینکه بعد از باز شدن ssms باید به محیط sql server متصل شوید. برای اتصال به sql با استفاده از پنجره Connect to Server اقدام نمایید.
با تشکر
ذکایی
سلام خسته نباشید.
من یه سوالی داشتم.
میشه نرم افزار اس کیوال سرور غیر از درایو C نصب کرد و نرم افزار ویژال استودیو تو خودت درایو C?
آرزو محمدزاده
درود وقت بخیر
این مورد هیچ مانعی ندارد. حتی شما می توانید برنامهsql را در یک سرور دریک مکان دیگر نصب کنید زیرا رابط این دو نرم افزار از طریق دریافت ip است.
اما توصیه میکنیم که در صورت انتخاب دو درایو جداگانه، محل ذخیره را پیش فرض نگذارید.
سپاس از همراهی شما
علی
درود و وقت بخیر
من مشکلی دارم که هر موقع یک کوئری نسبتا سنگین در sql 2016 ران می کنم میزان درصد استفاده از رم بالا می رود و هنگامی که کوئری تمام میشود دیگه میزان رم استفاده شده پایین نمیاد .
می خواستم ببینم که علیت این موضوع چی می تونه باشه و ربطی به چی می تونه داشته باشد
آرزو محمدزاده
با سلام
این اتفاق کاملا طبیعی است و از خاصیت های SQL Server می باشد.
اگر این اصطلاح رو شنیده باشید.(SQL Server رم خور می باشد!!!)
برای این SQL Server بتواند سرعت واکشی اطلاعات رو بالا ببرد و سریع تر به کاربر پاسخ بدهد با توجه به میزان RAM که در اختیار اش قرار می گیرد. دیتا (Page) ها را از سطح دیسک به یک بخشی از RAM به نام Buffer Pool منتقل می کند.
تشکر از همراهی شما
احسان
سلام
با فایل sqldump1000 چکار کنم
کلی از فضای هارد رو اشغال می کنه و مدام بیشتر میشه.هر نیم ساعت تقریبا نیم گیگ فضا اشغال می کنه
آرزو محمدزاده
درود بر شما
این سوال مربوط به DataBase MySQL می باشد.