تفاوت حجم MDF در unique index

[A.Farzin]

با سلام

حجم MDF من با 7 میلیون رکورد اطلاعات در یک جدول که 64 فیلد دارد، به حدود 15GB رسیده است.
در بررسی جداول متوجه شدم بیشترین فضا را دو تا از جداول اشغال کرده‌اند. که یکی از آنها 8GB و دیگری 4.5GB فضا اشغال کرده‌اند.
در هر دو جدول 60% فضای اشغال شده مربوط به ایندکسها بود بدین ترتیب در مورد جدول اولی 4.8GB صرف نگهداری ایندکسها شده بود.
به دنبال این هستم که حجم دیتابانک را کاهش بدهم ولی در خصوص راهکارها ابهام دارم. لطفاً راهنمائیم فرمائید.
1) اگر ایندکسها را به ایندکس unique تبدیل کنم، آیا تاثیری بر حجم فایل خواهد داشت؟
2) حدود 10 تا از فیلدهائی که در جدول هست با Data Type از نوع Float تعریف شده‌اند که می‌توانستند از نوع int هم تعریف شوند، تاثیر تغییر این دیتاتایپ روی حجم کلی بانک قابل توجه خواهد بود یا نه؟

ممنون

[پویا]

بهتره قبل از هر کار از دستورات reindex و dbcc استفاده کنید تا جدول ها و ایندکس هاتون را بررسی کنید
این دستورات باعث افزایش سرعت و کاهش حجم جدول ها و ایندکس ها می شود
استفاده از نوع float برای فیلدی که مقدار اعشاری ندارد کار درستی نیست چون دو برابر فضا اشغال می کند
همچنین استفاده از نوع char برای فیلد هایی که طول رشته در آن ها متغیر است اشتباه است و باید از نوع varchar استفاده شود

[supporter]

این که تبدیل فیلدهای نوع Float به Int تأثیر قابل توجه ای روی حجم Database می تونه داشته باشه یا نه به تعداد رکوردهای Table های مربوطه بستگی داره.

یک نکته دیگه که به نظر من می تونه مهم باشه کوچک بودن طول Clustered Index های جدول هاست.
این نکته وقتی تعداد Index هاتون زیاد باشه بیشتر خودشو نشون میده.
توجه داشته باشید که چون مقدار رکوردهای Clustered Index در Index های دیگه نگه داشته می‌شه هر چه طول Clustered Index جدولتون بزرگتر باشه اندازه Index های روی اون جدول هم بزرگتر خواهد شد.

[AminSobati]

1) تغییر ایندکس به یونیک ایندکس، تاثیری در حجم نخواهد داشت، چون یونیک بودن صرفا یک خصوصیت محسوب میشه، نه یک ساختار. شاید این تصور رو دارین که یونیک بودن باعث Distinct شدن اطلاعات میشه! ولی اینطور نیست، چون خود فیلد شما باید واقعا تکراری نداشته باشه (یونیک باشه) تا SQL Server قبول کنه روی اون یونیک ایندکس بسازین

2) یک راهکار برای کاهش حجم دیتابیس میتونه این باشه: تمام جداول به همراه ایندکسها رو به یک Filegroup جدید ببرین، سپس Primary رو Shrink کنین. این کار باعث میشه جداول بصورت منظم در Filegroup جدید چیده بشن و در حداقل فضای ممکن قرار بگیرند

3) dbcc reindex و امثالهم میتونن باعث کاهش حجم جداول بشن اما دیتابیس رو بزرگ میکنند! به این دلیل که وقتی یک جدول reindex میشه، SQL Server ممکنه نیاز پیدا کنه فایل رو افزایش حجم بده تا جدول رو بصورت منظم در فضای خالی بچینه. پس خود جدول مرتب و کم حجم میشه اما دیتابیس شما رشد کرده.

4) Clustered Index، خود جدوله و تمام فیلدها رو در بر میگیره. کوچک یا بزرگ کردن Clustered Index چندان معنی نداره. اما اگر منظور Clustered Key باشه، میتونیم بگیم چون Clustered Key در تمام ایندکسهای non clustered شرکت میکنه، بهتره Clustered Key رو کوچک بگیریم (در صورت امکان). Clustered Key همون فیلدی هست که روی اون Clustered Index میسازیم. اما در کل این موضوع در کاهش حجم کلی دیتابیس تاثیر ناچیزی داره

[A.Farzin]

در یکی از جدولها، PRIMARY KEY CLUSTERED بر روی 10 ستون ساخته شده بود که چون ایندکسهای دیگری هم در جدول بود و همانگونه که اساتید محترم فرمودند، قاعدتاً در آنها هم از این کلید استفاده شده بود، حجم ایندکسها حدود 3GB بود.
ابتدا این ایندکس CLUSTERED را حذف کردم و برای آن یک ستون ID ایجاد و PRIMARY KEY CLUSTERED را روی آن گذاشتم. در نتیجه حجم ایندکسها به 1GB رسید.
ولی یک سئوال:
علت ایجاد PRIMARY KEY CLUSTERED روی 10 ستون این بود که نیاز داشتم این 10 ستون تکراری نداشته باشند. اگر حالا به جای آن یک ایندکس UNIQUE NONCLUSTERED روی این 10 ستون بسازم، آیا مجدداً حجم ایندکسهایم افزایش قابلا ملاحظه خواهند داشت یا نه؟

چون حذف PRIMARY KEY CLUSTERED نزدیک 4.5 ساعت طول کشید و ساخت PRIMARY KEY CLUSTERED مجدد هم 4.15 ساعت، این موضوع را دیگه تست نکردم تا ببینم چه می‌شود.

[AminSobati]

Clustered Index در تمام nonclusteredها شرکت میکنه. لذا اگر شما یک Clustered Index تک فیلدی دارین، شرکت کردنش در ایندکسهای Nonclustered مشکلی از نظر حجم بوجود نمیاره

[A.Farzin]

چون حذف PRIMARY KEY CLUSTERED نزدیک 4.5 ساعت طول کشید و ساخت PRIMARY KEY CLUSTERED مجدد هم 4.15 ساعت، این موضوع را دیگه تست نکردم تا ببینم چه می‌شود.

با توجه به زمان زباد انجام تغییرات فوق اگر یک جدول خالی درست می‌کردم و داده‌ها را در آن Insert می‌کردم آیا زمان صرف شده کمتر نمی‌شد؟

[AminSobati]

اگر منظورتون اینه که این جدول خالی، PK مورد نظر رو داشته باشه و وقتی اطلاعات Import میشن، از همون ابتدا به صورت مرتب شده قرار بگیرند، باید بگم یقین ندارم حسنی از نظر Performance داشته باشه اما این رو یقین دارم که در دیتابیسهای بزرگ تغییر نام جدول کار کوچکی نیست! اگر هم قراره این جدول rename بشه به نام جدول اصلی، در شرایط زیادی این کار امکان پذیر نیست. مثلا وقتی جدول تحت Replication باشه