بالا رفتن تصاعدی حجم فایل بانک در SQL Server

[کیوان معینی]

یه جایی خوندم که در SQL Server ، اگه تعداد رکوردها از یک حدی بالاتر بره ، حجم فایل بانک (*.Mdf ) تصاعدی بالا میره (به گفته نویسنده مقاله : ضعف SQL Server در مقابل Oracle ) .
اگه کسی اطلاعاتی داره ، ممنون میشم . و اگه این مطلب درسته ، چطور میشه باهاش کنار اومد یا حلش کرد .

[odiseh]

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

[کیوان معینی]

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

[AminSobati]

کیوان جان این هم از اون حرفهاست! هر رکورد فقط به اندازه بایتهایی که فیلدهاش نیاز دارند فضا اشغال میکنه. لینک اون مطلب رو میتونی بفرستی؟

[کیوان معینی]

کیوان جان این هم از اون حرفهاست! هر رکورد فقط به اندازه بایتهایی که فیلدهاش نیاز دارند فضا اشغال میکنه. لینک اون مطلب رو میتونی بفرستی؟

با تشکر از شما ، مدیر بخش
من صحت این مطلب رو نه تایید می کنم نه رد ! ولی خوب ، فکر نمی کنم که نحوه ذخیره سازی اطلاعات در بانکهای رابطه ای نظیر SQL Server و Oracle ( با توجه به مباحث ساختمان داده ) به سادگی قرار دادن بایتهای اطلاعات پشت سر هم باشه ؟!! اگه به این راحتی ها بود ، خیلی ها میتونستند یه نرم افزار DataBase مثل SQL Server و ... بنویسند . من فکر میکنم که نحوه ذخیره سازی اطلاعات ، شامل الگوریتم های پیچیده ای است که هر شرکت مختص خودش طراحی کرده

در عین حال ، باز هم ممنون

در ضمن مطلبی که من خوندم ، یه مقاله چاپی از یه نشریه معتبره . اگه تونستم اسکنش رو میزارم .

[کیوان معینی]

کسی از دوستان نظری نداره ؟!

[AminSobati]

حرف شما درسته، چون Storage Engine یکی از پیچیده ترین اجزاء SQL Server هستش، اما عرض من این نبود که کار ذخیره سازی به سادگیه پشت هم قرار دادن چند بایت باشه! بلکه هر رکورد به تعداد بایتهای مشخصی نیاز داره و تصاعدی در کار نیست! من فکر میکنم اون مقاله هرچقدر هم معتبر باشه، اعتبارش بیشتر از این نیست که بریم سراغ وب لاگ آقای Paul Randal که از Developerهای تیم Storage Engine هستش و ببینیم هر رکورد چه ساختاری داره:


1) record header
a) 4 bytes long
b) two bytes of record metadata (record type)
c) two bytes pointing forward in the record to the NULL bitmap

2) fixed length portion of the record, containing the columns storing data types that have fixed lengths (e.g. bigint, char(10), datetime)

3) NULL bitmap
a) two bytes for count of columns in the record
b) variable number of bytes to store one bit per column in the record, regardless of whether the column is nullable or not (this is different and simpler than SQL Server 2000 which had one bit per nullable column only)
c) this allows an optimization when reading columns that are NULL

4) variable-length column offset array
a) two bytes for the count of variable-length columns
b) two bytes per variable length column, giving the offset to the start of the column value

5) versioning tag
a) this is in SQL Server 2005 only
b) this is a 14-byte structure that contains a timestamp plus a pointer into the version store in tempdb

[کیوان معینی]

باز هم از شما مدیر بخش ، تشکر می کنم

با تمام احترام ، ( و با توجه به این که این مسئله از بحث اصلی خارج شد ) خدمت شما عرض می کنم که اطلاعاتی که شما در بالا زحمت کشیده اید و ذکر کرده اید ، بنوعی همان بحث چگونگی ذخیره شدن و فضای لازم جهت ذخیره کردن اطلاعات سطرها و ستون ها ( مفصل تر) می باشد ، ولی درعمل خیلی مسائل و الگوریتم های مهم ترو سنگین تر ازاینها وجود دارد که (خیلی از شرکت ها و ... بدنبال آن هستند ) و من و شما به هیچ وجه به آنها دست نخواهیم یافت حتی از طریق وب لاگ آقای Paul Randal !!
چرا که درغیراین صورت پروژه SQL Server شرکت Microsoft ، یک پروژه ( اپن سورس ) خواهد بود که صد البته این طور نیست ؟! پس خواهش میکنم در مورد این مسئله کنجکاوانه تر به بحث بپردازیم تا به یک نتیجه منطقی برسیم !!

سپاسگزارم .

[AminSobati]

عزیزم،
اگر تمام الگوریتمهای استفاده شده در ذخیره سازی اطلاعات رو هم فاش کنند، باز هم تولید RDBMS غیر ممکنه. گو اینکه چندان پوشیده هم نیست! شرکت هایی که Third Party برای مثلا SQL Server یا Oracle تولید میکنند پس به چه شکل این کار رو انجام میدن؟ نرم افزارهای Data Recovery در صورت Damage شدن فایل دیتابیس میتونن از داخل فایل، تا جاییکه امکان داره رکوردها رو استخراج کنند. اگر تولید RDBMS با دانستن این مطالب میسر بود، تا حالا شرکتهایی مثل Reg Gate و Idera که نرم افزارهای جانبی زیادی برای SQL Server دارند حتما این کار رو انجام داده بودند تا سودشون 100 برابر بشه. مسئله مهم اینه که در RDBMS ، بخشهای بسیار حساس تری وجود داره، مثل Query Processor که هوش مصنوعی هستش.
عرض بنده اینه: دانش ما در مورد Storage اونقدر کم نیست که نتونیم بفهمیم آیا اطلاعات، تصاعدی حجمشون زیاد میشه یا خیر. اینکه شما بعضی از مکانیزمهای داخل SQL Server رو کاملا بشناسید، نیازی به Open Source بودن اون نداره. بلکه کتابهای منتشر شده مثل Inside SQL Server یا Guru's Guild to SQL Server Internals درک عمیقی به شما میده. ضمنا کتاب Inside Storage Engine هم بزودی منتشر میشه. من دستوراتی میشناسم که در Books Online مستند نشده اما SQL Server پشتیبانی میکنه، یکی از این دستورات مثل DBCC PAGE اطلاعات بایت به بایت داخل یک Page رو گزارش میکنه به شکلی که از اتلاف حتی یک بایت داخل دیتابیس هم مطلع میشید!
اگر جواب من قانع کننده نیست میتونین به Communityهای مایکروسافت یا سایر Forumهای بین المللی سر بزنید تا از نظرات دیگران هم مطلع بشید.

[h_baqery]

آدرس وب لاگ آقای Paul Randal رو بدید همه استفاده کنن.

[AminSobati]

http://blogs.msdn.com/sqlserverstorageengine/rss.xml