روزانه بیش از 2000 رکورد به اطلاعات دیتابیس نرم افزار اتوماسیون اداری بنده اضافه می شود که این موضوع به تدریج باعث کند شدن سیستم می گردد. آیا راهی برای رفع این اشکال وجود دارد؟
برخی از دوستان روش index را به من پیشنهاد کردند.
آیا این روش استاندارد و کاربردی هست؟ آیا روش های بهتری موجود است؟
شما میتونید رکروردهای قدیمی را جدا کنید و به جای یه سرور دو سه تا سرور استفاده کنید البته بستگی به خدوتون داره !!!!!
سلام.
برای رفع این مشکل اول باید ببینید چه دستوراتی بیش از همه دارند اجرا می شوند و باعث افزایش اشغال RAM توسط SQL Server می شود. برای اینکار میتونید از SQL Profiler استفاده کنید.
میشه بعد از اینکار بعضی از این دستورات رو به Stored Procedure تبدیل کرد تا فقط یکبار Compile شوند که این عمل باعث افزایش سرعت شما خواهد شد.
Telegram : @SQL_Server
با تشکر از پاسخ
روش هایی که ذکر شد آیا برای دیتابیس هایی که بیشتر از 200 گیگ اطلاعات دارند هم کاربرد دارد؟
آیا یک دیتابیس می تواند ذاتاً کند باشد و حتی با ارتقا قدرت سرور نتیجه مطلوب حاصل نشود؟
در صورت کند بودن ذاتی دیتابیس آیا می توان در زمان ارائه دیتابیس و وقتی که اطلاعات خاصی داخل آن نیست مورد فوق را تست کرد؟
من می توانم قدرت سرور را افزایش دهم اما امکان تعدد سرور وجود ندارد.
آیا می توان برای حجم دیتابیس و میزان قدرت سرور رابطه نموداری در نظر گرفت؟
اگر چنین چیزی امکان داشته باشد با یک الگوی مناسب می توان سخت افزار را نیز مدیریت کرد.
سلام دوست عزیزم،
هیچ دیتابیسی بدون index دارای بازده مناسب نخواهد بود. ایندکس کمک میکنه جستجو در بخش کوچکتری از اطلاعات انجام بشه لذا حجم اطلاعات شما نگرانی ایجاد نخواهد کرد. در اغلب موارد کندی که من برخورد داشتم (شاید 95 درصد) دلیلش نبودن ایندکسهای مناسب بوده. پس از اینکه وضعیت ایندکسها بهینه شد، اگر سرعت بهبود پیدا نکرد اونوقت به فکر ارتقاء سخت افزار میافتیم که همون 5 درصد باقیمانده خواهد بود!
آرشیو کردن اطلاعات که دوستان اشاره کردند روش خوبی هست ولی مستلزم آشنایی کافی از طراحی دیتابیس و نیاز Queryهاست.
من هم این مشکل رو دارم و البته برای دیتابیس ایندکس تعریف شده که تا حدود قابل قبولی (ایندکس ها از لحاظ بهینه بودن در حال بررسی هستند) بهینه هستند اما به دلیل حجم بالای اطلاعات (مثلا 30 میلیون در یک جدول) و اضافه شدن اطلاعات با سرعت زیاد، سرعت روز به روز داره پایین تر میاد.
میخوام بدونم به غیر از ایندکس چه کار دیگه ایی می تونم انجام بدم تا اوضاع بهتر بشه؟
در زمان های خاصی باید ایندکس های ساخته شده را rebuild کنی
مثلا fragmentaion عامل مهمی برای تصمیم گیری است
همچنین cluster index را تا جایی که امکان دارد باید کوچک تعریف کرد تا حجم noncluster ها هم زیاد نشود
همچنین filterdcluster ها می توانند کمک کنند مثلا سطرهایی که null هستند در ایندکس وارد نشوند
ممنون از پاسختون اما سوال من این بود که غیر از ایندکس چه کار میتونم انجام بدم . یه چیزهایی راجع به Partitioning خوندم کسی میتونه توضیح کوتاهی بده و یا منبع خوبی معرفی کنه
اصولا برای کاری که من میخواهم مفید هست؟
در ضمن تعداد کاربر های همزمانمون هم در حال افزایش هست در مورد این هم اگر کسی راهنمایی داره ممنون میشم بشنوم و باز هم اگه منبع مناسبی هست لطف میکنید که معرفی میکنید
يكي از روش‌هايي كه مي تواني سرعت را بالا ببري اينكه داده هاي باينري رو از جداول جدا كني براي اينكار مي تواني به سراغ NDF و روش‌هاي ديگر بروي
روش بعدي كه من توصيه مي كنم بري سراغش Partition بندي جداول ست البته اگه مي خواهي جواب درست از هر دو اين روش ها بگيري بايد فايل هاي NDF مربوط به اون ها در ديسك هاي جداگانه قرار بگيرين
اين روش براي بانك هايي كه حجمشون خيلي بالا است استفاده ميشه
براي مثال من الان بانك اطلاعاتي دارم كه روي SQL 2000 است و حجم اون با داده هاي باينري تا به امروز 104 گيگابايت است و صرفا از روش اول استفاده كردم ايندكس هاي مناسب هم در سيستم قرار دادم يك عدد هم SP در سيستم ندارم كليه كوئري هاي پروژه به صورت adhoc query (كوئري كه خارج از SP باشد) مي باشد به خوبي هم كاربراي مجموعه كه در حدود 30 تا هستند را ساپورت ميده در ضمن RAID سيستم هم از نوع RAID 5 است.
فقط سعي كن كه مدام ايندكس ها را در مواقع لزوم Rebuildكرده و همين طور هر از چندگاهي جهت آناليز و.... با Profiler كوئري هايي كه سرعت پاييني دارند استخراج كن تا بتوني براي اونها ايندكس هاي مناسب بزني
توي SQL 2005,2008 مي تواني از Covered Index (ايندكس هاي پوشاننده) جهت سرعت بخشيدن به كوئري ها استفاده كني
همين طور از مفهوم Missing Index براي به دام انداختن كوئري هايي كه داراي ايندكس مناسب نيستند استفاده كني (در اين تكنيك خود SQL Server بررسي مي كند كه آيا اندكس هاي موجود براي كوئري هاتون مناسب است و يا خير در صورت يكه ايندكس مناسب نباشد و يا كوئري داراي ايندكس نباشد خود SQLدر جداولي سيستمي ايندكسي براي كوئري شما پيشنهاد مي كنه كه شما مي تونيد اون رو استخراج و در صورت صلاحديد بر روي جدولتون ايجاد نماييد)
اگه توضيحات بيشتري در مورد هر كدوم از مباحث مطرح شده داشتي بگو تا بنويسم
سلام به نظر من طراحی خیلی مهمتر از استفاده از ایندکس ها و .. است .
مطمئناً دیتابیس شما از دیتابیس بانکی بزرگتر نیست . پس چرا وقتی موجودی از POS یا خودپرداز (ATM) می گیرید با این وضعیت خطوط دیتا به این سرعت پاسخ می گیرید ؟
هیچ دلیلی نداره کاربر در آن واحد به 30 میلیون رکورد دسترسی داشته باشه . آیا همه اون 30 میلیون رکورد در یک لحظه بدردش می خوره ؟
راه حلی که سیستم بانکی کشور برای کندی ارتباط استفاده می کنه اینه که در آخر روز بین ساعت 11:30 تا 12:00 سرور Down شده و یک جدول جدید در دیتابیس ایجاد میشه که مانده نهائی هر حساب توی اون ذخیره می شه . بنا براین برای دریافت مانده حساب در روز بعد فقط به سراغ یک رکورد می ره . نه اینکه جمع تمام رکورد ها زده بشه .
امیدوارم منظورم رو تونسته باشم برسونم .
ممنون از راهنمایی تون اگر امکان داره در این مورد توضیح بدید چون در این مورد چیزی نشنیده بودمنوشته شده توسط in_chand_nafar
در مورد Partitioning هم کمی تحقیق کردم اما مشکلی که من با این دیتا بیس دارم اینه که داده ها به صورت Parent_Child به هم وابسته هستند و کسی که به یک داده نیاز داره در واقع کل شجره رو نیاز داره منظورم در گزارشات هست و نمی دونم در این موارد چطور میشه از Partitioning استفاده کرد
Saeid59_m عزیز دقیقا به همین علتی که توضیح دادم نمیشه مثل مثال شما عمل کرد چون در چند جدول که محاسباتی هست میشه اینطور عمل کرد ولی در بقیه دسترسی ها عمقی هستند
in_chand_nafar عزیز ممکنه در رابطه با مطلبی که گفتید توضیح بیشتری بدید ممنون میشم
سلام
ببين سه دسته راهكار مطرح شده:
1- بهينه سازي وضعيت جاري براي سرعت بخشيدن به كار .مثلاindex
2- استفاده از روش‌هاي ديگر براي سرعت بخشيدن به دسترسي همزمانو سريع : مثلا Partitioning
3- دستكاري طراحي جداول
من در ارتبا با مورد سوم مي خوام بگم. ببين اين جدول اصلي ، احتمال زياد جدول فايل‌هاي متن نامه‌ها ستو يا جدول cover و يا مشخصات نامه ها.
اگه بتوني يك مرحله در دسترسي به اين جدول اضافه كني ، موضوع حل مي شه. چطوري ؟ اول جدولت رو به 2 تا جدول مي شكني . مثلا در جدول اصلي فقط يك ميليون ركورد و در جدول_Back بقيه . خوب ابتدا سيستم هدايت مي شه به جدول اصلي ، اگر جواب پيدا شد(كه شايد 90 درصد كار شما به همين جدول باشه) 1 بر مي گردونه و ادامه كار و قضيه حله. و اگه صفر برگردوند (يعني پيدا نكرد) سيستم رو به سراغ جدول دوم بفرست.
موفق باشي
سعيد جون اين مطلبي كه داري اشاره مي كني فقط در حد تيوري است و براي يك بانك نيم ساعت اون هم هر شب نمي تونه عملي باشه.
اين عمليات به اينصورت انجام مي شه كه با هر تراكنش مانده حساب در جدول ديگري كه فقط شماره حساب و شماره كارت است و آخرين مانده رو داره ذخيره مي شه
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول