ترفندهایی برای مدیریت بانک های اطلاعاتی با حجم بالا؟

[Jozef]

مثلا Shirink.
که خب بعضی اساتید توصیه میکنند تا نیاز نداشتیم استفاده نکنیم.
اساتید کمک کنند

[AminSobati]

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

[Jozef]

ممنون
میخوام بدونم واسه کنترل و مدیریت بانک های اطلاعاتی با حجم بالا کارها یا عملیات خاصی باید انجام بشه؟
مثل عمل Shrink که فضاهای خالی بدون استفاده رو کم میکنه.

[mpggcobol]

استفاده نکردن از بعضی از دستورات مثل

Select * from _Tbl
, not exists,distinct که توی رکوردهای ملیونی سرعت را پایین میاره بجای not exists از except و بجای distinct از union استفاده کنید. به مثال زیر توجه کنید:

select distinct Code from AstrictCode
همان نتیجه را می دهد منتهی با سرعتی کمتر از دستور زیر

Select Code From AstricCode Union Select Code From AstricCode
سعی کنید بیشتر از Stored Procedure استفاده کنید چرا که DBMS فقط یک بار زحمت Debug کردنش رو میکشه ولی در مورد دستورات یا توابع این طور نیست
همچنین استفاده از View ها بجای استفاده از select های تکراری نتایج فوق را در بر خواهد داشت
مدیریت Indexes هم که جای خود را دارد
Trigger ها هم که نابود کننده سرعت هستند

[Jozef]

دوست عزیز ایا تبدیل view به storedproc اشتباهه؟ یعنی روال وظیفه select رو انجام بده؟
من تمام عملیات ثبت و ویرایش و حذف اطلاعات را با Transaction انجام میدم. این ممکنه پس از مدتی ایجاد مشکل کنه؟

[mpggcobol]

view همانطور که از اسمش پیداست فقط view است یعنی ساختار نمایشی نه عملیاتی
به هیچ عنوان یک view نمی تواند وطایف SP را انجام دهد
ولی با توجه به سوالتون select زدن از view توی SP سرعتش بالا تر از select معمولیه
اگر توی transaction ها از قفل استفاده می کنید در مورد قفل ها مطالعه بیشتری داشته باشید
ولی استفاده معمولی هیچ مشکلی نداره و لازمه
حضور تراکنش ها با مفاهیم Thread در DBMS مدیریت می شود

[m0rteza]

اگر احساس مي كنيد كه حجم داده ها در يك جدول زياد خواهد شد بهتر است از shirink استفاده كنيد

براي اطلاعات حجيم
طراحي و نرمالسازي صحيح جداول نقش مهمي دارند
Index گذاري هاي صحيح

[AminSobati]

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

- استفاده از View یا SP تاثیری در سرعت کوئری شما نداره! تنها Timeی که در این دو حالت Save میکنیم، زمان Compile هست که در چند میلی ثانیه انجام میشه. پس انتظار نداشته باشید که اگر یک کوئری در SP به مدت 90 ثانیه طول میکشه، در غیر SP مثلا بشه 91 ثانیه! دلیل استفاده از SP در این هست که کوئری یک بار نوشته میشه و یک بار Compile میشه و میتونیم Security بهتری اعمال کنیم.

- از Shrink روی اطلاعات شدیدا اجتناب کنید چون باعث ناپیوستگی (Fragmentation) اطلاعات میشه. Shrink روی Log File اشکالی نداره.

- بقیه نکات، مثل بهینه نوشتن کوئری، داشتن ایندکسهای مناسب و ... برای همه بانکها توصیه میشه با هر سایزی

پس برای بانکهای حجیم چه نکاتی باید مد نظر داشت؟ برای داشتن پاسخی بهتر، باید دیدگاهمون رو اول معین کنیم. از دید یک Developer فرقی نمیکنه، برنامه نویس همیشه باید کوئری ها رو مناسب بنویسه، تا جای ممکن Cursor استفاده نکنه، زمان Transactionها رو کوتاه نگه داره و ....
اما از دید Admin، میشه ترفندهایی مثل Partitioning، تقسیم بندی درست Filegroupها برای Backupهای کم تر و ... باید رعایت بشه. متاسفانه این مطالب در یک پست نمیگنجه و توصیه من این هست که در زمینه Administration کتاب مطالعه بفرمایید

[محمد سلیم آبادی]

استفاده نکردن از بعضی از دستورات مثل

, not exists,distinct که توی رکوردهای ملیونی سرعت را پایین میاره بجای not exists از except و بجای distinct از union استفاده کنید. به مثال زیر توجه کنید:

همان نتیجه را می دهد منتهی با سرعتی کمتر از دستور زیر



سلام،
آیا این مطالب بواسطه ی تجربیات شخصی شما حاصل شدند یا اینکه از یک مقاله یا کتابی استخراج کرده این؟

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

[mpggcobol]

سلام،
آیا این مطالب بواسطه ی تجربیات شخصی شما حاصل شدند یا اینکه از یک مقاله یا کتابی استخراج کرده این؟

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

دوست عزیز این دستورات تست شده در مورد distinct باز هم بحث وجود داره و اون اینه که چند تا distinct توی یه select داشته باشیم برای تست هم کافیه یک تیبل ملیونی با کرسر بسازیم و چک کنیم
ولی برای اطلاع بیشتر در
http://blog.sqlauthority.com و
http://www.sqlteam.com مباحث خوبی هست

[محمد سلیم آبادی]

یک تیبل ملیونی با کرسر بسازیم
استفاده از Cursor و حتی Loop با وجود زبان قدرتمند مجموعه گرای SQL کار جالبی نیست.
برای تولید داده های آزمایشی به اندازه کافی روش بسیار موثر و کاربردی وجود داره که در ادامه کمی در موردش توضیح می دهم.

در صورتی که جدولی در بانکتان وجود دارد که دارای سطرهای زیادی است آن را انتخاب کنید در غیر اینصورت می تواند از جداول یا ویوهای سیستمی مثل sys.objects و یا sys.columns استفاده کنین.

با کمک CROSS JOIN جدول را چندین بار با خودش ضرب کنید تا تعداد سطر مورد نظر تولید شود البته توجه کنید که برای جداول نام مستعار در نظر بگیرین.

سپس با استفاده از یکسری توابع موثر، داده ها را در انواع مختلف تولید کنید بطور مثال برای تولید داده از نوع عددی از کد زیر استفاده می کنیم:

ABS(CHECKSUM(NEWID())) --d