1 جدول شد 2 جدول - 11 مگ شد 32 مگ !!!

با سلام
من طه دیتا بیس داشتم که یه جدول با 11 ستون و 37000 رکورد داشت با یه تعداد جداول دیگه . حجم دیتابیسم 11 مگ بود . جدولم به شکل زیر بود:

itm_id,itm_nm,itm_sz,....

فیلد دومم یعنی itm_nmاز نوع nvarchar100 بود اما نام کالا ها امکان داشت تکرار بشه و...
من اومدم ای« جدول رو به شکل 2 جدول مجزا در اوردم:

item:     itm_id,Itm_bch_id , itm_sz,.....

و

item_bach:  itm_bch_id,itm_bch_nm

عد اطلاعاتم رو کانورت کردم تو این جدول و نامها دیگه توی جدول item_bach تکرار نمیشه و کدش توی جدول item میخوره تا به جای یه فیلد 100 تایی یه فیلد int تکرار بشه و بعد جدول قبلی item رو پاک کردم .
با اجازه تون حجم دیتابیسم شده 32 مگ
چرا؟؟؟؟

زمانی که اطلاعات (حجیم) به داخل جدول شما Insert میشه، دنبال فضای خالی نمیگرده تا اون رو Insert کنه، بلکه به انتهای فایل دیتابیس اضافه میشه. حتی وقتی یک جدول حجیم رو حذف میکنین، Pageهای آزاد شده الزاما بلافاصله مورد استفاده قرار نمیگیرند. فقط عمل Shrink هستش که باعث میشه حتما Pageهای خالی مورد استفاده قرار بگیرند. ولی اصلا Shrink توصیه نمیشه چون با وجود اینکه حجم دیتابیس رو میتونه کاهش بده، اما باعث بوجود آمدن Fragmentation میشه. زمانی که شما دیتابیستون که 32 مگابایت هست رو Zip کنین یا Backup بگیرین، متوجه کاهش حجم قابل ملاحظه اون خواهید شد. من جای شما باشم سعی نمیکنم حجم دیتابیس رو کم کنم چون با توجه به ارزان بودن سخت افزار (هارد دیسک) ارزش نداره تا به هر قیمتی حجم دیتابیس رو کاهش بدیم!

نقل قول:

---

نوشته شده توسط AminSobati

. من جای شما باشم سعی نمیکنم حجم دیتابیس رو کم کنم چون با توجه به ارزان بودن سخت افزار (هارد دیسک) ارزش نداره تا به هر قیمتی حجم دیتابیس رو کاهش بدیم!

---

اولا ممنون جناب AminSobati چون واقعا سوالی نیست که از زیر دستون بی جواب رد شه .
ضمنا من این دیتابیس رو واسه روی هاست طراحی کردم و باید بره روی هاست و با این قیمت های اسکیوال سروری هاست ها حجم کم غنیمته :شیطان:

خوب اگه حالا من دیتابیسم رو export کنم چی؟ جاهای خالی توی دیتابیس جدید هم لحاظ میشه یا نه؟
ممنون

وقتی Export میکنین این بهترین حالته، چون جدول به جدول اطلاعات پر میشه و بصورت بهینه از فضای دیتابیس استفاده میشه. اما شما در محاسبه حجم دیتابیس آیا فضای Log File رو هم منظور کردین؟ حجم Data File الان برای شما مهمه، ولی Log File رو اگر Shrink کنین مشکلی از لحاظ Fragmentation نخواهد بود.

من حجم هر دو رو روی هم گفتم . datafile من 23 مگ هستش .
ضمنا srink یعنی چی؟

نقل قول:

---

نوشته شده توسط hamed_bostan

من حجم هر دو رو روی هم گفتم . datafile من 23 مگ هستش .
ضمنا srink یعنی چی؟

---

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

شرینک در لغت به معنای جمع کردن است. در SQl Server ما هنگامی که یک فایل رو Shrink میکنیم فصاهای خالی بین page ها در فایل با جا به جا شدن page ها پر میشود. به عبارتی یک page از انتهای فایل می آید در وسط فایل و درنهایت هم فضهای خالی از انتهای فایل را حدف میکند که این باعث میشود حجم فایل کم بشود. ولی مشکل کجاست. هنگامی که داده های ما بیشتر از یک page شود(که 100 درصد اینطور خواده بود) اطلاعات در page های متوالی ذخیره میشود. به طوریکه page اول به page بعد از خودش یعنی دوم اشاره میکند و همینطور دوم به سوم و... . هد هارد دیسک به ترتیب و با سرعت اینها را پشت سر هم میخواند .حالا اگر page ها مرتب نباشد مثلا" page اول در ابتدای فایل به page شماره دو در انتهای فایل اشاره کند و... بدترین وضعیت برای هد هارد دیسک خواهد بود که باعث افت پرفرمنس میشود.
در این حالت است که باید index ها و.. را مرتب کرد. یا از نو ساخت.

نقل قول:

---

نوشته شده توسط DonetKarvb

ولی مشکل کجاست. هنگامی که داده های ما بیشتر از یک page شود(که 100 درصد اینطور خواده بود) اطلاعات در page های متوالی ذخیره میشود. به طوریکه page اول به page بعد از خودش یعنی دوم اشاره میکند و همینطور دوم به سوم و... . هد هارد دیسک به ترتیب و با سرعت اینها را پشت سر هم میخواند .حالا اگر page ها مرتب نباشد مثلا" page اول در ابتدای فایل به page شماره دو در انتهای فایل اشاره کند و... بدترین وضعیت برای هد هارد دیسک خواهد بود که باعث افت پرفرمنس میشود.
در این حالت است که باید index ها و.. را مرتب کرد. یا از نو ساخت.

---

خوب حالا ما نفهمیدیم shrink خوبه یا بد؟ استفاده کنم یا نه؟

نقل قول:

---

نوشته شده توسط hamed_bostan

خوب حالا ما نفهمیدیم shrink خوبه یا بد؟ استفاده کنم یا نه؟

---

در مجموع زمانی که فضا دارید نه. راستش با سرعت زیاد پیشرفت سخت افزار به خصوص در زمینه حافظه ها زیاد معقول نیست که shrink بکنید. ولی از طرفی به خاطر هزینه های بالای هاستینگ شما میتونید شرینک بکنید و بعد هم ایندکس ها رو Defrag یا Rebuild کنید.(البته اگر permission بدهند.)
یه نکته ای رو هم عرض کنم که همین عملیات ساختن ایندکس و یا defrag آنها یک Cost بالایی دارد که به Sherink کردن نمی ارزد. ولی بازم خودت دودوتا 4تا کن

زمانی که برای Defrag مجددا ایندکسها رو Rebuild میکنین مجددا حجم دیتابیس نیاز داره که افزایش پیدا کنه، و وقتی حجمش زیاد شد لازم میشه Shrink کنین و وقتی Shrink کردین باز مجبورین Rebuild کنین و وقتی ....!
پس Shrink روی Data File در حالت عادی توصیه نمیشه. ولی در این مورد خاص (Host)، به خاطر صرفه جویی در فضا شاید ناگزیر باشیم. اما بعدش Rebuild نکنین. فقط Shrink کردن Log File بلامانعه

نقل قول:

---

نوشته شده توسط AminSobati

زمانی که برای Defrag مجددا ایندکسها رو Rebuild میکنین مجددا حجم دیتابیس نیاز داره که افزایش پیدا کنه، و وقتی حجمش زیاد شد لازم میشه Shrink کنین و وقتی Shrink کردین باز مجبورین Rebuild کنین و وقتی ....!
پس Shrink روی Data File در حالت عادی توصیه نمیشه. ولی در این مورد خاص (Host)، به خاطر صرفه جویی در فضا شاید ناگزیر باشیم. اما بعدش Rebuild نکنین. فقط Shrink کردن Log File بلامانعه

---

یه سوال:مگر فضایی که برا Rebuild و Defrag کردن میخواد از از دیتابیس tempDB نمیگره؟

در ضمن ممنون می شم بهم بگین این اصطلاح page که به کار می برین توی sql server چی هست؟ اطلاعات توی sql server به صورت فیزیکی چطوری ذخیره سازی می شن؟ ممنون

نقل قول:

---

نوشته شده توسط hamed_bostan

در ضمن ممنون می شم بهم بگین این اصطلاح page که به کار می برین توی sql server چی هست؟ اطلاعات توی sql server به صورت فیزیکی چطوری ذخیره سازی می شن؟ ممنون

---

با سلام
اطلاعات در SQL Server ابتدا در واحد های کوچک به نام page ذخیره میشوند که هر page ظرفیتی معادل 8KB را اشغال میکند. هر 8 عدد page در کنار هم یک extent را ایجاد میکنند. در نتیجه هر Extent ظرفیتش 64KB است.
اگر تصویری از این حالت بخواهیم داشته باشیم به صورت زیر خواهد بود:

http://i17.tinypic.com/2l8yg77.jpg
(ببخشید نقایشم خوب نبود.)

تو سطر اول این شکل ما فقط یک page داریم که این page میتونه اطلاعات یک مربوط به یک تیبل رو در خودش ذخیره کنه که بر اساس حجم داده ها تعداد page ها هم بالا میرود.
و اما سطر دوم همه یکدست آبی رنگ هستند. 8 عدد page که مربوط به یک جدول میباشد یک Extent را پر کرده اند که یه این نوع Uniform Extent میگوند در Extent بعدی هم که page ها از اطلاعات جداول مختلف پر شده است . نوع دوم را Mixed Extent نام گذاری میکنند.
حالا نحوه ذخیره سازی Lorge Object به گونه ای دیگر می باشد که تو Books Online بیان کرده.
امیدوارم درست منظورم را بیان کرده باشم.

یک عکس قشنگتر از books Online پیدا کردم حیفم اومد اینجا نذارمش.

http://i19.tinypic.com/33bjtav.jpg

برای اطلاعات بیشتر به این لینک هم تو Books Online میتونید مراجعه کنید.

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/ddc311fe-f3cc-4e99-b86b-43ce822ceda3.htm

نقل قول:

---

نوشته شده توسط DonetKarvb

یه سوال:مگر فضایی که برا Rebuild و Defrag کردن میخواد از از دیتابیس tempDB نمیگره؟

---

بعد از اینکه رکوردها Sort شدن در Tempdb، مجددا Pageها باید پشت سر هم نوشته بشن که طبیعتا در جای قبلی نمیتونه بصورت پیوسته بنویسه (اگر میتونست که دیگه جدول Fragmentation نداشت!). لذا به فضای خالی در انتهای دیتابیس نیاز پیدا میکنه

خوب واسه defragment کردن دیتابیس یا در اصل Page ها چیکار باید کرد و ایآ این عمل چه معایبی داره؟

Alter Index all on Customers

Rebuild



Alter Index all on Customers

REORGANIZE 

• به دو صورت میشه یک جدول رو Defrag کرد. آنلاین و آفلاین. در حالت آنلاین از تیبل میشه استفاده کرد ولی در حالت آفلاین خیر.
• اگر حجم داده ها زیاد باشد زمانبر خواهد بود.

بعلاوه پست قبلی، از Reorganize زمانی استفاده کنین که مقدار Fragmentation کمتر از 30 درصد باشه. و در صورت بیشتر بودن، Rebuild استفاده کنین. اگر از 10 درصد کمتر بود، اصلا ارزش Defrag نداره.
البته دستوراتی که دوست عزیزم آقای DonetKarvb اشاره کردند در SQL Server 2005 وجود داره. در 2000 از DBCC باید استفاده کرد. همچنین دستور CREATE INDEX ... WITH DROP_EXISTING که برای Defrag کاربرد داره، در هر دو ورژن موجوده.
برای تشخیص مقدار Fragmentation در 2000 از DBCC SHOWCONTIG استفاده میشه و در 2005 از sys.dm_db_index_physical_stats

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