20 Ekim 2010 Çarşamba

Yanyana Sürüm Yükseltme Kontrol Listesi (Side by side upgrade check list) : SQL Server 2005 ve üstü için...

Selam arkadaşlar,

Aşağıda, kendi çalışmalarımda iki sunucu arasında taşıma yaparken aşağıdaki kontrol listesini kullanıyorum. Sizin de işinize yarayabileceğini düşünerek burada da sizlerle paylaşmak istedim bu listeyi.

Örneğin hangi durumda kullanıyorum bu listeyi? Bir sunucumuz var, fakat donanım olarak artık değiştirilmesi gerekiyor. Eski SQL Server Instance'ının donanım olarak daha iyi bir sunucuya taşınması gerekiyor. İşte bu gibi durumlarda bu liste benim çok işime yarıyor.

Listeyi ihtiyacınıza göre güncelleyebilirsiniz veya gözünüze çarpan bir şey varsa bana da bildirebilirsiniz, ben de listeyi ona göre güncellerim.

Listede Database Mirroring veya Log Shipping gibi konular şimdilik yok, belki ileride bu konulardaki en iyi pratikleri de bu listeye ekler ve burada güncellerim; ama şimdilik bunlar yok.

Temel olarak listeyi üç bölüme ayırdım. İlk aşamada, taşıma öncesi işlemler yapılıyor. İkinci aşamada, taşıma sırasında yapılacaklar. Üçüncü aşamada da taşımalardan sonra yapılacaklar var.


İLK AŞAMA (GEÇİŞ ÖNCESİ)
• WINDOWS
o Computer Management: SQL Server'da kullanılan yerel Windows hesaplarının aktarılıp aktarılmadığı, aktarıldıysa da doğru yetkilerle aktarıldığı kontrol edilmeli.
o Computer Properties: System Properties->Advanced->Performance->Performance Options->Advanced->Processor scheduling: Adjust for best performance of ”Background services” ve Memory usage: Adjust for best performance of ”Memory usage” olmalı.
o NIC (Public): File and Printer Sharing for Microsoft Network Properties->”Maximize data throughput for file sharing” olduğundan emin olunmalı.
o Local Security Policy: SQL Server Database Engine için kullanılan servis hesabının şu Policy'lerde hakkının olduğundan emin olunmalı: “Lock Pages in Memory”, “Perform Volume Maintenance”, “Log on as a service”.
o SSCM: Yeni sunucudaki SQL Server servislerinin eski sunucudaki SQL Server servis hesaplarını kullanıp kullanmadığı kontrol edilmeli.
o SSMS: SQL Server Database Engine servis hesabının Active Directory'ye erişimi olduğundan emin olunmalı. Bunu kontrol etmek için aşağıdaki komut kullanılabilir.

xp_logininfo 'kullanıcı adı'

• SQL SERVER
o Server Properties: Ayarlar taşınacak.
o Security: Login'ler taşınacak.

EXEC sp_help_revlogin2

Not: Bu Script'e şu adresten ulaşabilirsiniz:

o Security: Login’lerin Server Level Role’leri çıkarılacak ve hedefte Login’lere üyelikleri verilecek. Aşağıdaki Script’ler kullanılabilir.
SELECT s.name, s.type_desc, p.permission_name, p.state_desc FROM sys.server_principals s INNER JOIN sys.server_permissions p ON s.principal_id = p.grantee_principal_id
WHERE permission_name <> 'CONNECT SQL' AND type_desc <> 'CERTIFICATE_MAPPED_LOGIN' ORDER BY s.name

SELECT p1.name AS UserName, p2.name AS RoleName FROM sys.server_principals p1 JOIN sys.server_role_members m ON p1.principal_id = m.member_principal_id
JOIN sys.server_principals p2 ON m.role_principal_id = p2.principal_id

o Security: Sistem veritabanlarındaki kullanıcı hakları ve veritabanı rolleri de taşınacak.
o Security: Credential'lar taşınacak. Örnek kod aşağıdadır.

EXEC sp_xp_cmdshell_proxy_account 'domain\proxy_adı', 'şifresi'

o Server Objects: Linked Server'lar taşınacak. Taşıma yapıldıktan sonra Linked Server’ların bağlantı kurup kuramadığı test edilecek.
o Server Objects: Server Level DDL Trigger'lar taşınacak.
o Management: SQL Server Log'lar için hedefte ayar yapılıp yapılmadığı kontrol edilecek. (Varsayılan değer = 50)
o Management: Database Mail Account ve Profile'ları aktarılacak.
o Management: Legacy bir bileşen kullanılıyorsa onlar aktarılacak.
o SQL Server Agent: SQL Server Agent ayarları aktarılacak.
o SQL Server Agent: Proxy’ler taşınacak ve Create Script’leri oluşturularak durumlarının “Enabled” olduğu teyit edilecek. Şayet “Enabled” değillerse, o zaman aşağıdaki kod yardımıyla “Enabled” duruma getirilecekler.

