none
SQL Server 2008'den alınan backup'ı SQL Server 2005 üzerine restore etmek. RRS feed

  • Genel Tartışma

  • Selamlar,

    ERP tarafında kullandığımız makinadan (SQL Server 2005) her gece full backup alıp, rapor (SQL Server 2005) makinamıza restore ediyorduk. Bu sayede raporlar farklı bir makina üzerinden alınarak sistem yavaşlatılmamış oluyor.

    ERP makinamız üzerindeki SQL Server'ı 2008 versiyona upgrade ettik, Bazı teknik durumlardan dolayı Rapor makinamız SQL Server 2005 olarak çalışmak durumunda. Fakat böyle olunca SQL Server 2008'den aldığımız full backup'ı SQL Server 2005'e restore edemiyoruz. "SQL Server cannot process this media family" şeklinde hata alıyoruz.

    "Full script text" ve "Export import" işlemleri de minimum 150GB gibi bir veriyi aktarmada saatler alacağından bu yöntemleri de kullanamıyoruz.

    Bu konu ile alakalı bir çözüm varsa destek almak istiyoruz.

    iyi çalışmalar.

    • Değiştirilmiş Tür Serkan Bark 23 Haziran 2011 Perşembe 07:04
    16 Haziran 2011 Perşembe 11:32

Tüm Yanıtlar

  • Merhaba,
    Her gece full backup yerine iki makine arasında eğer koşullar uygunsa log shipping tanımlanabilir veya yine farklı bir çözüm olan replikasyon da sorununuzu çözebilir.
    17 Haziran 2011 Cuma 06:10
  • Benim aklıma Snapshot Replication geliyor, %100 demiyorum, ama teoride bana işe yarar gibi geliyor; bunu araştırmanda fayda var. Merge ve Transactional Replication kurulumlarını pratikte de bazı projelerde uyguladım, ama seninki gibi bir senaryo ile bir projede henüz karşılaşmadığımızdan bunu pratikte denememiştim. O yüzden çok net bir şey diyemiyorum, ama teoride olur gibi görünüyor ve Snapshot Replication'ın kullanımı senin durumuna da uygun. Sonuçta sadece günde bir kere ve komple taşımak istiyorsun veritabanını.
    Ekrem Önsoy - MCDBA, MCITP:DBA+DBD, MCSD.Net, MCSE, ITILv3, SQL Server MVP | http://ekremonsoy.blogspot.com
    17 Haziran 2011 Cuma 14:32
  • Sefa bu işlem için İsmail'in ve Ekrem'in belirttiği tüm yöntemleri kullanabilirsin fakat bir kaç düzeltme yapmak istiyorum. Buna göre en doğru seçeneği seçebilirsin.

    Log Shipping asıl amacı High Availibility olan bir mekanizmadır. Logların restore edilmesi sürecinden dolayı, sürekli olarak Raporlama makinanızı Recovery modda tutar. Bu da raporlama makinanızı etkin kullanamayacağınız anlamına gelir. O yüzden bu seçeneği es geçmenizi öneririm.

    Ekrem'in söylediği seçenekler daha cazip olmakla beraber Merge Replication senin sisteminde uygun değil. Performans kaybı yaşarsın. Snapshot replication işinizi görür ama 150 GB biraz zahmetli olur her seferinde.

    Benim sana önerim Transactional replication seçeneğini kullanmandır. Böylece sadece ilk seferde snapshot rep. çalışıp daha sonra sadece değişen veriler için (transactional) bir replikasyon süreci çalışır.

    Hatta bu işlemi berirttiğin zaman aralıklarında da sistemin yapmasını isteyebilirsin.

    Yine de asıl durumu sen bildiğin ve yaşadığın için tercih ettiğin çözüm yolunu bizimle paylaşırsan sevinirim.

    Engin Demiroğ,MCT,engin@yazilimdevi.com

    http://www.yazilimDevi.com

     

    26 Haziran 2011 Pazar 15:56
  • Merhabalar,
    Ek bilgi olarak,

    Log  shipping kullanırsanız secondary server üzerinde tutulan veritabanını restoring moddan stand by moda alarak primary server daki veritabanının read only bir kopyasını elde ederek raporlama için uygun ortam sağlanabilir.  

    26 Haziran 2011 Pazar 16:09
  • Zaten standby moda alınmazsa, raporlama makinası bu veri tabanını kullanamaz. Stand by moda alınmazsa bir işe yaramaz zaten.

    Fakat daha önce belirttiğim gibi log shippingle kullanılmaya çalışılan veritabanı verimli olmayacaktır. Performans kaybı ve bakım zorlukları ortaya çıkar. Mesela raporlama makinasında yeni bir index yapısı oluşturulamaz, index defragmantation çalışmaları yapılamaz. Etkin kullanılamaz yani.

    Bu arada yine ek bilgi :) log shipping sql server 2008 ile beraber Microsoft tarafından depreceated duruma düşürülmüştür. Artık bu teknolojiyi önermeyip yerine Database Mirroring mekanizması önerilmektedir. Tamamen önceki sürümlerle uyumluluk amaçlı barındırılıyor şu an.

    Engin Demiroğ,MCT,engin@yazilimdevi.com

    http://www.yazilimDevi.com

    26 Haziran 2011 Pazar 18:13