Upgrade SQL Server 2005 Enterprise To SQL Server 2008 R2????

[mrmohsen]

با سلام خدمت تمام دوستان



دوستان من یه سرور دیتابیسی یه شرکتو Support میکنم در واقع Portal اون شرکته و تعداد 1000 یوزر از اون استفاده میکنند بار رو اون زیاده و کم کم حجم دیتابیس داره ار حالت غیر معمول خارح میشه و رسیده به 160GB و دیگه این نسخه SQL Enterprsie 2005 روش جواب نمیده و به این نتیجه رسبدم که SQL Server 2008 R2 رو نصب کنم حالا چند تا سوال دارم؟



1- اولا ریسک این موضوع چقدر است که یه وقت دیتابیس دچار مشکل بشه؟یا دیتابیس و از دست بدم؟؟؟؟

2- نحوه انتقال دیتابیس چطوره؟Attach , Dettach OR Backup Restore؟؟؟؟

3- آیا به ورژن 2008 R2 امکان Upgrade وجود داره؟؟؟؟؟



دوستان اگه یه راهنمایی کنن ممنون میشم

[in_chand_nafar]

دوست عزيز قبل از هر كاري اگر مي توانيد (در صورت امكان) ارتباط SQL Server را قطع كنيد و از بانك اطلاعاتي Backup تهيه كنيد
پس از آن SQL 2008 R2 را نصب و بانك اطلاعاتي را Restore كنيد
در ضمن پيشنهاد من اين است كه قبل از Upgrade سناريو Backup Restore را در يك سرور آزمايش پياده كرده برنامه هاي در ارتباط با اون بانك اطلاعاتي را تست و ....
در ضمن شما مي توانيد پروسه Upgrade را هم جلو ببريد منتها خود من اين كار را يكبار دو سال پيش هنگام ارتقا از 2005 به 2008 انجام دادم وسط كار با مشكل مواجه شدم و مجبور شدم سرور را از نوع تنظيم كنم (به اين نتيجه رسيدم كه اين كار را از اول انجام مي دادم بهتر بود)
در ضمن دوست عزيز حجم بانك اطلاعاتي شما براي SQL 2005 ناچيز بوده و اگر تنظيمات ايندكس و... را در بانك اطلاعاتي به خوبي انجام داده باشيد بايد بتوانيد به خوبي از اون جواب بگيريد
هنوز كه هنوز روي SQL 2000 سرويس پك 4 بانك اطلاعاتي (آرشيو الكترونيكي با حجم داده هاي باينري و داده زياد) با حجم 110 گيگابايت دارم كه به حداقل 100 يوزر سرويس مي ده و جوابگو است (قصدم از ذكر اين مثال اين بود كه قدرت SQL را كم در نظر نگيريد)

[mrmohsen]

مرسی دوست عزیز از پاسختون

یعنی بهتربن راحل برای این کار Backup و Restore هست ؟

Attach , Detach جوابگو نیست؟

خوب مسلما از ابتدا ساختن خیلی خوبه ولی ریسک از دست دادن دیتا پس چی؟

بله مسلما SQL2005 خیلی قدرتمنده من یه دیتا بیس دیگه دارم همیت امروز حجمش به 980 GB رسیده ولی user کمی روش هستن ولی پورتال استفاده بیش از حدی داره یعنی کله مجموعه وابسته بهش هست و ناچارم یه فکری براش کنم

[in_chand_nafar]

كليه اين كارها را در يك روز تعطيل و يا نصف شب و... انجام بده مثل شركت ها ديگه و... نمي دونم سناريو Disaster و... داري و يا خير
يادت باشه كه به لاگين SA كليه اين كارها را انجام بدي
1- ارتباط تمامي برنامه ها را با بانك اطلاعاتي قطع كن
2- تمامي sessionهايي كه به ازاي بانك اطلاعاتي وجود داره قطع (بانك را در حالت single User قرار بده) اين هم دستورش
USE master
GO
ALTER DATABASE TEST01 SET SINGLE_USER WITH ROLLBACK IMMEDIATE --ROLLBACK ALL CONNECTION
GO
ALTER DATABASE TEST01 SET SINGLE_USER WITH ROLLBACK AFTER 5 -- ROLLBACK ALL CONNECTION AFTER 5 SECONDS
GO
--قرار دادن بانك اطلاعاتي در حالت چند كاربره
ALTER DATABASE TEST01 SET MULTI_USER
GO
3- از بانك اطلاعاتي Backup بگير و حتما اين كار را انجام بده بعد (تا حداقل براي روز مبادا داشته باشي)
4- بانك اطلاعاتي را Detach كن
5- فايل هاي MDF,LDF را به سرور جديد و يا مسير جديد كپي كن
6- در سرور جديد و... بعد از نصب SQL فايل هاي بانك اطلاعاتي را Attach كن
7- با استفاده از دستور Dbcc ChekcDb صحت بانك اطلاعاتي را چك كن (اين كار بايد به طور مرتب براي تمامي بانك ها توسط ادمين و يا يك Job انجام شود)
8-لاگين هاي مورد نياز برنامه را ايجاد كن
9- Jobهاي مورد نياز براي بانك اطلاعاتي را ايجاد كن
10 - اصلاً تمامي Server Objectها را در سرور جديد ايجاد كن


دليل اين كه مي گم Backup بگير اين كه موقعي كه حجم بانك بالا است بايد خيلي مواظب بود و ريسك نكرد ممكن با detach كردن بانك اطلاعاتي در همان سرور Attach‌كردن بانك اطلاعاتي (مجداد در همان سرور) با مشكل مواجه بشي و داده هات رور از دست بدي اين مورد در SQL 2000 براي خودم پيش اومده و تنها چيزي كه من رو نجات داد Restore‌كردن FullBackup يك هفته قبل ، Restore كردن آخرين Differential Backup و Log Backup هاي بعد از Diff Backup از بانك اطلاعاتي بود.
يادت باشه آخر كار با دستور Dbcc CheckDB حتما بانك رو اط لحاظ صحت و سلامت چك كني