SQL Server Detach-Attach İşlemi

Bu başlık altında, SQL Server‘ın hizmet verdiği veri tabanlarında .mdf ve .ldf file’ların bulunduğu diskler altındaki pathlerin yerlerini değiştirme işlemi olan Detach-Attach işlemini örnekler ile anlatacağız. Öncelikle bir veri tabanını bir yerden başka bir yere taşımaya neden ihtiyaç duyarız? Kaynak yetersizliği Domain değişikliği Sürüm yükseltme Disk Performansı Yukarıdakilere ek olarak başka birçok neden bu işlemin yapılmasına neden olabilir. .Mdf, .ndf ve .ldf file’ların taşınması için aşağıdaki yöntemlere ek olarak kendi sisteminize uygun yöntemler ile yapabilirsiniz. Backup-restore Detach-attach Generate script (Data and Schema) Yukarıda bahsi geçen yöntemler arasından Detach – Attach yöntemini sizlere anlatmaya çalışacağım. Bu işlem yapılırken kesinlikle uzmana danışarak yapılmalı ve büyük database’lerde problem ile karşılaşılabileceği göz önünde bulundurulmalı. Ve tercih olarak biz bu işlemin yapılmasında SSMS ile değil Query ekranı ile yapılmasının daha sağlıklı olduğu düşünüyoruz. Detach işlemi: “DETACH” komutu, bir veri tabanının SQL sunucusundan ayrılmasını sağlayan bir işlemdir. Detach işlemi, veri tabanını sunucudan kaldırırken, veri tabanın fiziksel […]

SQL Server Detach-Attach İşlemi

Bu başlık altında, SQL Server‘ın hizmet verdiği veri tabanlarında .mdf ve .ldf file’ların bulunduğu diskler altındaki pathlerin yerlerini değiştirme işlemi olan Detach-Attach işlemini örnekler ile anlatacağız.

Öncelikle bir veri tabanını bir yerden başka bir yere taşımaya neden ihtiyaç duyarız?

  1. Kaynak yetersizliği
  2. Domain değişikliği
  3. Sürüm yükseltme
  4. Disk Performansı

Yukarıdakilere ek olarak başka birçok neden bu işlemin yapılmasına neden olabilir.

.Mdf, .ndf ve .ldf file’ların taşınması için aşağıdaki yöntemlere ek olarak kendi sisteminize uygun yöntemler ile yapabilirsiniz.

  1. Backup-restore
  2. Detach-attach
  3. Generate script (Data and Schema)

Yukarıda bahsi geçen yöntemler arasından Detach – Attach yöntemini sizlere anlatmaya çalışacağım. Bu işlem yapılırken kesinlikle uzmana danışarak yapılmalı ve büyük database’lerde problem ile karşılaşılabileceği göz önünde bulundurulmalı. Ve tercih olarak biz bu işlemin yapılmasında SSMS ile değil Query ekranı ile yapılmasının daha sağlıklı olduğu düşünüyoruz.

Detach işlemi: “DETACH” komutu, bir veri tabanının SQL sunucusundan ayrılmasını sağlayan bir işlemdir. Detach işlemi, veri tabanını sunucudan kaldırırken, veri tabanın fiziksel dosyalarını kaldırmaz. Bu işlemi yapma sebebimiz, SQL Server’ın hizmet verdiği diğer veri tabanlarının hizmetini aksatmadan yani SQL Server sevice kapatmadan istediğimiz veri tabanında yapabilmek için yapıyoruz.

Öncelikle bir veri tabanını taşımamız gereken durumlarda Detach – Attach yöntemini kullanacak olursak ve veri tabanı dosyalarının nerede tutulduğunu bilmiyorsak tutulduğu yeri öğrenmemiz gerekiyor. Bunun için aşağıda belirtmiş olduğum scriptler çalıştırılarak dosya konumu belirlenebilir.

Siz scriptlerde bulunan “test” veri tabanı yerine konumunu bulmak istediğiniz kendi veri tabanınızın ismini yazmalısınız. Aynı zamanda SQL Server’ın path’lerinin nerede tutulduğu bilgisini işlemden önce not etmelisiniz. Bu bilgileri Not edebilmek için aşağıdaki yöntemleri kullanabilirsiniz.

  1. Database ⇒ Properties ⇒ Files ⇒ path bilgisinin ekran görüntüsü alınır.

 

 

  1. select database_id from sys.databases where name=‘test’

        select physical_name from sys.master_files where database_id =6

 

