Всього крок потрібно зробити , це запустити Upgrade Advisor на базі SQL Server 2000 і розглянути всі питання , повідомив їм.
Як найкраща практика, використовуйте інструмент Upgrade Advisor у застарілій базі даних SQL Server 2000 та імпортуйте файл трасування в інструмент Upgrade Advisor для аналізу. Файл трасування дозволяє Пораднику з оновлення виявити проблеми, які можуть не відображатися при простому скануванні бази даних, наприклад, TSQL, вбудованому в програми. Ви можете фіксувати сліди TSQL за допомогою SQL Profiler на своєму сервері SQL Server 2000 протягом типових годин та аналізувати ці сліди за допомогою Advisor Upgrade Advisor.
Тож решта кроків:
У день міграції:
- скриптуйте наші входи на сервер 2000 за допомогою sp_help_revlogin .
- Сценарій завдань і пов'язаних серверів з сервера sql 2000.
- припинити підключення веб-серверів до сервера 2000. Переконайтесь, що жоден додаток не підключається до сервера 2000.
- створіть резервні копії баз даних та відновіть на сервері призначення sql 2008 R2. (зверніть увагу: не від'єднуйте / приєднуйте, оскільки все може піти не так, і ви отримаєте окрему базу даних та не створюйте резервних копій!)
- Після відновлення резервних копій на сервері 2008 R2, запустіть висновок із sp_help_revlogin на сервері R2 2008 R2, щоб відновити входи в систему.
- Синхронізуйте сирітських користувачів (якщо такі є) та відтворіть завдання агента sql та пов'язані сервери на новому сервері.
- змінити рівень сумісності відновлених баз даних на 100.
- Dbcc checkdb із увімкненими параметрами all_errormsgs та data_purance:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- запустіть DBCC UPDATEUSAGE на відновлених базах даних
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- Оновіть статистику для всіх таблиць при повному скануванні:
Update Statistics table_name with FULLSCAN
- Необов’язково: Перевірте рівні фрагментації та, залежно від рівня фрагментації, запустіть реорганізацію / перебудову всіх індексів. Ви можете використовувати сценарії Ola .
- Перекомпілюйте всі використовувані SP
sp_recompile 'procedureName'
- Оновіть свої погляди
SP_REFRESHVIEW view_name
- переконайтеся, що ви зміните параметр бази даних: сторінку підтвердити на CHECKSUM.
- Змініть модель відновлення (якщо вона відрізняється від sql 2000) на FULL. Якщо ви перейдете на ПОЛУНУЮ модель відновлення, ПЕРЕКОНАЙТЕ, що ви часто робите резервні копії журналу транзакцій. Це допоможе вам відновити момент часу, а також не розмивати свій T-Log.
У SQL Server 2005 і новіших версіях була введена база даних Mail . Тож вам доведеться перейти з SQLMail до пошти баз даних.
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
Крім того, якщо у вас є реплікація, вам доведеться її скинути. Якщо будь-яка ДР, наприклад логшинг або Дзеркальне відображення (нова в 2005 році і вище, але знецінилася в 2012 році), вам доведеться скинути її також.
Старі пакети DTS потрібно перенести на SSIS за допомогою C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe(командного рядка) або за допомогою майстра міграції пакетів .
Також ви можете використовувати мій сценарій, знайдений на веб- сайті /dba//a/36701/8783 . Хоча він використовує метод від'єднання / прикріплення, я настійно рекомендую використовувати метод BACKUP / RESTORE . Змініть сценарій відповідно.
Як бічна примітка:
- увімкніть миттєву ініціалізацію файлів на новому сервері.
- Майте кілька файлів даних tempdb однакового розміру.
- Увімкнути прапор трасування 1118
- Налаштуйте максимум та мінімум пам’яті правильно. Особливо Макс пам'яті далеко за замовчуванням.
- Правильно відрегулюйте настройки MAXDOP. Детальнішу інформацію див. На /dba//a/36578/8783 .
- Найкраще встановити sp_Blitz від Brent Ozar. Запустіть його та вирішіть важливі та пріоритетні проблеми, про які повідомляє він.
- Ви навіть можете використовувати SQL Power Doc від кендальвандике - SQL Power Doc працює з усіма версіями SQL Server від SQL Server 2000 до 2012 року, а також усіма версіями Windows Server та споживчими операційними системами Windows від Windows 2000 та Windows XP через Windows Server 2012 та Windows 8. Також корисно для планування оновлень - подивіться, які приховані функції використовуються в екземплярі.
- Увімкнути Оптимізація для спеціальних навантажень та параметрів стиснення резервного копіювання за замовчуванням.
Дозволяє вирішити ваші запитання ...
Що ще потрібно зробити, щоб міграція завершилася?
Зверніться до моєї відповіді. Це допоможе вам правильно скласти план міграції. Завжди перевіряйте свій план міграції в UAT (не виробництво) разом з належним тестуванням додатків діловими користувачами.
використовувати нові функції, такі як контрольна сума та модель повного відновлення.
CHECKSUMє новим у SQL Server 2005 та новіших версіях. Я висвітлював це як частину етапів міграції, описаних вище.
full recovery modelне є новим. Це залежить від типу вашого бізнесу та диктує, скільки даних ви можете втратити у випадку катастрофи.
Повний режим відновлення з частими резервними копіями журналу транзакцій дозволить вам відновити момент часу та зменшити кількість втрат даних.
зробити цю базу такою, якою вона була створена в SQL Server 2008 R2.
зробити цю базу даних повністю сумісною, правильною та ідеально підходить для нового двигуна баз даних SQL 2008 R2.
Не розумійте цього повністю! Але вище етапи міграції допоможуть вам. Вам просто потрібно відновити базу даних і змінити рівень сумісності 10 100разом з вищезазначеними кроками.
Я просто хочу знати, як правильно і повністю перетворити стару базу даних SQL Server 2000 в нову базу даних 2008 R2, будьте спокійні, що все зроблено правильно, і будьте задоволені всіма новими можливостями.
Ви повинні бути обережними з цим, оскільки це вимагатиме змін і до коду програми. Якщо ваш код програми змінено на використання нових функцій у SQL Server 2008 R2, то у вас не виникне жодних проблем - ПРЕДОСТАВЛЕНО, що ви повністю виконали повне тестування регресії вашої програми в середовищі UAT або DEV. Це надасть вам найкращу впевненість, коли ви робите фактичну міграцію в PROD.
Примітка. Наведені вище кроки, які я міг запам'ятати, і я впевнений, що нічого не залишилося. Якщо я побачу, що я пропустив якісь речі, то додам його чи інших експертів на цьому веб-сайті - сміливо додайте!
Все, що описано вище, потрібно спочатку відтворити в середовищі NON PRODUCTION, щоб уникнути сюрпризів під час фактичної міграції.
----------
Ще кілька питань:
Ви рекомендуєте використовувати метод резервного копіювання / відновлення, але я зробив, як написано вище, тож чи можу я зіткнутися з будь-якими проблемами зараз? Все працювало без жодних проблем.
Якщо все спрацювало нормально, і ви змогли долучити базу даних, то НІ у вас не виникне жодних проблем. Detach / Attach vs резервне копіювання / відновлення - це лише метод того, як ви переміщуєте свою базу даних в інше місце. Просто FYI .. Резервне копіювання / відновлення є більш безпечним і надійним, як якщо б щось пішло не так (у гірших випадках), то принаймні у вас є резервна копія для відновлення та відновлення вашої бази даних.
Про контрольну суму та повну модель відновлення: вона не була доступна / включена на SQL Server 2000, тому я хочу їх зараз використовувати. Ви сказали, що єдине, що мені потрібно зробити, це включити ці параметри у властивостях бази даних? Я десь читав, що цього недостатньо, і я також повинен будувати індекси чи щось таке. Я насправді не знаю, я просто прошу.
Як я вже сказав, контрольна сума є новою у версії 2005 та новіших версій. Це механізм, за допомогою якого SQL Server виявлятиме пошкодження сторінки, особливо завдяки I / O. Дивіться мою відповідь тут для отримання більш детальної інформації.
Щоб увімкнути CHECKSUM, а також змінити модель відновлення на FULL, ви можете зробити це, використовуючи нижче T-SQL-код:
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
Примітка. Після встановлення параметрів бази даних вона зберігатиметься під час міграції з 2008R2 на 2012 рік.
Я готуюсь перенести цю базу даних на SQL Server 2012 - тож спочатку це було з 2000 по 2008 рік R2, тепер буде з 2008 року в R2 по 2012 рік (це було неможливо зробити безпосередньо через відсутність підтримки 2000 баз даних у SQL Сервер 2012). Тож я розумію, що я повинен слідувати вашому посібнику: створити резервну копію у 2008 R2 та відновити у 2012 році, а потім виконати решту ваших порад, правда?
Так, будь ласка. Як я вже говорив, відновлення резервного копіювання є кращим методом, якщо у вас немає вагомих причин цього не робити.
Поясніть, будь ласка, метод резервного копіювання / відновлення: це схоже на скидання бази даних до SQL-запитів, а потім відновлення, виконавши купу запитів? Чи допоможе цей метод шляхом дефрагментації моєї бази даних? Якщо ні, як дефрагментацію / оптимізацію вручну?
Резервне копіювання / відновлення ... схоже на дамп і завантаження, що використовується в Sybase, Oracle або, можливо, також у MySQL. Його просто SQL Server викликає .. резервне копіювання / відновлення.
Необхідно прочитати: Розуміння резервних копій SQL Server від Пола Рендала.
Простий синтаксис (для повного синтаксису зверніться до BOL ):
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
Тоді відновлення можна зробити на сервері призначення у вигляді:
- якщо припустити, що диск диска призначення не відповідає вихідному серверу
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
move 'logical_data_fileName' to 'physical_path\database_name.mdf'
move 'logical_log_fileName' to 'physical_path\database_name_log.ldf'
with recovery, stats = 10
- припускаючи, що розташування диска призначення збігається з вихідним сервером
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
Чи допоможе цей метод шляхом дефрагментації моєї бази даних? Якщо ні, як дефрагментацію / оптимізацію вручну?
резервне копіювання / відновлення не дефрагментує вашу базу даних. Ви повинні використовувати Alter Index Reorganize або Rebuild в залежності від рівня вашої фрагментації.
Оскільки ви новачок у SQL Server, я б дуже рекомендував вам використовувати Ola Hallengren:
Оскільки ми використовували SQL Server 2000 Express протягом багатьох років (без інтерфейсу управління), ми робили резервні копії просто, зупиняючи двигун та RAR каталог DATA. Наразі, як ми працюємо на SQL Server 2008, хіба це ще не краще, ніж використання функції резервного копіювання в студії управління?
Зупинка двигуна - це найгірше, що ви можете зробити для резервного копіювання !!
Прочитайте посилання Пола про резервні копії, про які я згадував, та використання сценарію Оли. Microsoft має статтю KB із сценарієм для автоматичного резервного копіювання - Як планувати та автоматизувати резервні копії баз даних SQL Server у SQL Server Express
Повний режим відновлення з частими резервними копіями журналу транзакцій - Де зберігається журнал транзакцій - це файл LDF? Як я можу зробити це резервним копієм належним чином?
Кожна база даних SQL Server має журнал, який записує всі транзакції та модифікації бази даних, що здійснюються кожною транзакцією. Журнал транзакцій є критичним компонентом будь-якої бази даних.
Звичайне розширення для імен для журналу транзакцій - ".LDF", але воно може бути будь-яким.
Я не збираюсь більше писати про це, оскільки це зробить відповідь дуже порядною. Зверніться до управління журналом
транзакцій, і моя відповідь тут також має чудові посилання.
РЕДАКТ: 24.08.2016 .. Це допоможе майбутнім читачам:
Якщо ви переносите весь свій екземпляр з однієї версії на іншу, настійно рекомендую використовувати рішення на базі PowerShellStart-SqlMigration