EXEC msdb.dbo.sp_update_proxy @proxy_name = N'proxy adı', @enabled = 1

o Security: Proxy’leri kullanan Login’ler aşağıdaki sorgu ile tespit edilip ve bu Login’lere ilgili Proxy’ler için kullanım yetkisi verilmeli.
SELECT DISTINCT j.name as job_name, l.name as login_name, j.enabled FROM msdb..sysjobs j INNER JOIN msdb..sysjobsteps js ON j.job_id = js.job_id INNER JOIN master..syslogins l ON j.owner_sid = l.sid WHERE js.subsystem = 'SSIS' ORDER BY 2

EXEC msdb.dbo.sp_grant_login_to_proxy @proxy_name=N'proxy_adı', @login_name=N'domain\login_adı'

o SQL Server Agent: Job'lar taşınacak.
o SQL Server Agent: Her pazar günü yeni Error Log kullanılması için eğer yoksa bir Job oluşturulmalı. ("exec sp_cycle_errorlog" kullanılarak)
o SQL Server Agent: Operator'ler aktarılacak.
o Query Editor: Disabled olan Job’ların listesi alınacak. Bunun için aşağıdaki komut kullanılabilir.

SELECT j.name, l.name FROM master..syslogins l INNER JOIN msdb..sysjobs j ON l.sid = j.owner_sid WHERE j.enabled = 0)

o SSIS: SSIS Paketleri taşınacak. Eğer doğrudan hedefteki Integration Services'a aktarım yapılacaksa, o zaman aktarım sırasında Protection Level "Rely on server storage and roles for access control" olarak seçilmeli. Eğer doğrudan hedefin Integration Services'ına erişilemiyorsa, o zaman paket dosya sistemindeki bir klasöre Protection Level'ı "Encrypt sensitive data with password" olarak seçilerek kaydedilmelidir. Paket hedefte içe aktarılırken kaynakta paket dosya sistemine aktarılırken kullanılan şifre kullanılacaktır.
o SSMS: Detach edilecek veritabanlarının CREATE DATABASE Script’leri alınır ve her bir veritabanı için oluşturulan CREATE DATABASE Script’inin sonuna FOR ATTACH komutu eklenir.
o SSMS: Her bir veritabanı için ikinci aşamada Detach işleminin daha hızlı yapılabilmesi için Detach Script’leri hazırlanır.
o SSMS: Sistem veritabanlarında oluşturulmuş nesneler varsa (tablolar, SP’ler vs.) hedef sunucuya taşınmalı.

İKİNCİ AŞAMA (GEÇİŞ)
• SQL SERVER
o SSMS: Veritabanlarını Detach etmek için önceden hazırlanan Detach Script’leri kullanılır.
o SAN Bölümü: Diskler taşınacak. Tempdb diski, geri dönme olasılığı göz önüne alınarak taşınmayacak. Aynı harfle, yeni sunucu için aynı boyutta yeni bir disk verilecek.
o Sistem Alt Yapı Bölümü: Yeni sunucunun adını ve IP bilgilerini değiştirecek, varsa Share’ler kullanıcı haklarıyla beraber taşınacak.


ÜÇÜNCÜ AŞAMA (GEÇİŞ SONRASI)
• SQL SERVER
o Query Editor: Windows tarafında bilgisayar adı değiştirildikten sonra “sp_dropserver 'old_name'” ve “sp_addserver 'new_name', local” komutları çalıştırılacak. Daha sonra “SELECT @@SERVERNAME” komutu çalıştırarak sağlama yapılacak.
o Query Editor: Tempdb dosyalarının yolu, yeni verilen disk gösterilecek şekilde değiştirilir. Örnek kod aşağıdadır.

USE tempdb
GO
EXEC sp_helpfile
GO
USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'X:\Sqldata\tempdb.mdf')
GO
USE master GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'X:\Sqllog\templog.ldf')
GO

o Query Editor: İşlemci sayısı kadar Tempdb veri dosyası olduğu teyit edilir, yoksa olması sağlanır.
o Databases: Veritabanları, önceden hazırlanan CREATE DATABASE ... FOR ATTACH Script’leri kullanılarak Attach edilecek.
o Databases: Veritabanlarında Orphaned User olup olmadığı kontrol edilecek.
o Security: (Varsa) Credential’ların Domain isimleri yeni bilgisayar adına göre düzenlenecek.
o Management: Database Mail Account’larının çalışıp çalışmadığı (test e-postası gönderilerek) test edilecek.
o Security: Yerel Windows Login’leri tekrar oluşturulacak.
o SQL Server Agent: Credential değişikliği nedeniyle bazı Job’larda Job Owner için kullanılan kullanıcı adı geçerliliğini yitirmiş olabileceğinden dolayı Job Owner’lar kontrol edilecek.

Hiç yorum yok: