Sql verileri kopyalanıyor. MS SQL Server veritabanının düzenli yedeklerinin ayarlanması. Basit ve Tam güncelleme modellerinde yedekleme prensibi

MS SQL Server veritabanındaki bir tabloyu kopyalamanın birçok yolu vardır. Tablonun bir kopyasını oluşturmak için seçenekler listesini inceliyorum. Hangisinin seçileceği tablonun yapısına, içindeki indekslerin, tetikleyicilerin vb. varlığına ve gerekli el çalışmasına bağlıdır.

1. Tablo yapısını kopyalamanın manuel yöntemi

Microsoft SQL Management Studio'da bir veritabanı seçin, bir tablo seçin, sağ tıklayın ve “Komut Dosyası Tablosu” -> “ŞUNA OLUŞTUR” -> “Yeni Sorgu Düzenleyici Penceresi” öğelerini seçin. Pencerede tabloyu oluşturmak için gereken kod görüntülenecektir. Veritabanının adını belirtmeniz gerekir; bu durumda tablonun bir kopyasını almanız gerekir ve veritabanı değiştirilmiyorsa yeni bir ad vermeniz gerekir. Tablodaki yapıyı oluşturmaya yönelik kodun nasıl oluşturulacağı aşağıdaki resimde gösterilmiştir.

Bu yöntemi kullanarak tablo dizinleri oluşturulacak ancak tetikleyiciler kopyalanmayacaktır. Benzer şekilde kopyalanmaları gerekir.

Verileri önceden oluşturulmuş bir tabloya kopyalamak için aşağıdaki SQL'i kullanmanız gerekir:

..tmp_tbl_Deps'e EKLEYİN ..tbl_Deps'TEN SEÇ *

2. SQL tablosunu tek satıra kopyalamak

Bir veritabanının ortasında tablonun ve veri yapısının bir kopyasını oluşturun:

tbl_Deps'ten tmp_tbl_Dep'e * SEÇİN

Tablo yapılarını ve verileri bir veritabanından diğerine kopyalayın:

..tbl_Deps'TEN ..tmp_tbl_Deps'e * SEÇİN

Bu çözümün dezavantajı indekslerin kopyalanmamasıdır.

Bu makale, ek Microsoft SQL Server Management Studio programını kullanarak veritabanınızın yeni bir yedek kopyasını manuel olarak nasıl oluşturacağınızı anlatacaktır.

1. Yedek kopya oluşturun

Gerçekte her şeyin yapılması kolaydır. Ekipmanı piyasaya sürüyoruz" » (« Başlangıç» — « tüm programlar» — « SQL Server 2008 R2» — « Microsoft SQL Server Management Studio ortamı") ve yetkilendirme için verileri girin.

Bundan sonra Nesne Tarayıcısında "sekmesini açın" Bazi haraçları»Yedek kopya oluşturmamız gereken veritabanına sağ tıklıyoruz. Bağlam menüsünde " seçeneğini seçin zavdannya» ( Görevler) — « Yedek kopya oluştur» ( Destek olmak...) .

Pencereyi başlat " Veritabanı yedekleme» ( Yedek veritabanı). Konuştuğumuz şeyi değiştirelim povna» ( Tam dolu), Gerekirse bir ad ve açıklamanın yanı sıra gerekirse yedek kopyanın bir açıklamasını da sağlayacağız. Bunu yapmak için bilgisayarınızın sabit diskine gidin ve ana SQL sunucusu veritabanının Yedekleme klasörüne gidin. Kopyalama konumunu değiştirmek için " canlılık» ( Kaldırmak), diğer seçenekleri temizlemek için ve ardından “ Eklemek» ( Eklemek...) yeni bir şey eklemek için.

Buraya yedekleme dosyasının adını yazacağız ve “ TAMAM" Bu tür varış noktaları belirtilebilir. Bu durumda yedek kopya, her biri belirlenen dosyada olmak üzere eşit parçalara bölünecektir.

Her şey yoluna girdikten sonra “” tuşuna basıyoruz. TAMAM“Görevin tamamlanıp tamamlanmadığını kontrol ediyorum. Her şey doğru yapılandırılmışsa, belirtilen dizinde SQL veritabanı dosyasının yedek bir kopyasını bulacağız.

2. Veritabanını yedek kopyadan güncelleme

Güncelleme benzer bir şemayı takip ediyor. sen " Ara Yazılım Microsoft SQL Server Management Studio»Bir baz seçin Yedek kopya nerede yapılır?, Farenin sağ tuşuyla tıklayın ve “ zavdannya» ( Görevler) — « Yenile» ( Eski haline getirmek) — « Veri tabanı...» ( Veri tabanı...).

Pencere açılacak" Veritabanı güncellemesi» ( Veritabanını Geri Yükle). Burada, dzherelo'nun dediği gibi, " Bir uzantı ekleyeceğim» ( Cihazdan) Yedekleme dosyasını seçiyorum (1. adımda oluşturuldu).

Sancağı kuralım" Yenile» ( Eski haline getirmek) Yedek kopyanın tersi. Gerekirse depozitoda " parametreler» ( Seçenekler), Ek güncelleme parametrelerini belirtebilir, anlamlarını okuyabilirsiniz.

Tüm çalışmalar tamamlandıktan sonra kabartma yapacağız” TAMAM»Veritabanının başarıyla güncellendiğine dair bildirim alıyoruz.

3. Yedek kopyanın başka bir veritabanına güncellenmesi (veri kopyalama)

Veri tabanına veri aktarılması gerekiyorsa, Yedek kopyanın oluşturulduğu hesapta, O halde 2. paragrafta açıklanan eylemlerle ilgileniyorsanız, " parametreler"(Seçenekler) veritabanı için dosya adlarını belirtin ve işareti ayarlayın" Orijinal veritabanının üzerine yaz"(DEĞİŞTİRME İLE).

Chi sana yardım etti mi?

SQL Server yönetiminin en yaygın iki görevinin nasıl organize edileceğine bir göz atalım:

• Veritabanlarının otomatik yedeklenmesi;
• Eski yedek kopyaların silinmesi.

Veritabanı yedeklemelerini planlama

