Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Günlük aktarımı, genellikle farklı bilgisayarlarda bulunan tek bir veritabanının iki kopyasını kapsar. Herhangi bir zamanda, şu anda veritabanının yalnızca bir kopyası istemciler tarafından kullanılabilir. Bu kopya birincil veritabanı olarak bilinir. İstemciler tarafından birincil veritabanına yapılan güncelleştirmeler, veritabanının ikincil veritabanı olarak bilinen diğer kopyasına günlük gönderimi yoluyla yayılır. Günlük gönderimi, birincil veritabanında yapılan her ekleme, güncelleştirme veya silme işleminden işlem günlüğünün ikincil veritabanına uygulanmasını içerir.
Günlük aktarımı, aşağıdaki davranışlarla birlikte replikasyonla birlikte kullanılabilir:
Günlük aktarma yük devrinden sonra çoğaltma devam etmez. Yük devretme gerçekleşirse, çoğaltma aracıları ikincil sunucuya bağlanmaz; bu nedenle işlemler abonelere çoğaltılmaz. Birincil sunucuya geri geçiş gerçekleşirse, replikasyon devam eder. İkincil kopyalardan birincile gönderim kopyalarını günlüğe kaydeden tüm işlemler Abonelere çoğaltılır.
Birincil kalıcı olarak kaybolursa, çoğaltmanın devam edebilmesi için ikincil yeniden adlandırılabilir. Bu konunun geri kalanında bu olayı işlemeye yönelik gereksinimler ve yordamlar açıklanmaktadır. Verilen örnek, log shipping için en yaygın kullanılan veritabanı olan yayın veritabanıdır, ancak benzer bir süreç abonelik ve dağıtım veritabanları için de uygulanabilir.
Çoğaltmayı yeniden yapılandırmaya gerek kalmadan çoğaltmaya katılan veritabanlarını kurtarma hakkında bilgi için bkz. Çoğaltılan Veritabanlarını Yedekleme ve Geri Yükleme.
Note
Yayın veritabanı için kullanılabilirlik sağlamak üzere, günlük aktarma yerine Always On kullanılabilirlik gruplarını kullanın. Daha fazla bilgi için bkz. Always On kullanılabilirlik gruplarıyla çoğaltmayı yapılandırma.
Birincil Kaybedilirse İkincilden Çoğaltma için Gereksinimler ve Yordamlar
Aşağıdaki gereksinimlere ve dikkat edilmesi gerekenlere dikkat edin:
Birincil veritabanı birden fazla yayın veritabanı içeriyorsa, günlük tüm yayın veritabanlarını aynı ikincil veritabanına gönderir.
İkincil sunucu örneğinin yükleme yolu birincil sunucuyla aynı olmalıdır. İkincil sunucudaki kullanıcı veritabanı konumları birincil sunucudakiyle aynı olmalıdır.
Hizmet ana anahtarını birincil sunucuda yedekleyin. Bu anahtar ikincilde geri yüklenecektir. Daha fazla bilgi için bkz BACKUPSERVICEBACKUP SERVICE MASTER KEY . (Transact-SQL).
İşlem günlüğü gönderimi veri kaybına karşı garanti sağlamaz. Birincil veritabanındaki bir hata, henüz yedeklenmemiş verilerin veya hata sırasında kaybolan yedeklemelerin kaybolmasına neden olabilir.
İşlemsel Çoğaltma ile İşlem Günlüğü Aktarımı
İşlemsel çoğaltma için günlük aktarımının davranışı, yedekleme ile eşitle seçeneğine bağlıdır. Bu seçenek, yayın veritabanında ve dağıtım veritabanında ayarlanabilir; Publisher için günlük aktarmada yalnızca yayın veritabanındaki ayar dikkate alınır.
Yayın veritabanında bu seçeneğin ayarlanması, işlemlerin yayın veritabanında yedeklenene kadar dağıtım veritabanına teslim edilmemesini sağlar. Son yayın veritabanı yedeklemesi, dağıtım veritabanının geri yüklenen yayın veritabanının sahip olmadığı işlemlere sahip olma olasılığı olmadan ikincil sunucuda geri yüklenebilir. Bu seçenek, Publisher'ın ikincil bir sunucuya geçmesi durumunda Publisher, Dağıtımcı ve Aboneler arasında tutarlılığın korunmasını garanti eder. İşlemler Publisher yedeklenmeden dağıtım veritabanına teslim edilemediğinden gecikme süresi ve aktarım hızı etkilenir; uygulamanız bu gecikme süresini tolere edebilirse, yayın veritabanında bu seçeneği ayarlamanızı öneririz. Yedekleme ile eşitleme seçeneği ayarlanmadıysa aboneler, ikincil sunucuda kurtarılan veritabanına artık dahil olmayan değişiklikleri alabilir. Daha fazla bilgi için Anlık Görüntü ve İşlemsel Çoğaltmayı Yedekleme ve Geri Yükleme Stratejileri konusuna bakın.
Yedeklemeyle eşitle seçeneğiyle işlemsel çoğaltmayı ve günlük gönderimini yapılandırmak için
Yayın veritabanında yedekleme ile eşitleme seçeneği ayarlanmadıysa,
sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'komutunu yürütün. Daha fazla bilgi için bkz. sp_replicationdboption (Transact-SQL).Yayın veritabanı için günlük aktarmayı yapılandırın. Daha fazla bilgi için bkz. Log Shipping'i (SQL Server) Yapılandırma.
Publisher başarısız olursa, veritabanının son işlem günlüğünü ikincil sunucuya RESTORE LOG'un KEEP_REPLICATION seçeneğini kullanarak geri yükleyin. Bu, veritabanı için tüm çoğaltma ayarlarını korur. Daha fazla bilgi için bkz. Günlük Gönderimi İkincil 'e (SQL Server) yük devretme ve RESTORE (Transact-SQL).
msdb veritabanını ve ana veritabanlarını birincilden ikincil veritabanına geri yükleyin. Daha fazla bilgi için bkz. Sistem Veritabanlarını (SQL Server) Yedekleme ve Geri Yükleme. Birincil de bir Dağıtımcı ise, dağıtım veritabanını birincilden ikincile geri yükleyin.
Bu veritabanları, çoğaltma yapılandırması ve ayarları açısından birincildeki yayın veritabanıyla tutarlı olmalıdır.
İkincil sunucuda bilgisayarı yeniden adlandırın ve ardından SQL Server örneğini birincil sunucu adıyla eşleşecek şekilde yeniden adlandırın. Bilgisayarı yeniden adlandırma hakkında bilgi için Windows belgelerine bakın. Sunucuyu yeniden adlandırma hakkında bilgi için bkz. SQL Server Stand-Alone Örneğini Barındıran Bilgisayarı Yeniden Adlandırma ve SQL Server Yük Devretme Kümesi Örneğini Yeniden Adlandırma.
İkincil sunucuda, birincil sunucudan yedeklenen hizmet ana anahtarını geri yükleyin. Daha fazla bilgi için bkz RESTORESERVICERESTORE SERVICE MASTER KEY . (Transact-SQL).
Yedeklemeyle eşitleme seçeneği olmadan işlemsel çoğaltmayı ve günlük gönderimini yapılandırmak için
Yayın veritabanı için günlük aktarmayı yapılandırın. Daha fazla bilgi için bkz. Log Shipping'i (SQL Server) Yapılandırma.
Publisher başarısız olursa, veritabanının son işlem günlüğünü ikincil sunucuya RESTORE LOG'un KEEP_REPLICATION seçeneğini kullanarak geri yükleyin. Bu, veritabanı için tüm çoğaltma ayarlarını korur. Daha fazla bilgi için bkz. Günlük Aktarımı İkincil Sunucusuna Yük Devretme (SQL Server) ve RESTORE (Transact-SQL).
msdb veritabanını ve ana veritabanlarını birincilden ikincil veritabanına geri yükleyin. Daha fazla bilgi için bkz. Sistem Veritabanlarını (SQL Server) Yedekleme ve Geri Yükleme. Birincil de bir Dağıtımcı ise, dağıtım veritabanını birincilden ikincile geri yükleyin.
Bu veritabanları, çoğaltma yapılandırması ve ayarları açısından birincildeki yayın veritabanıyla tutarlı olmalıdır.
İkincil sunucuda bilgisayarı yeniden adlandırın ve ardından SQL Server örneğini birincil sunucu adıyla eşleşecek şekilde yeniden adlandırın. Bilgisayarı yeniden adlandırma hakkında bilgi için Windows belgelerine bakın. Sunucuyu yeniden adlandırma hakkında bilgi için bkz. SQL Server Stand-Alone Örneğini Barındıran Bilgisayarı Yeniden Adlandırma ve SQL Server Yük Devretme Kümesi Örneğini Yeniden Adlandırma.
Günlük Okuyucu Aracısı'ndan, yayın veritabanı ile dağıtım veritabanının senkronize olmadığını belirten bir hata iletisi alabilirsiniz.
İkincil sunucuda, birincil sunucudan yedeklenen hizmet ana anahtarını geri yükleyin. Daha fazla bilgi için bkz RESTORESERVICERESTORE SERVICE MASTER KEY . (Transact-SQL).
sp_replrestart yürüt. Bu saklı yordam, Günlük Okuyucu Aracısı'nın yayın veritabanı günlüğündeki daha önce çoğaltılan tüm işlemleri yok saymasını sağlamak için kullanılabilir. Saklı yordam tamamlandıktan sonra uygulanan işlemler Günlük Okuyucu Aracısı tarafından işlenir. Daha fazla bilgi için bkz. sp_replrestart (Transact-SQL).
Saklı yordam başarıyla yürütüldükten sonra Günlük Okuyucusu Aracısı'nı yeniden başlatın. Daha fazla bilgi için bkz. Replikasyon Ajanı Başlat ve Durdur (SQL Server Management Studio) bölümünü inceleyebilirsiniz.
Aboneye zaten dağıtılmış olan işlemler Publisher'da uygulanabilir. Distribution Agent’ın, bu işlemleri Abone üzerinde yeniden uygulamaya çalışırken bir hatayla başarısız olmamasını sağlamak için Veri Tutarlılığı Hatalarında Devam Et adlı aracı profilini belirtin.
Birleştirme Çoğaltması ile Günlük Aktarımı
Birleştirme çoğaltmasını ve günlük gönderimini yapılandırmak için aşağıdaki yordamda yer alan adımları izleyin.
Birleştirme çoğaltmasını ve günlük gönderimi yapılandırmak için
Yayın veritabanı için günlük aktarmayı yapılandırın. Daha fazla bilgi için bkz. Log Shipping'i (SQL Server) Yapılandırma.
Publisher başarısız olursa, ikincil sunucuda bilgisayarı yeniden adlandırın ve ardından SQL Server örneğini birincil sunucu adıyla eşleşecek şekilde yeniden adlandırın. Bilgisayarı yeniden adlandırma hakkında bilgi için Windows belgelerine bakın. Sunucuyu yeniden adlandırma hakkında bilgi için bkz. SQL Server Stand-Alone Örneğini Barındıran Bilgisayarı Yeniden Adlandırma ve SQL Server Yük Devretme Kümesi Örneğini Yeniden Adlandırma.
RESTORE LOG'un KEEP_REPLICATION seçeneğini kullanarak veritabanının son işlem günlüğünü ikincil sunucuya geri yükleyin. Bu, veritabanı için tüm çoğaltma ayarlarını korur. Daha fazla bilgi için bkz. Günlük Gönderimi İkincil 'e (SQL Server) yük devretme ve RESTORE (Transact-SQL).
msdb veritabanını ve ana veritabanlarını birincilden ikincil veritabanına geri yükleyin. Daha fazla bilgi için bkz. Sistem Veritabanlarını (SQL Server) Yedekleme ve Geri Yükleme. Birincil de bir Dağıtımcı ise, dağıtım veritabanını birincilden ikincile geri yükleyin.
Bu veritabanları, çoğaltma yapılandırması ve ayarları açısından birincildeki yayın veritabanıyla tutarlı olmalıdır.
İkincil sunucuda, birincil sunucudan yedeklenen hizmet ana anahtarını geri yükleyin. Daha fazla bilgi için bkz RESTORESERVICERESTORE SERVICE MASTER KEY . (Transact-SQL).
Yayın veritabanını bir veya daha fazla abonelik veritabanıyla eşitleyin. Bu, daha önce yayın veritabanında yapılan ancak geri yüklenen yedeklemede temsil edilmeyen değişiklikleri karşıya yüklemenize olanak tanır. Karşıya yüklenebilen veriler, yayının filtrelenme şekline bağlıdır:
Yayın filtrelenmemişse, yayın veritabanını en güncel Abone ile eşitleyerek güncel duruma getirebilmeniz gerekir.
Yayın filtrelenmişse, yayın veritabanını güncelleyemeyebilirsiniz. Her aboneliğin yalnızca tek bir bölge için müşteri verilerini alması için bölümlenmiş bir tablo düşünün: Kuzey, Doğu, Güney ve Batı. Her veri bölümü için en az bir Abone varsa, her bölüm için bir Abone ile eşitlenmesi, yayın veritabanını güncel hale getirmelidir. Ancak, örneğin Batı bölümündeki veriler herhangi bir aboneye çoğaltılmadıysa, Yayıncıdaki bu veriler güncel hâle getirilemez. Bu durumda, Yayımcı ve Abonelerdeki verilerin uyumlu hâle gelmesi için tüm abonelikleri yeniden başlatmanızı öneririz. Daha fazla bilgi için bkz. Abonelikleri Yeniden Başlatma.
SQL Server 2005 (9.x) tarihinden önce SQL Server sürümünü çalıştıran bir Abone ile eşitleme yaparsanız abonelik anonim olamaz; bir istemci aboneliği veya sunucu aboneliği olmalıdır (önceki sürümlerde yerel abonelikler ve genel abonelikler olarak adlandırılır). Daha fazla bilgi için bkz. Verileri Eşitleme.
Ayrıca Bkz.
SQL Server Eşleme
Log Shipping Hakkında (SQL Server)Always On kullanılabilirlik gruplarıyla çoğaltmayı yapılandırma