İlk query’i çalıştırdığımızda ‘test’ veri tabanının master file’de hangi database id ile tutulduğunu öğreniyoruz. Ardından aşağıdaki query’i çalıştırarak veri tabanımızın path’lerinin tutulduğu dosya konumunu öğrenebiliriz.

 

  1. use [test]

        select * from sys.database_files

  1. use test

        go

        exec sp_helpfile

 

 

  1. sp_helpdb‘test’

Dosya konumunu bulduğumuz veri tabanında Detach işlemini gerçekleştirmeden herhangi bir taşıma işlemi yapmaya çalıştığımızda aşağıda bulunan hata penceresi ile karşılaşırsınız.

 

 

Bunun nedeni veri tabanınızın connectionların açık olmasından kaynaklanmaktadır.

Detach işlemi tam da burada devreye giriyor.

Detach İşlemi

Dosya konumlarını taşımak istediğiniz veri tabanı üzerine Sağ tık ⇒ Task ⇒  Detach adımlarını izlediğimizde aşağıdaki pencere karşımıza çıkar.

 

Açılan pencerede detach işlemine devam edebilmek için en önemli aşama “Drop Connections” tiki işaretlenmelidir. Aksi takdirde “Message” altında bulunan açıklama alanındaki ‘Active Connections’ drop edilemeyecektir. “Status” kısmında ‘Not Ready’ yazması aktif connectionlar olduğu anlamına gelmektedir.

 

 

Ayarlamaları yaptıktan sonra sayfanın üst tarafında bulunan “Script” kısmına tıklıyarak Query ekranında Scriptimizi açıyoruz ve çalıştırıyoruz.

 

 

Veri tabanı Detach edildiğinde ilişkili kullanıcı izinleri ve yapılandırmaları kaybolabilir. Veri tabanını yeniden bağladığınızda, bu izinleri ve yapılandırmaları yeniden tanımlamanız gerekebilir.

Attach İşlemi

Bu kısımda Detach ettiğimiz veri tabanımızın .mdf, .ndf ve .ldf dosyalarını taşımak istediğimiz dosya konumuna getiriyoruz. Ben “test” isimli veri tabanı dosyalarını C:\SQL dosya konumundan C:\SQL_NEW isimli yeni bir dosya konuma taşıdım.

Taşıma işleminin ardından SQL Server’da Databases sağ tık yaparak açılan pencerede “Attach” seçeneğine tıklayarak Attach işlemine başlayabiliriz.

Açılan pencerede ‘Databases to attach’ kısmının altında bulunan ‘Add…’ kısmında tıklayarak dosya konumunu belirlediğimiz  veri tabanımızın .mdf dosyasını seçiyoruz. (Bu kısımda sadece .mdf dosyası görünür ve biz bu .mdf dosyasını seçip OK seçeneğine tıklıyoruz.)

 

 

‘MDF File Location’ = .mdf dosyasının yeni konumunu açıklar.

‘Database Name’ = veri tabanı adını açıklar.

‘Attach As’ = Eğer veri tabanımıza yeni bir isim vermek istiyorsak burada yeniden adlandırma yapabiliriz. (ben NEW_DB adını verdim. İlk isminin geçerli olmasını istiyorsanız burada herhangi bir işlem yapmanıza gerek kalmayacak otomatik olarak ilk ismini SQL Server kendisi yazacaktır.)

Burada dikkat edilecek önemli bir konu .mdf ve varsa .ndf dosyalarının aynı dosya konumu içinde bulunmasıdır. Aksi takdirde ‘Attach’ işleminde hata alınacaktır.

Ayarlamaları yaptıktan sonra sayfanın üst tarafında bulunan “Script” kısmına tıklıyarak Query ekranında Scriptimizi açıyoruz ve çalıştırıyoruz.

 

 

Arkadaşlar bu şekilde “Detach – Attach” işlemini tamamlamış bulunuyoruz. Umarım çalışmalarınıza katkıda bulunabilmişimdir. İyi Çalışmalar 🙂

 

 

 

 

 

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 hafta önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 1 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 1 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele