هشت اشتباه بزرگ در SQL Server!

درباره نویسنده

Hamid J. Fard

Hamid J. Fard

متخصص پایگاه داده SQL Server دارای مدارک معتبر مایکروسافت از قبیلMicrosoft Certified Master: SQL Server 2008 و Microsoft Certified Solutions Master: Charter - Data Platform. من در گروههای کاربران SQL Server در کشور مالزی و سنگاپور به صورت فعال صحبت و آموزش می دهم.

52 دیدگاه

  1. تورج عزیزی

    تورج عزیزی

     سلام

    با تشکر از مقاله مفیدتون،
    اگر امکانش هست بگید چرا برخی CPU های خاص برای SQL Server پیشنهاد می شود؟
    پاسخ
  2. مسعود طاهری

    مسعود طاهری

     تورج جان سلام

    این کتاب دید خیلی خوبی در زمینه سخت افزار برای حوزه SQL Server به شما می دهد. مطالعه اون را به همه دوستان توصیه می کنم
    پاسخ
    1. فرشید علی اکبری

      فرشید علی اکبری

       سلام

      بابت معرفی این کتاب ارزشمند بسیار ممنون از شما.
      موفق باشید.
      پاسخ
  3. مسعود طاهری

    مسعود طاهری

     حمید جان مقاله شما عالی بود

    در صورت امکان در آینده هر کدام از این موضوعات را در یک مقاله جداگانه ارائه دهید تا دوستان بتوانند استفاده کنند
    پاسخ
  4. مجتبی شهریور

    مجتبی شهریور

    سلام
    مقاله بسیار خوبی بود ولی بخشید نقد میکنم ولی فقط جهت بهتر شدن مقالات هست اونم اینکه ای کاش یه کم کمتر کلی گویی می فرمدین و بیشتر مسائل را باز می فرمودین

    پاسخ
  5. Hamid J. Fard

    Hamid J. Fard

     مسعود طاهری: ممنون.

    مجتبی شهریور: باز کردن مسایلی از این قبیل در مقاله نمی گنجه. چون توضیحات تمام اشتباهات باید در قالب یک دوره آموزشی باشد. 
    تورج عزیزی:
    اصولا در حال حاضر ما دو شرکت سازنده پردازنده داریم Intel و AMD. به دلیل استفاده SQL Server از دستورات منتطقی بسیار سنگین Intel اولین و بهترین پیشنهاد است. دوم اینکه قدرت پردازنده به مقدار حافظه داخلی آن باید به نسبت خوبی باشد (البته این نکته فقط برای SQL Server نیست). سوم اینکه در سالهای گذشته پردازنده ها یک قابلیت جدیدی داشتند که هر هسته در یک لحظه ۲ عدد نخ را اجرا می کرد که این در SQL Server 2005  و  SQL Server 2008 باعث بروز Deadlock می شد. که در حال حاضر برطرف شده است.
    متاسفم اگر غلط املایی دارم!
    پاسخ
    1. فرشید علی اکبری

      فرشید علی اکبری

      جناب مهندس فرد سلام
      وقت شما بخیر.
      بابت مقاله ی خوبتون همانند سایر دوستان از شما تشکر میکنم. هرچند فقط در حد تلنگری بود تا کاربران استفاده کننده از SQL SERVER با دقت بیشتری موارد خاص را در نظر بگیرند. متاسفانه سایت شما (دراین آدرس) باز نمیشه، چنانچه کانال های ارتباطی وآموزشی دیگری از خود دارید لطفاً معرفی نموده تا کاربران داخل ایران هم از تجربه و تخصص به اشتراک گذاشته شده شما دوست عزیز استفاده کنند.
      با توجه به حوزه تخصصی شما، انشا… شاهد مقالات تخصصی تری در این زمینه ازتون باشیم.
      با آرزوی شادی و شادکامی برای شما دوست عزیز.
      پاسخ
      1. Hamid J. Fard

        Hamid J. Fard

         ممنون از نظرتون. البته این تلنگر نه بلکه یک سیلی بود 🙂 به امید خدا وقتی برگشتم ایران یک روز در مورد این موارد گپ و گفتوگو می کنیم البته باید ببینیم آقای طاهری چی دستور می دن!

        اون وبسایت خیلی وقت هست که بسته شده. من دیگه در لینکداین مطالب میگذارم. 
  6. علی رحیمیان

    علی رحیمیان

    سلام.
    از بابت مقاله ممنون. از این به بعد به نکات فوق توجه بیشتری می کنم.
    اگر امکان دارد مورد 7 رو بیشتر توضیح دهید.
    ممنون.

    پاسخ
    1. Hamid J. Fard

      Hamid J. Fard

       در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File (VLF) که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.

      پاسخ
      1. علی رحیمیان

        علی رحیمیان

        ممنون از توضیحات خوبتون.
        موفق باشد.

  7. ابراهیم

    ابراهیم

    سلام مهندس جن مقاله عالی بود
    ایشالا در آینده کمی بیشتر در مورد این چند مورد مقاله هایی که میشه نوشت رو ببینیم تا ما بتونیم تا حد امکان جلوی اشتباهات از این قبیل رو به درستی بگیریم.

    پاسخ
  8. سیدمهدی معصومی

    سیدمهدی معصومی

     با سلام

    مقاله فوق بیشتر یک دید کلی و در سطح کاملا ابتدایی است که به نظر من عنوان مدیران مناسب نیست. و نکته دوم اینکه قبل از نصب دیتابیس نیاز است تا کارهای زیادی بر روی خود ویندوز سرور و یا ماشین مجازی انجام گردد که شاید حتی از نوع نصب SQL هم مهم تر باشد.
    با تشکر از مطالب دوست عزیز
    پاسخ
    1. فرید طاهری

      فرید طاهری

       سلام دوست عزیز
      الان محتوایی در دنیای امروز کاملا دیده می شوند که وقت خواننده را تلف نکنند و سریع مطلب را برسانند.

      اگر فکر می کنید مباحث ابتدایی است خوشحال می شوم برای این موضوعات شما و سایر دوستان یک مقاله تولید کنید و در اختیار سایر کاربران قرار دهید فکر کنم بسیار شایسته باشد.

      پاسخ
    2. Hamid J. Fard

      Hamid J. Fard

       درسته. یک دید کلی داره ولی سطح ابتدایی نیست البته برای کسانی که اطلاعات کافی از SQL Server ندارند بله یک سطح بسیار ابتدایی است. نکته دوم اینکه یک سری تنظیمات در سطح ویندوز باید انجام شود که روند اختصاص حافظه و اختصاص فظای دیسک سخت رو برای SQL Server آسان کند.

      خیلی خوشحال می شیم که شما توضیحات بیشتری در مورد هر یک از موارد بیان شده را ذکر کنید + تنظیمات ویندوز!
      متاسفم اگر غلط املایی دارم!
      پاسخ
  9. علی عبدیان

    علی عبدیان

     با سلام ممنون مقاله خوبی بود
    فقط گزینه 7 رو یخورده توضیح دهید ممنون میشم

    پاسخ
  10. Hamid J. Fard

    Hamid J. Fard

     در مورد اشتباه ۷ اینطور بگم که فایل تراکنش یا Transaction Log شامل فایلهای ویرچوآل بسیاری است به نام Virtual Log File  که این وی ال اف ها تراکنشها را نگه داری مکنند. فقط به طور خلاصه بگم که اگر به صورت اصولی تنظیم نشود فایل تراکنش دارای وی ال اف فایلهای بسیار زیاد و کوچکی خواهد بود که باعث پایین آمدن سرعت تراکنش ها می شود و باعث می شود که SQL Server به صورت RANDOM فایل تراکنش را بخواند به جای آنکه SEQUENTIAL بخواند.

    پاسخ
  11. Hamid J. Fard

    Hamid J. Fard

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

    پاسخ
    1. فرید طاهری

      فرید طاهری

      سلام. در این مورد برای شما ایمیلی ارسال خواهم کرد.

      با احترام

      پاسخ
  12. رقيه حجازی

    رقيه حجازی

     سلام
    به نکات جالبی اشاره کردید. اگه میشه در مورد نکته 5 بگید که چطور حجم فایل مربوط به تراکنش رو طوری کم کرد که اون اتفاقاتی که گفتید نیفته؟

    پاسخ
  13. Hamid J. Fard

    Hamid J. Fard

     خانم حجازی: خب وقتی بعد از تغییر Recovery Modelبه Full یک فایل پشتیبان بگیرید این مشکل حل میشه. جواب توی نکته نهان بود.

    پاسخ

  14. تورج عزیزی

     Great article!
    امیدوارم دوستان عزیزی که در این مباحث شرکت می کنند همیشه در سایت حاضر باشند!

    پاسخ
  15. ساناز احمدی

    ساناز احمدی

     سلام
    مقاله عالی بود نظر دوستان راهم دیدم به هر حال هریک از دوستان نظر خاصی دارن ولی چه بهتر بود درسایت قسمتی در نظر گرفته می شد تا دوستان راحتر باهم نظرات و دانش خود را به اشتراک بگذارند..
    بازم متشکرم

    پاسخ

  16. حجازی

    ببخشید شما  کل مراحلی که در بند  5 مطرح کردید ، گفتید بدترین عملی هست که یک مدیر پایگاه داده انجام می ده. من خودم همیشه قبل و بعد از تغییر RecoverModel یک BackUp می گیرم که با خوندن مطلب شما فکر کردم که کلاً این روش برای Shrink کردن LogFile اشتباه هست

    پاسخ
  17. Hamid J. Fard

    Hamid J. Fard

     خانم حجازی: در حقیقت Shrink کردن فایل تراکنش یک عمل اشتباه است به دلیل اینکه حجم فایل تراکنش دقیقا بر میگرده به مقدار RPO و اینکه فایل تراکنش درست مدیریت نشده. اصولا فایل تراکنش برای تراکنشهای بسیار بالا حجمی حدود ۲ تا ۸ گیگابایت را داشته باشه نه بیشتر. مگر اینکه….

    پاسخ

  18. حجازی

     ببخشید اینقدر سوال می کنم
     بهر حال یکسری عملیات هست که باعث افزایش حجم فایل تراکنش میشه که بعدش مجبور به این کار میشیم. اینو بایستی چیکار کرد؟

    پاسخ
    1. Hamid J. Fard

      Hamid J. Fard

      حجازی: درسته ولی باید فایل تراکنش همانطور که گفتم به مقدار RPO مدیریت بشه و اینکه مثلا شما یک Bulk Operation دارید در این خصوص Recovery Model را به Bulk Logged تغییر داده و بعد از انجام کار به Full و بعد یک فایل پشتیبان از پایگاه داده می گیرید.

      پاسخ
    2. مسعود طاهری

      مسعود طاهری

        حمید جان+ خانم حجازی  سلام

      حمید عزیز جواب به جا و مناسبی دادید در تکمیل بحث در برخی مواقع اتفاق می افتاد که کاربران حجم زیادی از رکوردها را می خواهند تغییر (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);
        SET @r = @@ROWCOUNT;
        COMMIT TRANSACTION;
        — CHECKPOINT;    — if simple
        — BACKUP LOG … — if full
      END
      پاسخ
      1. Hamid J. Fard

        Hamid J. Fard

         مسعود عزیز و خانم حجازی: 

        نکته اول: البته این رو بگم که در واقعیت هیچ کسی داده ها حجیم و زیادی را با دستور Delete حذف نمی کنند.

        نکته دوم:دستور Delete From با Begin Transaction Delete From تفاوت چندانی در فایل تراکنش ندارد به دلیل آنکه در هر دو دستور تمامی اطلاعات رکوردها در فایل تراکنش ذخیره می شود و بعد از دستورات Checkpoint یا backup Log فایل تراکنش دوباره قابل استفاده قرار می گیرد.

        شما می توانید با دستور fn_dblog تغییرات فایل تراکنش را بعد از هر دو دستور مشاهده کنید.

        امیدوارم کسی برداشت بد از نظر من نکه. بنده فقط می خواهم که دانسته هایم را با شما در اشتراک بگذارم.

      2. مسعود طاهری

        مسعود طاهری

         بلی این دو دستور تفاوتی ندارد چون خود دستور Delete به تنهایی Autocommit Transaction است اما در برخی مواقع سناریوهایی دیده ام که داده های زیادی بنا به دلایلی از سیستم پاک می شود یا حتی Update می شود در این گونه مواقع می توان با انجام این نوع کارها تا حدودی از افزایش حجم لاگ جلوگیری کرد. (تهیه لاگ بکاپ یا Chekpoint با توجه به Recovery Model) 

        در تکمیل صحبت های حمید

        –نظارت بر فضای لاگ فایل
        DBCC SQLPERF(LOGSPACE)
        GO

        –مشاهده وی ال اف ها
        DBCC LOGINFO
        GO

        –مشاهده لاگ رکوردها
        SELECT * FROM fn_dblog(NULL,NULL)
        GO

  19. سیامک محمدی

    سیامک محمدی

    موارد زیر هم میتونن جزو Bad practice ها باشن:

    – ایندکس‌ گذاری‌های تکراری و یا بیش از حد
    – ایجاد جداول Heap
    – استفاده از تکنیک‌های کوئری نویسی در جاهایی که میتوان ساده تر به جواب رسید. مثل استفاده زیاد از Curser, Temp Tableها، ویوهای تودرتو و ..
    – نصب ننمودن پچ‌ها و سرویس پک‌ها
    – رعایت ننمودن مسائل امنیتی و ناخود آگاه فراهم کردن فضا برای SQL Injection
    پاسخ

  20. محمد استقامت

       سلام

    به تنظیمات پیش فرض اشاره کردین. مشکلی برای ما پیش اومده که شاید به نحوی به این تنظیمات مرتبط بشه اگه راهنمایی کنید ممنون می شم. 
    مشخصات محیط ما : 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_id cpu_id status
    0 0 VISIBLE ONLINE
    1 1 VISIBLE ONLINE
    …
    19 19 VISIBLE ONLINE
    20 20 VISIBLE OFFLINE
    21 21 VISIBLE OFFLINE
    …
    29 29 VISIBLE OFFLINE
    1048576 0 VISIBLE 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 مربوطه و اگر هست چه راهی با توجه به شرایط نرم افزارها در ایران پیش روم هست ؟ ممنون
    پاسخ
    1. Hamid J. Fard

      Hamid J. Fard

         بله همانطور که مشهود است مشکل از قسمت لایسنس است. در حال حاضر 10 عدد از Scheduler  ها به صورت Offline هستند یعنی SQL Server هیچ گونه Thread را بر روی آن پردازنده ها اجراء نمی کند.
      پاسخ
    2. مسعود طاهری

      مسعود طاهری

      سلام بر حمید عزیز و آقای استقامت 

      بلی این موضوع صحیح است. بحث لایسنس است. در قسمت SQL Server Logs هم زمانی که سرویس SQL استارت می شود. در خصوص تعداد Coreهای قابل استفاده به ازای لایسنس شما لاگی ثبت می کند ….
      پاسخ

  21. محمد استقامت

    سلام بر اساتید عزیز

    سپاس از پاسخ شما.
    این به این معنی است که همه نسخ sql server 2014 enterprise موجود در ایران از همین نسخه با لایسنس های محدود هستند. (ساپورت حداکثر 20 Core CPU) یا اینکه نسخه دیگری وجود دارد که بتوانم از آن استفاده کنم ؟ 
    و یا اینکه با تغییری روی همین نسخه بتوان Licence آنرا ارتقاء دارد؟ قطعا تعویض sql server روی سیستم های عملیاتی بسیار هزینه بر است.

    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      تهیه نسخه 

      enterprise core license
      مستلزم پرداخت هزینه و… می باشد. (از نمایندگی های مایکروسافت در خارج از ایران تهیه کنید)
      در ضمن پس از تهیه لاینس باید مجدد SQL Server را Change کنید.
      پاسخ
      1. Hamid J. Fard

        Hamid J. Fard

           البته نیازی به تغییر SQL Server نیست به این دلیل که شما فقط نیاز دارید کد لایسنس را به روز رسانی کنید و اینکه شما نمی توانید از نماینده گی های خارج از کشور خریداری کنید مگر اینکه از شرکت شما یک نماینده گی در آن کشور باشد در غیر اینصورت غیر قانونی بوده.
        در ضمن در نظر داشته باشید که فقط ورژن Upgrade می شود نه Edition.
      2. مسعود طاهری

        مسعود طاهری

            بلی تغییر را اشتباه نوشتم. باید گزبنه Upgrade را در Setup  انتخاب کنیم

        راستی حمید در ایران روش های ناسناخته ای برای دور زدن تحریم ها وجود دارد از اینکارهای غیر قانونی خیلی از سازمان ها انجام می دهند و حتی در داخل ایران هم از خدمات مایکروسافت استفاده می کنند. چند تا سازمان دولتی که باهشون درگیر شدم دقیقا همین کار را انجام می دهند. بدون داشتن شرکت در کشور دیگر فقط از طریق واسطه و …. 
      3. Hamid J. Fard

        Hamid J. Fard

           درسته ولی لایسنس به نام آن شرکت واسطه ثبت شده و برای استفاده در ایران نیست و اینکه مایکروسافت می تواند از آن شرکت واسط شکایت کند 

      4. مسعود طاهری

        مسعود طاهری

            اتفاقا من هم از دقیقا این موضوع را به سازمان گوشزد کردم و دقیقا صفحه لایسنس و… را که مشاهده کردم شاخ در آوردم به نام خود سازمان و تا به حال که مشکلی نداشته است. شاید خیلی ها نتوانند این کار را انجام دهند اما واسطه و… (مثل ب.ز و امثال آن)

      5. مسعود طاهری

        مسعود طاهری

            و جالب تر این است که چندین بار هم پشتیبانی Remote از آن طرف داشته اند و حتی در حد ارائه Hotfix و…

        وقتی این گونه چیزها را می بیننم به این نتیجه رسیدم آخر الزمان نزدیک است

  22. محمد استقامت

       در مورد اشتباه چهارم : قرار دادن فایل های تراکنش و داده روی یک درایو

    به احتمال زیاد منظور درایوهایی است که روی دیسک های جداگانه باشند. 
    حال در اکثر سازمان های بزرگ دیگر سرورها بصورت فیزیکی و جداگانه نیستند بلکه سرورهای مجازی هستند که اکثر آنها هم از SAN استفاده می کنند. 
    حال سوال من این است : روی درایو هایی که همه از یک SAN   هستند و می دانیم که پشت همه این درایو ها یک سخت افزار واقعی است ، ایا هنوز این جداسازی می تواند مزیتی محسوب شود یا نه ؟ 
    چون به نظرم دلیل یکی از دلایل اصلی این جداسازی دسترسی موازی با سرعت بالاست یعنی دو دیسک با هم و بصورت موازی روی داده و تراکنش کار کنند. که در حالت SAN واقعا نمی دانم چه مزیتی می تواند داشته باشد؟
    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      سلام 

       هنگام استفاده از 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. محمد استقامت

           بسیار سپاس گذارم. توضیح کاملی بود. 

  23. جواد

    سلام وقت بخیر
    یک سوالی داشتم میخواستم بپرسم برای شیرینک کردن خودکار لاگ فایل باید چیکار کنم ؟
    فول بکاپ هم به صورت خودکار گرفته می شود
    البته بدون اینکه به دیتابیس آسیبی برسد

    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      سلام دوست عزیز
      1- اگر می خواهید که Log Backup داشته باشید می توانید لاگ بکاپ بگیرید (با جاب) در این حالت لاگ فایل شما عموما حجم ش خیلی زیاد رشد نخواهد کرد
      2- اگر لزومی به داشتن لاگ بکاپ ندارید می توانید Recovery Model بانک را در حالت Simple قرار دهید

      پیشنهاد من به شما استفاده از حالت اول است در این حالت می توانید مزایای Log Backup را بدست آورید

      برای بدست آوردن اطلاعات بیشتر به این لینک مراجعه کنید
      https://nikamooz.com/product/database-maintenance-sql-server/

      پاسخ

  24. رضا

    سلام جناب آقای طاهری
    بنده یک سیستم حسابداری دارم و میخوام رو حالت cloud اجرا کنم و تمام دیتا های تمام شرکتها در یک دیتابیس ثبت شوند ولی مشکل تو backup و restore کردن هر شرکت به صورت مجزاست آیا این امکان وجود داده که داده های هر شرکت رو جداگانه backup گرفت

    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      سلام
      راحت ترین راه
      ایجاد دیتابیس جدید – استفاده از دستور Select into برای درج جدول و دیتاهای مورد نیاز در اون دیتابیس جدید است بعدش تهیه بکاپ از اون دیتابیس

      موفق باشید

      پاسخ

  25. شایان میرسلطانی

    سلام خسته نباشید
    من یه سوال در رابطه با فایل گروپ ها داشتم
    اینکه من الان یک دیتابیس دارم که حجمش 5 گیگه و فقط روی mdf ذخیره میشده دیتاها, الان من میخوام روی یک درایو ssd یک فایل گروپ دیگه بسازم که دیتاها برن اونجا و حجم mdf زیاد تر نشه.
    حالا سوال اینه که الان فقط برم فایل گروپ جدید رو primary کنم یا کار دیگه هم باید بکنم؟ و اینکه اگه بخوام همه فایل گروپ ها باهم دیگه رشد کنن چیکار کنم؟
    بسیار ممنون

    پاسخ
    1. مسعود طاهری

      مسعود طاهری

      بازسازی ساختار دیتابیس ها هم تاثیر گذار است روی کار شما
      یک فایل گروه برای Primary = قرار گرفتن اشیاء سیستمی
      یک فایل گروه برای جدوال = همون کلاستر ایندکس ها
      یک فایل گروه برای ایندکس های Non Clustered
      یک فایل گروه هم برای BLOB

      اگر این ها هر کدام چند دیتا فایل داشته باشند می توانید از Trace Flag شماره 1117 کمک بگیرید که البته بسته به نسخه SQL Server با دستور هم قابل راه اندازی است

      تمامی این موارد و کلی نکته دیگر در دوره Performance & Tuning به طور مفصل بررسی شده است

      پاسخ

  26. ذکایی

    سلام خسته نباشید.
    من یه سوالی داشتم.
    میشه نرم افزار اس کیوال سرور غیر از درایو C نصب کرد و نرم افزار ویژال استودیو تو خودت درایو C?

    پاسخ
    1. آرزو محمدزاده

      آرزو محمدزاده

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

      سپاس از همراهی شما

      پاسخ

ارسال یک نظر

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

تمامی حقوق مادی و معنوی این وب سایت متعلق به نیک آموز می باشد.
این سایت توسط تیم آموزش برنامه نویسی نیک آموز مدیریت می شود.