• SQL Management Studio'yu açın ve gerekli veritabanına bağlanın. SQL Server Agent'ın ne yaptığına bakın;
• Yönetim - Bakım menüsünü açın (“SYSADMIN” rolüne sahip olduğunuz) - sağ tıklayın ve “Yeni Bakım Planı” seçeneğini seçin;
• Yeni bir hizmet planı girin;
• Sağdaki takvimin sonuna tek bir satırda tıklayın. Vikna'da Vikonny'nin itaat saatini ayarlayın. Veritabanının daha az kalabalık olduğu bir saati seçin;
• Araç Kutusu bölümünden Yedekleme Veritabanı Görevi öğesini ana alana sürükleyin;
• Veritabanını Yedekleme Görevi'ne çift tıklayın - yedekleme görevini ayarlama penceresi açılacaktır - gerekli ayarları yapın;
• Tamam'ı tıklayın - artık yedek kopyalar planlanan saatten önce düzenli olarak oluşturulacaktır;

Eski yedeklemelerin silinmesi

Yedekleme dosyaları sık sık oluşturulacağından sabit sürücünüzdeki alan kaçınılmaz olarak değişecektir. Bu nedenle güncel olmayan yedekleme dosyalarını silmeniz gerekecektir. Hizmet planını kolayca yapılandırabilirsiniz:

• Araç Kutusu panelinden Bakım Temizleme Görevini ana alana sürükleyin;
• Güç penceresini açmak için Bakım Temizleme Görevi'ne çift tıklayın. Yedek kopyaların genişletilmesini, genişletilmesini ve silinmesi gereken dosya sayısının sağlanması sizin sorumluluğunuzdadır. Yedek kopyaları bir aya kadar saklamak iyi bir uygulamadır;
• Tamam'a tıklayın ve hizmet planını kaydedin;
• Daha sonra bakım planının yaklaşan zamanını kontrol edebilir veya manuel olarak seçebilirsiniz (Object Explorer'da bakım planına sağ tıklayın).

sqlcmd -S DECLSERVER\SQLGTD -E -Q 'declare @s varchar(255) set @s = 'E:\backup\GTD_' + Convert(varchar(1), datepart(dw, getdate())) + '. bak 'veritabanı GTD'yi diske yedekle = init, noformat, skip, nounload ile @s "

sqlcmd Transact-SQL ifadelerini, sistem prosedürlerini ve komut dosyalarını komut satırından SQLCMD modunda sorgu düzenleyiciye girmenizi sağlar,

• -S - sunucu adını ayarlar, sunucu[\örnek_adı];
• DECLSERVER\SQLGTD - veritabanının çalıştırılacağı sunucu adı / örnek adı;
• -E - SQL sunucusuna bağlanmak için kullanıcı adını ve şifreyi değiştirmek daha güvenilirdir;
• -Q "cmdlinequery" - programı başlatırken sqlcmd Sizden çıkış yapmanız istenecektir, aksi halde programınızı tamamladıktan sonra programlardan çıkamayacaksınız. Aralarında birkaç nokta bulunan çok sayıda içecek olabilir. Yukarıda gösterildiği gibi patilerin içine yerleştirin;
• ilan etmek - değiştirilebilir olanı telaffuz ediyoruz, değiştirilebilir olanın adı her zaman @ ile başlıyor, bu nedenle @S. Vipadka'mıza @S- bu, yedek kopyaların kaydedildiği klasördür (disk);
• varchar(n) - değişiklik türünü ayarlar @S uzun bir n satırına sahip bir dize olarak örnekte 255 karakter vardır;
• ayarlamak - değişiklik değerini ayarlar @S, Uygulamada yedekleme klasörü E sürücüsündedir ( E:\yedekleme\), Daha sonra işlevi seçmek için yedekleme dosyasının adını ayarlayın Convert(varchar(1), datepart(dw, getdate())) yılın tam gününde (Pazartesi - 1 , Vitorok - 2 , vb.) ve genişletme mevcuttur fırında pişirmek. Çıktı aşağıdaki adlara sahip bir dosyadır: GTD_Haftanın Günü Numarası.bak;
• destek olmak - bir yedek oluşturun;
• veri tabanı - tüm veritabanının bir yedeğinin oluşturulduğunu gösterir;
• GTD - uygulamamızda veritabanı bir SQL sunucusundadır;
• diske - yedekleme cihazının türünü, sabit disk dosyasını ve değişikliğin belirtildiğini belirtir @S, Oluşturulan dosyanın hangi yolu ve adı atanır;
• init, noformat, skip, nounload ile - yeniden atanan başlıklarla verileri sayıma göre yeniden yazmanın gerekli olduğunu belirtir; bu, yılın her günü için 7 yedek dosyaya sahip olmamızı, sayıma göre yeniden yazmamızı sağlar.

Gerekirse sıkıştırma gibi diğer işlevleri kullanabilirsiniz; bkz. Sorgu Ekleme ve Transact-SQL İşlevleri.

Croc 2. Bir metin dosyasının uzantısını .cmd olarak değiştirme

Dosya keseden çıkarılabilir yedeklemeGTD.cmd. Komut dosyasını MS SQL veritabanının kurulu olduğu makineden çalıştırmalısınız.

Krok 3. Bu süreç otomatiktir

MS Windows Server 2008'deki bu çalışmaya bir göz atalım: Ekle Sunucu Yöneticisi -> Yapılandırma -> Zamanlayıcı -> Zamanlayıcı Kitaplığı.

Veritabanı yöneticileri yedekleme yapacak olanlar ve yedekleme yapacak olanlar olarak ikiye ayrılır.

Girmek

Bu makalede, MS SQL Server 2008 R2'nin ek araçlarını kullanan IB 1C'nin birincil yedeklemesi açıklanmakta, neden diğer şekilde değil de bu şekilde çalışması gerektiği açıklanmakta ve bir takım efsaneler ortadan kaldırılmaktadır. MS SQL dokümantasyonu hakkında söyleyecek çok şeyimiz var, bu makale daha çok yedekleme mekanizmalarına ve gerekli tüm bakımlara bakacaktır. Ancak öncelikle bu görevlerle uğraşanlar için, basit durumlarla başa çıkmanıza yardımcı olacak basit ve kesin talimatlar burada yer almaktadır. Bu makale, yönetim gurularının, guruların ve dolayısıyla her şeyi bilmesi için tasarlanmamıştır, ancak okuyucunun MS SQL Server'ı kendisinin kurması ve bu sihirli teknoloji mucizesini kendi çekirdeğinde bir veritabanı oluşturmak için kullanması önemlidir; bir veritabanı oluşturun. 1C verileriyle ilgilenin.

TSQL BACKUP DATABASE komutunu (ve onun kardeşi BACKUP LOG'u) esasen MS SQL Server'ı DBMS olarak kullanan 1C veritabanlarını yedeklemenin tek bir yöntemi olarak kullanıyorum. Neden? Şimdi yakma yollarımıza bir göz atalım:

MS SQL yöntemlerini kullanarak yedek kopyaların kullanılmasındaki temel zorluklar, çalışma ilkelerinin temel düzeyde anlaşılmamasından kaynaklanmaktadır. Bu kısmen uzun bir çizgiyle, kısmen de "hazır tarifler" düzeyinde basit ve mantıklı bir açıklamanın olmayışıyla (hmm, diyelim ki hiçbir fikir edinemedim) ve ayrıca durumla açıklanıyor. forumlarda “doguru değil” mitolojik tavsiyesiyle anlatılıyor. Bununla ne yapacağımı bilmiyorum ama yedeklemenin temellerini açıklamaya çalışacağım.

Gelecek için ne biriktiriyoruz?

Uzun zaman önce uzak bir galakside 1C: Enterprise 7.7 gibi bir mühendislik ve muhasebe düşüncesi ürünü yarattık. Belki de 1C: Businesses'ın ilk sürümleri, SQL sürümü MS SQL yedeklemesini önemli kılmak için veritabanına yeterli bilgiyi kaydetmeyen popüler dbf dosya formatının yerini almak üzere geliştirildi, ancak aynı zamanda cilt değiştiğinde zihin yapıları da değişiyor. Yeni model yok edildiğinde, yedekleme sistemini ana işlevini kaybetmeye zorlamak için büyük çaba harcamak zorunda kaldı. Ale, o zamandan beri, sürüm 8 ortaya çıktığından beri, veritabanı yöneticileri rahatlayabildiler. Standart yedekleme özellikleri eksiksiz ve eksiksiz bir yedekleme sistemi oluşturmanıza olanak tanır. Yedek kopyaya yalnızca kayıt defteri günlüğünü ve formların konumunu ayarlamak gibi diğer eylemleri (eski sürümlerde) girmeyin, aksi takdirde yedekleme yapmak istiyorsanız bu verilerin sistemin işlevselliği üzerindeki israfı belirtilmez. kayıt defteri günlüğünün kopyası ї doğru ve doğru şekilde çalışır.

Neden yedek bir kopyaya ihtiyacımız var? Hm. İlk bakışta inanılmaz derecede iyi beslenmiş görünüyor. Peki öncelikle sistemin bir kopyasını yakıp arıza durumunda sistemi farklı bir şekilde geri yüklemek mümkün müdür? Ben ilkinin amacına uygunum, ama başka bir nedenden ötürü; ilk yedekleme efsanesi.

Yedek kopyalama, sistemin bütünlüğünü sağlamanın son adımıdır. Veritabanı yöneticisinin ürün sistemini yedek kopyalardan güncellemesi gerektiğinden, bu, büyük bir güvenle iş organizasyonunda ciddi bir hatanın olmadığı anlamına gelir. Verilerin bütünlüğünü sağlamanın ana yolu olduğu için yedeklemeden önce kurulamaz, aksine yangın söndürme sistemine daha yakın bir yere kurulabilir. Yangın söndürme sistemi gereklidir. Hepsi bu kadar, ama düzeltildi, doğrulandı ve doğru. Kendisinin de söylediği gibi, bu başlı başına pek çok olumsuz sonucu olan ciddi bir PP'dir.

Yedeğin yalnızca "barışçıl" amaçlarla saklandığından emin olmak amacıyla verimliliği sağlamak için şu diğer özellikleri kullanın:

• Sunucularınızın fiziksel güvenliğini sağlayın: yangınlar, su baskınları, elektrik hasarları, temizleme istasyonları, alarm saatleri, meteorlar ve vahşi yaratıklar; tüm kokular sunucunuzu korumak için kornanın çalmasını bekliyor.
• Bilgi güvenliği tehditlerine karşı dikkatli olun.
• Sistemde uygun şekilde değişiklik yapın ve ardından değişikliklerin aksaklığa yol açmaması için mümkün olduğunca ilerleyin. Annenin değişiklik yapma planına ek olarak "her şey yanlış olduğu için ne yapacağını" da planlaması gerekiyor.
• Bunun yerine sistemin kullanılabilirliğini ve güvenilirliğini artırmak için teknolojileri aktif olarak araştırın, böylece kazaların mirasını temizleyebilirsiniz. MS SQL için izleme, en son kullanılabilirliğe genişletilebilir:
  • MS SQL kümelerini seçmek (dürüst olmak gerekirse, bunun 7/24 gerektirmeyen sistemler için veritabanı yöneticisi tutmanın en pahalı ve gereksiz yollarından biri olduğuna saygı duyuyorum)
  • Veritabanı yansıtma (kullanılabilirliğe, üretkenliğe ve kullanılabilirliğe bağlı olarak senkronize ve asenkron modda)
  • İşlem günlüğü teslimi
  • 1C yöntemlerini kullanarak çoğaltma (veritabanı bölümleri)

Sistemin kullanılabilirliğine ve bu amaç için ayrılan bütçeye bağlı olarak, arıza durumunda kesintileri ve yenilemeyi 1-2 kat azaltacak bir çözüm seçebilirsiniz. Gelişmiş erişilebilirlik teknolojilerinden korkmanıza gerek yok: temel MS SQL bilgisiyle birkaç gün içinde kolayca öğrenilebilirler.

Ale, ne olursa olsun yedek bir kopyaya hala ihtiyaç var. Bu, diğer her şeyi idare ettiğiniz sürece kullanabileceğiniz yedek paraşütün aynısıdır. Ale, kullanışlı bir yedek paraşüt olarak:

• Bu sistemin doğru ve profesyonelce ayarlanması gerekir,
• Fakhіvet sisteme tabidir ve hem teorik hem de pratik becerilerden ve durgunluktan (düzenli takviye) suçludur,
• Sistem en güvenilir ve basit bileşenlerden oluşmalıdır (bu bizim devam eden umudumuzdur).

MS SQL verilerinin kaydedilmesi ve işlenmesi hakkında temel bilgiler

MS SQL'deki veriler genellikle mdf veya ndf uzantılarıyla veri dosyalarına (bundan sonra FD olarak anılacaktır - kısa vadeli biçimlendirilmez, bu istatistikte en kısasından bile daha geniş olmayan bir on yıl olacaktır) kaydedilir. Bu dosyalara ek olarak ldf uzantılı dosyalara kaydedilen işlem günlükleri (TJ) de bulunmaktadır. Yeni yöneticilerin hem üretkenlik hem de güvenilirlik açısından kendilerini çalışmaya hazırlamaları çoğu zaman zor ve zordur. Bu çok ağır bir af. Aslında güvenilir bir şekilde çalışan bir yedekleme sistemi olduğundan ve sistem güncellemeleri saatlerce görülebildiğinden, verileri güvenli veya son derece güvenilmez, hatta çok güvenilir bir RAID-0'a kaydedebilirsiniz. yerel güvenilir ve üretken kaynağın (RAID-1'i kullanmak istiyorum). Neden öyle? Rapora bir göz atalım. Hemen sonucun basitleştirildiğini söyleyeceğim, ancak anlaşılması adına bitireceğim.

FD, verileri 8 kilobaytlık bölümler halinde saklar (bunlar 64 kilobaytlık bir kapsamda birleştirilir, ancak tamamen değil). MSSQL garanti etmez, Veriyi değiştirme komutunu verdikten hemen sonra değişiklik FD'ye gönderilecektir. Hayır, sadece hafızadaki sayfa “tasarruf” olarak belirlenmiş. Sunucunun yeterli kaynağı varsa, veriler kaçınılmaz olarak diskte görünecektir. Üstelik sunucu “iyimser” bir şekilde çalışıyor ve bu değişiklikler bir işlemde yapıldığından, işlem gerçekleştirilmeden önce tamamen diskte boşa harcanabiliyor. Bu durumda FD robotu aktif olduğunda, toplanıp toplanmayacağı veya kaydedileceği bilinmeyen, dağınık haldeki yazılı olmayan veri parçalarının ve tamamlanmamış işlemlerin kaldırılması gerekir. Sunucuya kaydedilmemiş tüm verileri "hemen" diske dökmesi talimatını veren özel bir "CHECKPOINT" komutu vardır, aksi takdirde bu komutun depolandığı alan belirlidir. 1C'nin vikoristik olmadığını (sıkışıp kalmadığımı) söylemek ve çalışma saati boyunca FD'nin tüm istasyonda durmadığını anlamak yeterli.

Bu kaostan çıkmak için doğru ST'ye ihtiyacımız var. Şu sözleri yazıyor:

• Bir işlemin başlangıcı ve tanımlayıcısı hakkında bilgi.
• Bir işlemin kaydedilmesi veya bağlanması gerçeği hakkında bilgi.
• FD'deki verilerdeki tüm değişiklikler hakkında bilgi (kabaca söylemek gerekirse, ne oldu ve ne oldu).
• FD'nin kendisinin veya veritabanı yapısının değiştirilmesine ilişkin bilgiler (dosyaların arttırılması, dosyaların değiştirilmesi, görünen ve silinen sayfalar, oluşturulan ve silinen tablolar ve dizinler)

Tüm bu bilgiler, girildiği belirlenen işlem tanımlayıcısına göre yazılır ve bu işlem öncesinde nasıl ilerleneceğini ve bu işlem sonrasında nasıl gidileceğini anlamak için yeterlidir.ї işlemler ve sorunlar (suçlu, tutarsız günlük kaydına sahip bir güncelleme modelidir) .

Bu bilgilerin hemen diske yazılması önemlidir. Bilgi CT'ye kaydedilmediği sürece kullanıcı komuta uymaz. Normal bir durumda, alanın boyutu yeterliyse ve çok parçalı değilse, içindeki kayıtlar ardı ardına küçük kayıtlar halinde (8 kb'nin katları olması gerekmez) yazılır. İşlem günlüğü yalnızca güncelleme için kesinlikle gerekli olan verileri kullanır. Zokrema OLUMSUZ Değişiklikten önce hangi metnin kullanıldığı, düzenleme için hangi planın kullanıldığı, ne tür bir uygulamanın başlatıldığı hakkındaki bilgiler kaybolur ve güncelleme için diğer bilgilere gerek yoktur. İşlem günlüğündeki verilerin yapısına ilişkin ifade yazılabilir

:: fn_dblog'dan * seçin (null, null)

Sabit disklerin, kaotik bir okuma ve yazma komutları akışı yerine sıralı yazmalarla daha verimli çalışması ve SQL komutlarının VT'ye yazmanın tamamlanma anını kontrol etmesi sayesinde, aşağıdaki öneri meyvesini veriyor:

En az düzeyde esneklik istiyorsanız, gıda endüstrisinin ortasında, ST'nin en yaygın (diğer her şey gibi) fiziksel parçaları genişletmesi gerekir; tutarlı kayıt için minimum saatlik erişim ve maksimum erişim gereklidir. güvenilirlik çalışması Basit sistemler için RAID-1 tamamen uygundur.

İşleme dokunulursa sunucuda yapılan tüm değişiklikler ön tarafa döndürülür. Bu yüzden

MS SQL Server'daki bir işlemin maliyeti, işlemin verilerini değiştirmenin toplam maliyetiyle karşılaştırılabilir. Banka işlemlerini yapmadığınızdan veya banka işlemleriyle ilgili kararları daha erken almadığınızdan emin olun.

Sunucu herhangi bir nedenle robotu başlatmak istemezse, yeniden başlatıldığında FD'deki verilerin tüm durumu (kayıtlı işlemler dışında kayıtsız ve kayıtlı işlemler dışında) yansıtıp yansıtmadığı analiz edilecektir. bağlantılı işlemler i) ve bu veriler ayarlanacaktır. Bu nedenle, örneğin büyük bir tablonun dizinlerini yeniden oluşturmaya başladıysanız ve sunucuyu yeniden başlattıysanız, yeniden başlattığınızda, bu işlemin gerçekleştirilmesi için önemli bir saat olacaktır ve bu süreci kesintiye uğratmak imkansızdır.

Dosyanın sonuna kadar çalıştığınızda ne olur? Çok basit - koçanın üzerinde boş bir yer varsa, o zaman koçanın üzerindeki boş yere, işgal edilen yere kadar dosyaya yazmaya başlamalısınız. Döngülü manyetik dikiş gibi. Başlangıç ​​için yer olmadığından sunucu, işlem günlüğü dosyasını genişletmeye çalışacak ve bu da, fiziksel işlem dosyası açısından zengin olabilecek yeni bir sanal işlem günlüğü dosyasıyla vizyon sunucusuna yeni bir bilgi parçası verecektir. yedek kopyayla uğraşmak bile yeterli değil. Sunucu dosyayı genişletemezse (diskteki alan tükenmiş veya genişletme ayarları tarafından engellenmişse), mevcut işlem 9002 hatasından etkilenir.

Hata! Gelecekte ZT'de yer alabilmek için ne kazanmanız gerekiyor? İşte geldik yedekleme sistemine ve güncelleme modellerine. Bir işlemi kaydetmek ve bir çökme sırasında sunucunun doğru durumunu güncellemek için, kritik işlemlerin en erken başlangıcından başlayarak TT'deki kayıtların kaydedilmesi gerekir. Bu minimum değer ZT'ye yazılır ve kaydedilir obov'yazkovo. Hava durumu ne olursa olsun sunucunun ayarlanması ve yöneticinin sorumluluğundadır. Sunucu bu bilgilerin kaybolmasına izin veremez. Bir oturumda işlem açarsanız ve diğer oturumlarda farklı işlemleri iptal ederseniz işlem günlüğü beklenmedik bir şekilde sona erebilir. En erken işlem DBCC OPENTRAN komutuyla belirlenebilir. Bu sadece gerekli minimum bilgidir. Daha fazla uzan güncellenmiş modeller. SQL Server'da üç tane vardır:

• Basit- Sadece yaşam için gerekli olan fazla yakıttan tasarruf edilir.
• Tam (Povna)- kalan yedekleme anından itibaren tüm VT kaydedilir işlem günlüğü. Saygınızı yeniden kazanın ve tam yedekleme yapma konusunda endişelenmeyin!
• Toplu giriş yapıldı- işlemin bir kısmı (küçük bir kısmı bile) çok kompakt bir formatta kaydedilir (esasen yalnızca veri dosyasının şu veya bu tarafını değiştiren bir kayıt). Aksi halde Tam ile aynıdır.

Yenileme modelleriyle ilgili bir takım efsaneler var.

• Basit, disk alt sistemindeki yükü azaltmanıza olanak tanır. Öyle değil. Tam olarak Toplu oturum açıldığı zamanki kadar yazılır, ancak daha önce oldukça saygı duyulur.
• Toplu günlük kaydı, disk alt sistemindeki yükü azaltmanıza olanak tanır. 1C için durum böyle değil. Aslına bakılırsa, minimal protokol kapsamına giren elmasla ek danslar olmadan yapılabilecek birkaç işlemden biri, dt formatındaki görselleştirmeden veri elde edilmesi ve tablonun yeniden yapılandırılmasıdır.
• Varsayılan Toplu günlük modelinde, herhangi bir işlem, işlem günlüğünün yedek kopyasına yansıtılmaz ve yedek kopya sırasında durumun güncellenmesine izin vermez. Bu tamamen doğru değil. İşlem minimum düzeyde günlüğe kaydedilene kadar gerçekleştirilirse, verilerin bulunduğu tam sayfalar yedek kopyada saklanacak ve işlem günlüğünü sonuna kadar "oynatmak" mümkün olacaktır (ancak daha uzun bir süre için mümkün değildir) en azından işlemler kesin olarak günlüğe kaydedildiğinden beri).

1C veritabanları için Toplu kayıtlı model ihtiyatlı olarak kullanılabilir, bu nedenle onu daha fazla göremiyoruz. Tam ve Basit arasındaki seçim ekseni ise raporun bir sonraki bölümünde ele alınacak.

• İşlem günlüğü yapısı
• • İşlem günlüğü güncelleme ve yönetim modelleri
  • İşlem günlüğü yönetimi
• İşlem günlüklerinin yedeklenmesi

Basit ve Tam güncelleme modellerinde yedekleme prensibi

Yedekleme türüne bağlı olarak üç tür vardır:

• Tam dolu(Povna)
• Diferansiyel(Farklısiyana, riznitseva)
• Kayıt(İşlem günlüklerinin, doktorların ve bu terimin kötüye kullanıldığı sıklıkta yedek bir kopyası hızlı bir şekilde RKZhT'ye güncellenecektir)

Burada kafanızın karışmasına gerek yok: yeni bir model ve yeni bir yedek kopya tamamen farklı kelimelerdir. Bunları karıştırmamak için aşağıda güncelleme modeli için İngilizce terimler, yedek kopya türleri için ise Rusça terimler kullanacağım.

Tam ve diferansiyel kopyalama, Basit ve Tam için aynı şekilde çalışır. İşlem günlüklerinin yedek bir kopyası gün boyunca Simple'da mevcuttur.

Tam yedek kopya

Herhangi bir zamanda veritabanı durumunu güncellemenizi sağlar (yedek kopyanın oluşturulduğu durumda). Veri dosyalarının bozuk kısmının geçmiş bir kopyasından ve yedek kopyanın oluşturulduğu saate ait işlem günlüğünün aktif girişinden oluşur.

Diferansiyel yedekleme

Son yedeklemeden bu yana değişen verileri kaydeder. Yeniden başlamanız gerekiyorsa, yeni bir yedek kopya oluşturmanız gerekir (NORECOVERY modunda uçlar daha aşağıya doğru yönlendirilecektir), ardından "iş parçası" kaldırılmadan önce orijinal perakende kopyaları kaydedebilirsiniz veya elbette yalnızca bir sonraki yeni yedek kopyaya kadar oluşturulanlardan. Bu amaçla, yedek kopyayı kaydetmek için gereken disk alanı miktarını önemli ölçüde azaltabilirsiniz.

Önemli noktalar:

• Önceki tam yedekleme olmadan diferansiyel kopya kaybolur. Bu nedenle bunların tek tek buraya kaydedilmesi önemlidir.
• Bir sonraki diferansiyel yedekleme, öncekinden sonra oluşturulan önceki diferansiyel yedeklemenin içerdiği tüm sayfaları kaydedecektir (ancak bunun yerine farklı bir tane olabilir). Bu nedenle, dış görünüm, yeniden yeni bir kopya oluşturulana kadar öncekilerden daha büyük bir fark kopyası alır (bu yok edilirse, o zaman yalnızca sıkıştırma algoritmaları aracılığıyla)
• Her an yenilemek için bitirin geriye kalanŞu anda tam yedekleme geriye kalanşimdilik fark kopyası. Güncelleme için ara kopyalara gerek yoktur (ancak güncelleme anını seçmek için gerekli olabilir)

RKZhT

Cari döneme ait TT'nin bir kopyasını yerleştirin. Geçmiş RKZhT anından hat içi RKZhT'nin kalıplanma anına kadar düşünün. RKZhT, NORECOVERY modunda güncellenen bir kopyadan, herhangi bir zamanda ST'nin güncellenen kopyasının periyodunun girilmesine, ST'nin güncellenmiş kopyasının periyodunun girilmesine, durumun mevcut saatten sonraki herhangi bir saate güncellenmesine olanak sağlar. saat, yenileme aralığına girmek için ї yedek kopyalar. Standart parametreler kullanılarak bir yedekleme oluşturulduğunda, işlem günlüğü dosyasındaki yer değişir (işlem açık kalana kadar).

Açıkçası, RKZhT'nin Basit modelde bir anlamı yoktur (bu nedenle, kapatılmamış işlemlerin kalan anından bilgileri kaldırır).

Vikorystanny RKZhT önemli bir kavramı suçladığında - kesintisiz lancer RKZhT. Bu dize, bu dizenin birkaç yedek kopyasının boşa harcanmasıyla veya veritabanının Simple'a ve geriye aktarılmasıyla kesintiye uğratılabilir.

Lütfen dikkat: RKZhT seti esasen Mary'dir, çünkü sürekli bir döngüye sahip değildir ve kalan başarılı tam veya perakende yedeklemenin başladığı an suçludur. ortada bu Lanzyuzhka dönemi.

Merhamet ve efsanenin bölümleri:

• "RKZhT, ilk tam veya perakende yedekleme sırasında verileri işlem günlüğüne yerleştirecektir." Hiç de öyle değil. RKZhT, ilk bakışta gereksiz verileri ilk RKZhT ile bir sonraki yedekleme yedeği arasına yerleştirecektir.
• "İşlem günlüğünün ortasında daha iyi bir yer elde etmenin sorumlusu yeni veya perakende bir yedeklemedir." Hiç de öyle değil. Birinci ve ikinci yedeklemeler RKZhT kordonunu temizlemez.
• Ekipman elle temizlenmeli, değiştirilmeli ve parçalanmalıdır. Hayır, yanlışlıkla söylemeye gerek yok - bu iyi değil. RKZhT arasındaki ST'yi çıkarırsanız, yenileme için gerekli olan RKZhT kelepçesi imha edilecektir. Ve dosyadaki kademeli değişiklikler / uzantılar, fiziksel ve mantıksal parçalanmaya yol açacaktır.

Basit bir şekilde nasıl çalışır?

Hadi veritabanı 1000 GB. Veritabanı her gün 2 GB büyüyor ve bu da 10 GB eski veriyi değiştiriyor. Kapsamlı güncel yedeklemeler

• F1'in 0:00'daki tam kopyası 1 şiddetli (1000 GB kaplıdır, resmin basitliği için sıkıştırılmıştır, kurtarılamaz)
  • Diferansiyel kopya D1.1, 0:00'da 2 kez (hacim 12 GB)
  • Diferansiyel kopya D1.2 v 0:00 3 şiddetli (19 GB kaplı)
  • Diferansiyel kopya D1.3 v 0:00 4 şiddetli (25 GB)
  • Diferansiyel kopya D1.4 v 0:00 5 şiddetli (31 GB kaplı)
  • Diferansiyel kopya D1.5 v 0:00 6 şiddetli (36 GB)
  • Fark kopyası D1.6 v 0:00 7 şiddetli (40 GB kaplı)
• F2'nin tam kopyası 0:00 8 şiddetli (kapasite 1014 GB)
  • Diferansiyel kopya D2.1, 0:00 9 şiddetli (hacim 12 GB)
  • Diferansiyel kopya D2.2 v 0:00 10 şiddetli (toplam 19 GB)
  • Fark kopyası D2.3 v 0:00 11 şiddetli (25 GB)
  • Fark kopyası D2.4 v 0:00 12 şiddetli (toplam 31 GB)
  • Diferansiyel kopya D2.5 v 0:00 13 şiddetli (36 GB kaplı)
  • Diferansiyel kopya D2.6 v 0:00 14 şiddetli (toplam 40 GB)

Bu ek set için verileri 1'den 14'e kadar herhangi bir günün saat 0:00'ında güncelleyebiliriz. Bunun için 1-7. günler için F1'in yeni bir kopyasını veya 8-14. yıllar için F2'nin yeni bir kopyasını almamız, bunları NORECOVERY modunda güncellememiz ve ardından gerekli günün diferansiyel kopyasını kaydetmemiz gerekiyor.

Tam olarak nasıl çalışıyor?

Önceki örnekte olduğu gibi aynı yedekleme ve perakende yedekleme setine sahip olabilir miyiz? Buna ek olarak RKZhT'nin adımları:

• RKZhT 1 Pazartesi 12:00 31'den 12:00'a kadar 2 şiddetli (30 GB'a yakın)
• RKZhT 2, 12:00 2 şiddetli ile 12:00 4 şiddetli (30 GB'ye yakın) arası dönem için
• RKZhT 3 12:00'den 4 şiddetliye kadar 12:00 6 şiddetli (30 GB'ye yakın)
• RKZhT 4, 12:00 6 şiddetli ile 12:00 7 şiddetli (30 GB'ye yakın) arası dönem için
• RKZhT 5, 12:00 8 şiddetli ile 12:00 10 şiddetli (30 GB'a yakın) arası dönem için
• RKZhT 6, 12:00 10 şiddetli ile 12:00 12 şiddetli (30 GB'ye yakın) arası dönem için
• RKZhT 7, 12:00 12 şiddetliden 12:00 14 şiddetliye kadar (30 GB'a yakın)
• RKZhT 8 12:00 14 şiddetliden 12:00 16 şiddetliye kadar (30 GB'ye yakın)

Saygıyı yeniden sağlayın:

1. RKZhT'nin boyutu yaklaşık olarak sabit olacaktır.
2. Yedek kopyaları daha az veya daha sık ve muhtemelen daha sık çalıştırabiliriz, böylece boyutları daha küçük olur.
3. Artık sistem durumunu 1'inci 0:00'dan, elimizde yeni bir kopya varsa 16'sı 12:00'ye kadar her an güncelleyebiliriz.

En basit durumda, yenileme için ihtiyacımız var:

1. Güncellenene kadar kalan kopya
2. Güncellemeye kadar kalan diferansiyel kopya
3. Kalan diferansiyel kopya anından güncelleme anına kadar tüm RKZhT

• F2'nin tam kopyası 0:00 8 şiddetli
• Fark kopyası D2.2, 0:00 10 şiddetli
• 12:00 22:00 - 12:00 12:00 arası dönem için RKZhT 6.

F2 başlangıçtan itibaren güncellenecek, ardından D2.2 ve ardından RKZhT 6, ayın 10'unda 13:13:13'e kadar güncellenecektir. Tam modelin temel avantajı, bir seçeneğimizin olmasıdır; ya vikorist yine kalacak ya da fark kopyası ya da DEĞİL. Örneğin, D2.2 kopyasının sıkıştırılmış olduğu ortaya çıktı ve 13:13:13 22:00'den önceki an için verileri güncellememiz gerekiyordu, o zaman Basit model için bu, yalnızca şu ana kadar verileri güncelleyebileceğimiz anlamına geliyordu: şu an D2.1. Tam - "PANİK YAPMAYIN" ile aşağıdaki seçeneklere sahibiz:

1. F2'yi, ardından D2.1'i, ardından RKZHT 5'i, ardından 13:13:13 22:00'ye kadar RKZHT 6'yı yenileyin.
2. F2'yi, ardından RKZHT 4'ü, ardından RKZHT 5'i, ardından 13:13:13 22:00'ye kadar RKZHT 6'yı yenileyin.
3. Aksi halde, F1'i güncelleyin ve ayın 10'unda 13:13:13'e kadar tüm RKZhT'leri RKZhT 6'ya kadar sürün.

Görünüşe göre ikinci model bize daha fazla seçenek sunuyor.

Ve artık daha da kurnaz olduğumuz açık. Ve kazadan birkaç gün önce (13:13:13 22:00) bir kaza olacağını biliyoruz. Veritabanını mevcut sunucudaki yeni bir yedek kopyayla güncelliyoruz, böylece yeni perakende kopyaları veya RKZHT'yi, yani NORECOVERY modunda indirme olanağını ortadan kaldırıyoruz. RKZhT kalıplandıktan sonra her seferinde, NORECOVERY modunda kaldırılan yedek tabanda durur. Vay! Ancak büyük veritabanını güncellemek için artık veritabanını güncellemek için yalnızca 10-15 dakikamız var! Sanırım kesinti süresini azaltmanın yollarından biri olan günlük dağıtım mekanizmasını yeniden icat ettik. Verileri bu şekilde periyot başına bir kez değil sürekli olarak iletirseniz, o zaman bir ayna elde edersiniz ve baz aynası güncellenirken baz jet kontrol ederse, ayna ile senkronize olur, kontrol etmezse, asenkrondur.

Yüksek kullanılabilirlik özellikleri hakkında daha fazla ayrıntı şu bölümde okunabilir:

• Yüksek düzeyde kullanılabilirlik (Veritabanı Motoru bileşeni)
  • Yüksek düzeyde kullanılabilirliğe sahip çözümler hakkında halktan haberler
  • Yüksek düzeyde kullanılabilirlik. Karşılıkçılık ve işbirlikçi çalışma

Yedeklemenin diğer yönleri

Bir teori ortaya attıysanız ve elleriniz çalışıyorsa ve bir yedek kopya oluşturmaya çalışıyorsanız, bu bölüm güvenle atlanabilir.

dosya grupları

1C: İş dünyası esas olarak dosya gruplarıyla ilgilenemez. Bir dosya grubu ve hepsi bu. Aslında, MS SQL'deki bir programcı veya veritabanı yöneticisi tablolar, dizinler oluşturabilir veya bir dosya grubu çevresinde (en basit durumda dosyalar çevresinde) tablolar ve dizinler oluşturabilir. Bu, herhangi bir veriye erişimi hızlandırmak (en popüler medyada bile bulunabilir) veya verileri feda etmek, onu daha ucuz bir cihaza (örneğin, düşük hacimli veya hacimli veriler). Dosya gruplarıyla çalışırken, yedek kopyalarıyla doğrudan çalışmak mümkündür ve aynı zamanda güncelleme de mümkündür veya geri yükleme yapılması gerekir, böylece tüm dosya gruplarının aynı anda "yakalanması" gerekir. RKZhT göçleri.

veri dosyaları

Bir kişi verileri farklı dosya gruplarına yerleştirirse, dosya grubunun ortasında bir grup dosya varsa, MS SQL Server verileri bağımsız olarak bunlara kopyalar (dosyalar eşit şekilde işlenirse bunu yapmaya çalışacaktır) eşit olarak). Uygulanan noktada giriş-çıkış işlemlerini paralelleştirmek için görünüm kullanılır. Yedek kopyalar açısından ise farklı bir an var. SQL 2008 öncesi dönemde büyük veritabanları için bile kalıcı bir yedekleme için sabit bir pencere görmek yaygın bir sorundu ve bu yedeklemenin hedef diski buna uyum sağlayamıyordu. Bu durumda en kolay yol, pencerenizde her dosyanın (veya dosya grubunun) yedek kopyasını oluşturmaktı. Aynı zamanda, yedek kopyaların sıkıştırılmasının aktif olarak genişletilmesiyle bu sorun azaldı, ancak bu yöntem yine de dikkate alınabilir.

Yedek sıkıştırma

MS SQL Server 2008'de rock süper-mega-ultra güçlü hale geldi. Ara sıra, yedek kopyalar bir sayfaya kalıplandığında sıkıştırılabilir. Bu, 1C veritabanı yedek kopyasının boyutunu 5-10 kat değiştirir. Ve doktorlar için, disk alt sisteminin üretkenliği ve DBMS'nin dar alanı göz önüne alındığında, bu yalnızca tasarruf verimliliğinde bir azalma değil, aynı zamanda yedek kopyalamanın daha da hızlı bir şekilde hızlanması anlamına gelir (ve işlemcilere artan bir vurgu vardır, aksi takdirde DBMS sunucusundaki işlemci yükünün tamamen yeterli olduğundan emin olun).

2008 sürümü yalnızca Enterprise sürümünün özelliklerine sahipken (ki bu oldukça pahalıdır), 2008 R2'de bu işlevsellik Standart sürüme eklendi ve bu çok sevindirici.

Aşağıda uygulamaları analiz ederken sıkıştırma görünmüyor, ancak onu açmak için özel bir neden olmadığından yedek sıkıştırmayı kullanmanızı şiddetle tavsiye ediyorum.

Bir yedekleme dosyası - çok fazla cesaret

Aslında yedek kopya yalnızca bir dosya değil, birçok yedek kopyayı kaydedebileceğiniz daraltılabilir bir kaptır. Bu yaklaşımın uzun bir geçmişi var (özellikle 6.5 sürümüne karşı ihtiyatlıyım), ancak şu anda "birincil" veritabanlarının, özellikle 1C veritabanlarının yöneticileri için, bu yaklaşımı yedekleme başına - bir dosya olarak kullanmamak için ciddi bir neden yok" . Kapsamlı bir geliştirme için, birkaç yedek kopyayı tek bir dosyaya koyma yeteneğini dikkate almak önemlidir, aksi takdirde her şey için vikorist yapamazsınız (ya da yaparsanız, o zaman bir dosyanın enkazını çözebilirsiniz) vasıfsız bir şekilde vikoristov c) yapabilecek olan yönetici adayı.

Bir sürü ayna kopyası

SQL Server'ın mucizevi bir özelliği daha var. Yedek kopyayı paralel olarak bir grup cihaz halinde oluşturabilirsiniz. Basit bir şekilde, bir kopyayı yerel diske kaydedebilir ve hemen bir arka uç kaynağında saklayabilirsiniz. Yerel kopya kullanışlıdır, çünkü güncellemeleri zaten tamamlanmış olduğundan, uzak kopya ana veritabanı sunucusunun fiziksel sınırlamalarını çok daha hızlı bir şekilde aktaracaktır.

Yedekleme sistemlerinin uygulamaları

Teoriyi bitir. Artık tüm mutfağın çalıştığını pratikle göstermenin zamanı geldi.

Bakım Planını kullanarak tipik bir sunucu yedeğini ayarlama

Bu bölüm, hazır tarifleri açıklamalı olarak görmenizi gerektirir. Bu bölüm resim serisi açısından oldukça sıkıcı ve uzun olduğundan bu bölümü atlayabilirsiniz.

Belediye başkanı bir hizmet planı oluşturmaktan sorumludur

TSQL komut dosyalarıyla sunucu yedeklemesini ayarlayın, bazı püf noktalarını deneyin

Asıl mesele yemek, ama başka neye ihtiyacınız var? Neden herkes her şeyi ayarladı ve hala iyi bir yaşlı adam gibi çalışıyor? Her türlü senaryoyla uğraşmak zorunda mısın? Bakım planları aşağıdakilere izin vermez:

• Vikoristuvati dzerkalne rezervannya
• Vikoristovat, sunucunun kısıtlamasını sunucuyu ayarlamaktan ayarlıyor
• Bireyin acil durumlara tepki vermesine izin vermez (düzeltme imkanı yoktur)
• Vikorist güvenlik ayarlarına izin vermiyor
• Çok sayıda sunucuda (muhtemelen zaten 3-4) hizmet planları geliştirmek (ve bunları güncel tutmak) zordur.

Aşağıda tipik yedekleme komutları verilmiştir

Tam yedek kopya

Orijinal dosyanın (yani) tam yedek kopyasının üzerine yazılır ve kayıttan önce tarafların sağlama toplamları doğrulanır. Yedek kopya oluştururken yüzlerce ilerleme sayılır

VERİTABANINI DİSK'E YEDEKLEME = N "C:\Backup\mydb.bak" INIT, FORMAT, STATS = 1, CHECKSUM İLE

Diferansiyel yedekleme

Benzer - perakende kopya

VERİTABANINI DİSK'E YEDEKLEME = N "C:\Backup\mydb.diff" İLE DİFERANSİYEL, BAŞLAT, FORMAT, İSTATİSTİK = 1, SAĞLAMA TOPLAM

RKZhT

İşlem günlüğünün yedek kopyası

GÜNLÜĞÜ DİSKE YEDEKLEME = N "C:\Backup\mydb.trn" INIT, FORMAT İLE

ayna rezervasyonu

Genellikle yalnızca bir yedek kopyayı değil iki yedek kopyayı manuel olarak oluşturmak gerekir. Örneğin, biri sunucuda yerel olarak uzanabilir (sanki elinizin altındaymış gibi) ve diğeri, fiziksel olarak uzak bir yerde hemen oluşturulabilir ve hoş olmayan sarsıntı dalgalanmalarından korunabilir:

VERİTABANINI DİSK'E YEDEKLEME = N "C:\Backup\mydb.bak", AYNA İÇİN DİSK = N "\\safe-server\backup\mydb.bak" INIT, FORMAT İLE

Çoğu zaman dikkate alınmayan önemli bir nokta: MSSQL Sunucu işleminin adı altında başlatıldığı kullanıcının "\\safe-server\backup\" kaynağına erişimi olmalıdır, aksi takdirde kopya acımasızca sona erecektir. MSSQL Sunucusu sistem adı altında başlatılırsa, "sunucu_adı$" istemci etki alanına erişim verilmesi veya daha basit bir şekilde, özel olarak oluşturulmuş bir istemci adı altında MS SQL'in başlatılmasını doğru şekilde yapılandırmak için erişim verilmesi gerekir.

AYNALAMA belirtmezseniz, 2 ikiz kopya değil, yansıtma ilkesine göre 2 dosyaya bölünmüş bir kopya olacaktır. Ve etraflarındaki deri ıslak olacak.