Yapılacak en önemli adım , Yükseltme Danışmanı'nı SQL Server 2000 veritabanında çalıştırmak ve rapor ettiği tüm sorunları gidermektir.
En iyi uygulama olarak, SQL Server 2000 eski veritabanınızdaki Yükseltme Danışmanı aracını kullanın ve analiz için Yükseltme Danışmanı aracına bir izleme dosyası alın. İzleme dosyası, Yükseltme Danışmanı'nın uygulamalara gömülü TSQL gibi basit bir veritabanı taramasında görünmeyebilecek sorunları algılamasını sağlar. SQL Server 2000 sunucunuzdaki SQL Profiler'ı kullanarak tipik saatlerde TSQL izlerini yakalayabilir ve Yükseltme Danışmanı'nı kullanarak bu izleri analiz edebilirsiniz.
Yani adımların geri kalanı şöyle olurdu:
Göç gününde:
- sp_help_revlogin kullanarak oturum açma işlemlerimizi 2000 sunucusunda kodlayın .
- Sql 2000 sunucusundan işleri ve bağlantılı sunucuları kodlayın.
- 2000 sunucuya bağlanan web sunucularını durdurun. Hiçbir uygulamanın 2000 sunucusuna bağlanmadığından emin olun.
- Veritabanlarınızı yedekleyin ve varış noktası sql 2008 R2 sunucusuna geri yükleyin . (not: İşler ters gidebileceğinden bağlantıyı kesmeyin / eklemeyin, ayrı bir veri tabanına sahip olacaksınız ve yedeklemeyeceksiniz!)
- Yedeklemeleriniz 2008 R2 sunucusuna geri yüklendikten sonra, girişleri yeniden oluşturmak için çıktıyı 2008 R2 sunucusundaki sp_help_revlogin'den çalıştırın.
- Yetim kullanıcıları (varsa) senkronize edin ve yeni sunucudaki sql aracısı işlerini ve bağlantılı sunucuları yeniden oluşturun.
- geri yüklenen veritabanlarındaki uyumluluk düzeyini 100 olarak değiştirin.
- Dbcc checkdb, all_errormsgs ve data_purity seçenekleriyle açık:
DBCC CHECKDB ('<db_name_goes_here>' ) WITH ALL_ERRORMSGS,NO_INFOMSGS, DATA_PURITY
- geri yüklenen veritabanlarında DBCC UPDATEUSAGE komutunu çalıştırın
DBCC UPDATEUSAGE('database_name') WITH COUNT_ROWS
- Tam tarama ile tüm tablolardaki istatistikleri güncelleyin:
Update Statistics table_name with FULLSCAN
- İsteğe bağlı: Parçalanma seviyelerini kontrol edin ve parçalanma seviyesine bağlı olarak, tüm Endekslerin yeniden oluşturulmasını / yeniden oluşturulmasını çalıştırın. Ola'nın komut dosyalarını kullanabilirsiniz .
- Tüm SP’leri kullanarak derle
sp_recompile 'procedureName'
- Görünümlerinizi yenileyin
SP_REFRESHVIEW view_name
- veritabanı seçeneğini değiştirdiğinizden emin olun: sayfa CHECKSUM ile doğrulayın.
- Kurtarma modelini (sql 2000'den farklıysa) FULL olarak değiştirin. TAM kurtarma modeline geçerseniz, İşlem Günlüğü'nü sık sık yedeklediğinizden emin olun. Bu, T-Log'unuzu şişirmemenizin yanı sıra, hem anında hem de iyileşmenizi sağlayacak
SQL Server 2005 ve daha yeni sürümlerinde Database Mail tanıtıldı. Bu yüzden SQLMail'den Database Mail'e geçmelisiniz.
USE [master]
GO
sp_configure 'show advanced options',1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO
Ayrıca, herhangi bir çoğaltmanız varsa, sıfırlamanız gerekir. Herhangi bir DR, logshipping veya Mirroring gibi (2005 ve sonraki yıllarda yeni, ancak 2012 yılında amortismana tabi tutulmuşsa), o zaman da sıfırlamanız gerekir.
Eski DTS paketlerinin C:\Program Files\Microsoft SQL Server\100\DTS\Binn\DTSMigrationWizard.exe(komut satırı) veya Paket Taşıma Sihirbazı kullanılarak SSIS'e geçirilmesi gerekir .
Ayrıca, /dba//a/36701/8783 adresinde bulunan betiğimi kullanabilirsiniz . Ayır / attach yöntemini kullanmasına rağmen, BACKUP / RESTORE yöntemini kullanmanızı şiddetle tavsiye ediyorum . Komut dosyasını buna göre değiştirin.
Yan not olarak:
- açmak Anında Dosya başlatma yeni sunucuda.
- Var çoklu veri dosyaları, tempdb eşit boyutta.
- Izleme Bayrağını Etkinleştir 1118
- Maksimum ve minimum belleği doğru şekilde yapılandırın. Özellikle de varsayılan olarak azami bellek.
- MAXDOP ayarlarını doğru şekilde yapın. Daha fazla ayrıntı için /dba//a/36578/8783 adresine bakın .
- Brent Ozar'dan sp_Blitz'i kurmak en iyisidir . Çalıştırın ve bildirdiği kritik ve yüksek öncelikli sorunları ele alın.
- Hatta SQL Power Doc'u kendalvandyke'den de kullanabilirsiniz - SQL Power Doc, SQL Server 2000'den 2012'ye kadar tüm SQL Server sürümleriyle ve Windows Server ve Windows 2000'den Windows XP ve Windows XP'den Windows Server ve tüketici Windows İşletim Sistemlerinin tüm sürümleriyle çalışır 8. Yükseltmeleri Planlama için de faydalıdır - bir örnekte hangi gizli özelliklerin kullanıldığını görün.
- Geçici iş yükleri ve Varsayılan yedekleme sıkıştırma seçenekleri için En İyileştir'i etkinleştirin.
Sorularınızı ele alalım ...
Geçişi tamamlamak için başka ne yapmalıyım?
Cevabımı bakın. Düzgün bir göç planı ile gelip yardımcı olacaktır. Geçiş planınızı her zaman işletme kullanıcıları tarafından uygun uygulama testleriyle birlikte bir UAT'de (üretim dışı) test edin.
sağlama toplamı ve tam kurtarma modeli gibi yeni özellikler kullanın.
CHECKSUMSQL Server 2005 ve üzeri yeni. Yukarıda açıklanan göç adımlarının bir parçası olarak ele aldım.
full recovery modelyeni değil İş türünüze bağlıdır ve felaket durumunda ne kadar veri kaybedebileceğinizi belirler.
Sık İşlem günlüğü yedekleriyle birlikte tam kurtarma modu, zaman içinde geri yükleme yapmanıza olanak sağlar ve burada veri kaybı miktarını azaltır.
bu veritabanının tam olarak SQL Server 2008 R2'de oluşturulduğu gibi olmasını sağlayın.
bu veritabanının tam uyumlu, doğru ve yeni SQL 2008 R2 veritabanı motoru için uygun olmasını sağlayın.
Bunu tam olarak anlama! Ancak yukarıdaki göç adımları size yardımcı olacaktır. Yalnızca veritabanını geri yüklemeniz ve 100yukarıdaki adımlarla birlikte uyumluluk düzeyini 10 değiştirmeniz gerekir .
Eski SQL Server 2000 veritabanını nasıl doğru ve tam olarak yeni 2008 R2 veritabanına dönüştüreceğimi bilmek istiyorum, her şeyin doğru yapıldığından emin olun ve tüm yeni özelliklerden memnun olun.
Uygulama kodunuzda da değişiklik yapmanız gerekeceğinden, bu konuda dikkatli olmalısınız. Uygulama kodunuz, SQL Server 2008 R2'deki yeni özellikleri kullanacak şekilde değiştirildiyse, herhangi bir sorunla karşılaşmazsınız - PROVIDED, uygulamanızın bir UAT veya DEV ortamında tam bir regresyon testi yaptığınızı tam olarak bildirmediniz. PROD uygulamasındaki asıl geçişi yaptığınızda bu size en iyi güveni sağlayacaktır.
Not: Yukarıda hatırlayabildiğim adımlar var ve hiçbir şeyin dışarıda bırakılmadığından eminim. Bazı şeyleri kaçırdığımı görürsem, bu siteye ya da diğer uzmanlara ekleyeceğim - eklemek için çekinmeyin!
Yukarıda ana hatları çizilen her şeyin, asıl geçiş sırasında herhangi bir sürpriz yaşanmaması için önce NON ÜRETİM olmayan bir ortamda tekrar oynatılması gerekir.
----------
Birkaç soru daha var:
Yedekleme / geri yükleme yöntemini kullanmanızı öneririz, ancak yukarıda yazıldığı gibi yaptım, şimdi herhangi bir sorunla karşılaşabilir miyim? Her şey sorunsuz çalıştı.
Her şey yolunda giderse ve veritabanını ekleyebilseniz, HAYIR herhangi bir sorun yaşamayacaksınız. Çıkar / Bağla vs Yedekle / Geri Yükle, veri tabanınızı / veritabanlarınızı farklı bir yere nasıl taşıdığınızı gösteren bir yöntemdir. Sadece FYI .. Yedekleme / Geri Yükleme , herhangi bir şey ters giderse (en kötü durumlarda) sanki daha sonra güvenli bir şekilde daha güvenli ve güvenilirdir;
Sağlama toplamı ve tam kurtarma modeli hakkında: SQL Server 2000'de kullanılabilir / etkin değildi, bu yüzden şimdi kullanmak istiyorum. Yapmam gereken tek şeyin veritabanı özelliklerinde bu seçenekleri etkinleştirmek olduğunu söylediniz. Bir yerde okudum, bu yeterli değil ve aynı zamanda indeksleri veya başka bir şeyi yeniden oluşturmalıyım. Gerçekten bilmiyorum, sadece soruyorum.
Dediğim gibi, sağlama toplamı 2005 ve daha yeni sürümlerde yeni. SQL Server'ın özellikle G / Ç nedeniyle sayfa bozulmasını algıladığı bir mekanizmadır. Daha fazla ayrıntı için buradaki cevaba bakın .
CHECKSUM'u etkinleştirmek ve kurtarma modelini FULL olarak değiştirmek için, aşağıdaki T-SQL kodunu kullanarak yapabilirsiniz:
USE master;
GO
ALTER DATABASE [your_database_name] -- change this !!
SET RECOVERY FULL, PAGE_VERIFY CHECKSUM;
GO
Not: Veritabanı seçeneklerini belirledikten sonra, 2008R2'den 2012'ye geçiş yaptığınızda kalıcı olur.
Bu veritabanını SQL Server 2012'ye taşımayı hazırlıyorum - bu yüzden ilk önce 2000'den 2008 R2'ye, şimdi de 2008'den R2'ye 2012 olacak (SQL'de 2000 veritabanını desteklemediği için bunu doğrudan yapmak imkansızdı. Sunucu 2012). Bu yüzden rehberinizi takip etmem gerektiğini anladım: 2008 R2’de yedekleyin ve 2012’de geri yükleyin, sonra diğer ipuçlarını yerine getirin, değil mi?
Evet lütfen. Söylediğim gibi, geri yüklemeyi yapmamak için iyi bir nedeniniz yoksa tercih edilen yöntemdir.
Lütfen bana yedekleme / geri yükleme yöntemini açıklayın: SQL sorgularına bir veritabanı dökümü gibi ve daha sonra bir sürü sorgu yürüterek geri yükler mi? Bu arada bu arada benim veritabanı "birleştirme"? Değilse, manuel olarak nasıl birleştirebilir / optimize edebilirsiniz?
Yedekleme / geri yükleme ... Sybase, Oracle veya muhtemelen MySQL'de kullanılan damping ve load'a benzer. Onun sadece SQL Server onu çağırır .. yedekleme / geri yükleme.
A okumak gerekir: Paul Randall tarafından SQL Server Yedekleri Anlamak .
Basit Sözdizimi (Tam sözdizimi için BOL bakın ):
backup database database_name
to disk = 'D:\backup\database_name_full.bak'
with init, stats =10
Ardından, geri yükleme işlemi hedef sunucuda şu şekilde yapılabilir:
- hedefin disk düzeninin kaynak sunucununkiyle eşleşmediğini varsayarsak
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
- hedefin disk düzeninin kaynak sunucununki ile eşleştiğini varsayarsak
restore database database_name
from disk = 'D:\backup\database_name_full.bak'
with recovery, stats = 10
Bu arada bu arada benim veritabanı "birleştirme"? Değilse, manuel olarak nasıl birleştirebilir / optimize edebilirsiniz?
yedekleme / geri yükleme veritabanınızı birleştirmez. Parçalanma seviyenize bağlı olarak Alter Index Reorganize veya Rebuild kullanmak zorundasınız.
SQL Server’da yeni olduğunuzdan, Ola Hallengren’in:
Yıllardır SQL Server 2000 Express kullandığımızdan (yönetim arayüzü yok), sadece motoru ve RAR DATA dizinini durdurarak yedekleme yapıyorduk. Şimdilik, SQL Server 2008'de olduğumuz gibi, Management Studio'da yedekleme işlevini kullanmaktan daha iyi değil mi?
Motoru durdurmak, yedekleme yapmak için yapabileceğiniz en kötü şeydir !!
Paul'un bahsettiğim yedekler ve Ola'nın senaryosunu kullan ile ilgili bağlantısını oku. Microsoft, otomatik yedeklemeler yapacak bir komut dosyası içeren bir KB makalesine sahiptir - SQL Server Express'teki SQL Server veritabanlarının yedeklerini zamanlama ve otomatikleştirme
Sık İşlem günlüğü yedekleriyle birlikte tam kurtarma modu - İşlem günlüğü nerede depolanır - LDF dosyası mı? Nasıl düzgün yedeklerim?
Her SQL Server veritabanında, tüm işlemleri ve her işlem tarafından yapılan veritabanı değişikliklerini kaydeden bir günlük bulunur. İşlem günlüğü, herhangi bir veritabanının kritik bir bileşenidir.
İşlem günlüğü için normal adlandırma kuralı uzantısı '.LDF'dir, ancak herhangi biri olabilir.
Bunun üzerine daha fazla yazmayacağım çünkü bu, cevabı çok küçümseyecektir. İşlem Günlüğü Yönetimi'ne bakın
ve buradaki cevabımın da mükemmel bağlantıları var.
EDIT: 24.07.2016 .. Bu gelecekteki okuyuculara yardımcı olacaktır:
Tüm örneğinizi bir sürümden başka bir sürüme geçiriyorsanız, PowerShell tabanlı çözümü kullanmanızı şiddetle tavsiye ederimStart-SqlMigration
