Aracılığıyla paylaş

SQL Server işlem günlüğü mimarisi ve yönetim kılavuzu

Şunlar için geçerlidir:SQL ServerAzure SQL VeritabanıAzure SQL Yönetilen ÖrneğiAzure Synapse AnalyticsAnalytics Platform Sistemi (PDW)Microsoft Fabric SQL veritabanı

Her SQL Server veritabanı, her işlem tarafından yapılan tüm işlemleri ve veritabanı değişikliklerini kaydeden bir işlem günlüğüne sahiptir. İşlem günlüğü veritabanının kritik bir bileşenidir ve sistem hatası varsa veritabanınızı tutarlı bir duruma geri getirmek için işlem günlüğü gerekebilir. Bu kılavuz, işlem günlüğünün fiziksel ve mantıksal mimarisi hakkında bilgi sağlar. Mimariyi anlamak, işlem günlüklerini yönetmedeki etkinliğinizi artırabilir.

İşlem günlüğü mantıksal mimarisi

SQL Server işlem günlüğü, sanki bir log kaydı dizisiymiş gibi mantıksal olarak çalışır. Her günlük kaydı bir günlük dizisi numarası (LSN) ile tanımlanır. Her yeni günlük kaydı, önceki kaydın LSN'sinden daha yüksek bir LSN ile günlüğün mantıksal ucuna yazılır. Günlük kayıtları oluşturulduklarında ardışık bir dizilimde depolanır; dolayısıyla, LSN2 LSN1'den büyükse, LSN2 tarafından referans verilen günlük kaydındaki değişiklik, LSN1 günlük kaydında açıklanan değişiklikten sonra gerçekleşmiştir. Her günlük kaydı, ait olduğu işlemin kimliğini içerir. Her işlem için, işlemle ilişkili tüm günlük kayıtları, işlemin geri alınmasına hız veren geriye dönük işaretçiler kullanılarak zincirde tek tek bağlanır.

LSN'nin temel yapısıdır [VLF ID:Log Block ID:Log Record ID]. Daha fazla bilgi için VLF ve günlük bloğu bölümlerine bakın.

Burada bir LSN örneği verilmiştir: 00000031:00000da0:0001, burada 0x31 VLF'nin kimliği, 0xda0 günlük bloğu kimliği ve 0x1 bu günlük bloğundaki ilk günlük kaydıdır. LSN örnekleri için sys.dm_db_log_info DMV'nin çıkışına vlf_create_lsn bakın ve sütunu inceleyin.

Veri değişiklikleri için günlük kayıtları, gerçekleştirilen mantıksal işlemi veya değiştirilen verilerin önceki ve sonraki görüntülerini kaydeder. Önceki görüntü, işlem gerçekleştirilmeden önce verilerin bir kopyasıdır; after görüntüsü, işlem gerçekleştirildikten sonra verilerin bir kopyasıdır.

Bir işlemi kurtarma adımları günlük kaydının türüne bağlıdır:

  • Mantıksal işlem günlüğe kaydedildi

    • Mantıksal işlemi ilerletmek için, işlem yeniden gerçekleştirilir.
    • Mantıksal işlemi geri almak için ters mantıksal işlem gerçekleştirilir.

  • Öncesi ve sonrası görüntüler günlüğe kaydedildi

    • İşlemi ilerletmek için son durum görüntüsü uygulanır.
    • İşlemi geri almak için, önceki görüntü uygulanır.

birçok işlem türü işlem günlüğüne kaydedilir. Bu işlemler şunları kapsar:

  • Her işlemin başlangıcı ve sonu.

  • Her veri değişikliği (ekleme, güncelleştirme veya silme). Değişiklikler, sistem tabloları dahil olmak üzere herhangi bir tabloda sistem saklı yordamlarına veya veri tanımı dili (DDL) deyimlerine göre yapılan değişiklikleri içerir.

  • Her kapsam ve sayfa ayırma veya serbest bırakma.

  • Tablo veya dizin oluşturma veya bırakma.

Geri alma işlemleri de günlüğe kaydedilir. Her işlem, açık bir geri alma komutu veya hatayla karşılaşılması durumunda meydana gelen bir geri alma işlemini desteklemek için yeterli günlük alanı sağlamak amacıyla işlem günlüğünde yer ayırır. Ayrılan alan miktarı işlemde gerçekleştirilen işlemlere bağlıdır, ancak genellikle her işlemi günlüğe kaydetmek için kullanılan alan miktarına eşittir. İşlem tamamlandığında bu ayrılmış alan boşaltılır.

İlk günlük kaydındaki günlük dosyasının başarılı bir veritabanı genelinde son yazılan günlük kaydına geri alma işlemi için mevcut olması gereken bölümü, günlüğün etkin bölümü, etkin günlük veya günlüğün kuyruğu olarak adlandırılır. Veritabanının tam kurtarılması için gerekli olan günlüğün bölümü budur. Aktif günlüğün hiçbir bölümü asla kesilip küçültülemez. Bu ilk günlük kaydının günlük dizisi numarası (LSN), en düşük kurtarma LSN'si (MinLSN ) olarak bilinir. İşlem günlüğü tarafından desteklenen işlemler hakkında daha fazla bilgi için bkz. İşlem günlüğü.

Diferansiyel ve log yedeklemeler, geri yüklenen veritabanını daha sonraki bir zamana ilerleterek daha yüksek bir LSN'ye ulaştırır.

İşlem günlüğü fiziksel mimarisi

Veritabanı işlem günlüğü bir veya daha fazla fiziksel dosyaya haritalandırılır. Kavramsal olarak, günlük dosyası günlük kayıtlarının bir dizisidir. Fiziksel olarak, günlük kayıtlarının sırası, işlem günlüğünü uygulayan fiziksel dosyalar kümesinde verimli bir şekilde depolanır. Her veritabanı için en az bir günlük dosyası olmalıdır.

Sanal Günlük Dosyaları (VLFs)

SQL Server Veritabanı Altyapısı, her fiziksel günlük dosyasını dahili olarak birkaç sanal günlük dosyasına (VLFs) böler. Sanal günlük dosyalarının boyutu sabit değildir ve fiziksel günlük dosyası için sabit sayıda sanal günlük dosyası yoktur. Veritabanı Altyapısı, günlük dosyalarını oluştururken veya genişletirken sanal günlük dosyalarının boyutunu dinamik olarak seçer. Veritabanı Altyapısı birkaç sanal dosya tutmaya çalışır. Bir günlük dosyası genişletildikten sonra sanal dosyaların boyutu, mevcut günlüğün boyutunun toplamı ve yeni dosya artışının boyutudur. Sanal günlük dosyalarının boyutu veya sayısı yöneticiler tarafından yapılandırılamaz veya ayarlanamaz.

Sanal günlük dosyası oluşturma

Sanal günlük dosyası (VLF) oluşturma işlemi şu yöntemi izler:

  • SQL Server 2014 (12.x) ve sonrasındaki sürümlerde, bir sonraki büyüme geçerli günlük fiziksel boyutunun 1/8'inden küçükse, büyüme boyutunu kapsayan 1 VLF (Sanal Günlük Dosyası) oluşturun.
  • Sonraki büyüme geçerli günlük boyutunun 1/8'inden fazlaysa, 2014 öncesi yöntemini kullanın, yani:
    • Büyüme 64 MB'tan küçükse büyüme boyutunu kapsayan 4 VDF oluşturun (örneğin, 1 MB büyüme için 256 KB boyutunda 4 VLIF oluşturun).
      • Azure SQL Veritabanı'nda ve SQL Server 2022 (16.x) (tüm sürümler) ile başlayarak mantık biraz farklıdır. Büyüme 64 MB'tan küçük veya buna eşitse, Veritabanı Altyapısı büyüme boyutunu kapsayacak tek bir VLF oluşturur.
    • Büyüme 64 MB'tan 1 GB'a kadar ise, büyüme boyutunu kapsayan 8 VLI oluşturun (örneğin, 512 MB büyüme için 64 MB boyutunda 8 VLF oluşturun).
    • Büyüme 1 GB'tan büyükse, büyüme boyutunu kapsayan 16 VLF oluşturun; örneğin, 8 GB büyüme için 512 MB boyutunda 16 VLF oluşturun).

Günlük dosyaları çok küçük artışlarla büyük bir boyuta büyüdüğünde, birçok sanal günlük dosyası ortaya çıkar. Bu işlem veritabanı başlatma, günlük yedekleme ve geri yükleme işlemlerini yavaşlatabilir ve işlem çoğaltma/CDC ve Always On yineleme gecikmesine neden olabilir. Buna karşılık, günlük dosyaları birkaç veya yalnızca bir artımlı büyük bir boyuta ayarlanırsa, bunlar çok büyük birkaç sanal günlük dosyası içerir. İşlem günlüğünün gerekli boyutunu ve otomatik büyütme ayarını düzgün tahmin etme hakkında daha fazla bilgi için İşlem günlüğü dosyasının boyutunu yönetme makalesininÖneriler bölümüne bakın.

Günlük dosyalarınızı, gereken son boyuta mümkün olduğunca yakın şekilde, en iyi VLF dağılımına ulaşmak için gereken artışları kullanarak oluşturmanızı ve görece büyük bir growth_increment değeri tercih etmenizi öneririz.

Geçerli işlem günlüğü boyutu için en uygun VLF dağılımını belirlemek için aşağıdaki ipuçlarına bakın:

  • boyut değeri, SIZE bağımsız değişkeni tarafından ALTER DATABASE ayarlanır ve günlük dosyasının başlangıç boyutudur.
  • Growth_increment değeri (otomatik büyütme değeri olarak da bilinir), FILEGROWTH bağımsız değişkeniyle ALTER DATABASE tarafından ayarlanan ve her yeni alan gerektiğinde dosyaya eklenen alan miktarını belirten değerdir.

FILEGROWTH ve SIZE bağımsız değişkenleri hakkında daha fazla bilgi için ALTER DATABASE sayfasına bakın.

Tip

Belirli bir örnekteki tüm veritabanlarının geçerli işlem günlüğü boyutu için en uygun VLF dağılımını ve gerekli boyuta ulaşmak için gereken büyüme artışlarını belirlemek için GitHub'daki bu Fixing-VLFs betiğine bakın.

Çok fazla VLF'niz olduğunda ne olur?

Veritabanı kurtarma işleminin ilk aşamalarında, SQL Server tüm işlem günlüğü dosyalarındaki tüm VLF'leri bulur ve bu VLF'lerin listesini oluşturur. Bu işlem, belirli bir veritabanında bulunan VLF sayısına bağlı olarak uzun sürebilir. Ne kadar çok VLF olursa işlem o kadar uzun olur. Sık sık işlem günlük dosyasının otomatik büyümesi veya manuel büyümesi küçük artışlarla karşılaşılırsa, veritabanı fazla sayıda VLF ile sonuçlanabilir. VLF sayısı birkaç yüz bin aralığına ulaştığında, aşağıdaki belirtilerin bir kısmı veya çoğuyla karşılaşabilirsiniz:

  • SQL Server başlatma sırasında bir veya daha fazla veritabanının kurtarma işleminin tamamlanması çok uzun sürer.
  • Veritabanını geri yükleme işleminin tamamlanması çok uzun sürer.
  • Veritabanı ekleme girişimlerinin tamamlanması çok uzun sürüyor.
  • Veritabanı yansıtmayı ayarlamaya çalıştığınızda, zaman aşımı olduğunu belirten 1413, 1443 ve 1479 hata iletileriyle karşılaşırsınız.
  • Veritabanını geri yüklemeye çalıştığınızda 701 gibi bellekle ilgili hatalarla karşılaşırsınız.
  • İşlem çoğaltması veya değişiklik verisi yakalama önemli bir gecikmeyle karşılaşabilir.

SQL Server Hata günlüğünü incelediğinizde, veritabanı kurtarma işleminin çözümleme aşamasından önce önemli miktarda zaman harcandığını fark edebilirsiniz. Örneğin:

2022-05-08 14:42:38.65 spid22s Starting up database 'lot_of_vlfs'.
2022-05-08 14:46:04.76 spid22s Analysis of database 'lot_of_vlfs' (16) is 0% complete (approximately 0 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

Ayrıca, ÇOK sayıda VLF içeren bir veritabanını geri yüklerken SQL Server bir MSSQLSERVER_9017 hatası kaydedebilir:

Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

Daha fazla bilgi için bkz. MSSQLSERVER_9017.

Çok sayıda VLF'ye sahip veritabanlarını düzeltme

Toplam VDF sayısını en fazla birkaç bin gibi makul bir tutarda tutmak için, aşağıdaki adımları uygulayarak işlem günlüğü dosyasını daha az sayıda VLF içerecek şekilde sıfırlayabilirsiniz:

  1. İşlem günlüğü dosyalarını el ile küçültün.

  2. Aşağıdaki T-SQL betiğini kullanarak dosyaları bir adımda el ile gerekli boyuta büyütün:

    ALTER DATABASE <database name> MODIFY FILE (NAME='Logical file name of transaction log', SIZE = <required size>);

    Note

    Bu adım, veritabanı özellikleri sayfasını kullanarak SQL Server Management Studio'da da mümkündür.

İşlem günlüğü dosyasının yeni düzenini daha az VLIF ile ayarladıktan sonra, işlem günlüğünün otomatik büyütme ayarlarında gerekli değişiklikleri gözden geçirin ve yapın. Bu ayar doğrulama, günlük dosyasının gelecekte aynı sorunla karşılaşmasını önler.

Bu işlemlerden herhangi birini gerçekleştirmeden önce, daha sonra sorunlarla karşılaşmanız durumunda geçerli bir geri yüklenebilen yedeklemeye sahip olduğunuzdan emin olun.

Belirli bir örnekteki tüm veritabanlarının geçerli işlem günlüğü boyutu için en uygun VLF dağılımını ve gerekli boyuta ulaşmak için gerekli büyüme artışlarını belirlemek için, VLF'leri düzeltmek için aşağıdaki GitHub betiğini kullanabilirsiniz.

Günlük blokları

Her VLF bir veya daha fazla log bloğu içerir. Her bir log bloğu, log kayıtlarından oluşur (4 baytlık sınırda hizalanmış). Günlük bloğunun boyutu değişkendir ve her zaman 512 baytın tamsayı katıdır (SQL Server'ın desteklediği en düşük sektör boyutu), en fazla boyutu ise 60 KB'dir. Günlük bloğu, işlem günlüğü için temel G/Ç birimidir.

Özetle, günlük bloğu, diske günlük kayıtları yazılırken temel işlem günlüğü birimi olarak kullanılan günlük kayıtlarının kapsayıcısıdır.

Bir VLF içindeki her günlük bloğu, blok uzaklığıyla benzersiz bir şekilde ele alınmıştır. İlk bloğun her zaman VLF'deki ilk 8 KB'yi geçen bir blok uzaklığı vardır.

Genel olarak, bir VLF her zaman log bloklarıyla doldurulur. VLF'deki son günlük bloğu boş olabilir (örneğin, herhangi bir günlük kaydı içermez). Yazılacak günlük kaydı geçerli günlük bloğuna sığmadığında ve VLF'de kalan alan bu günlük kaydını tutmak için yetersiz olduğunda bu durum ortaya çıkar. Bu durumda, VLF'yi doldurmak için boş bir günlük bloğu oluşturulur. Günlük kaydı, sonraki VLF'deki ilk bloğa içerisine eklenir.

İşlem günlüğünün döngüsel yapısı

İşlem günlüğü bir çevrimli dosyadır. Örneğin, bir fiziksel günlük dosyasının dört VLFS'ye bölünmüş olduğu bir veritabanını düşünün. Veritabanı oluşturulduğunda, mantıksal günlük dosyası fiziksel günlük dosyasının başlangıcında başlar. Mantıksal günlüğün sonuna yeni günlük kayıtları eklenir ve fiziksel günlüğün sonuna doğru genişletilir. Günlük kesilmesi, kayıtları en düşük kurtarma günlüğü sıra numarasının (MinLSN) önünde görünen tüm sanal günlükleri serbest bırakır. MinLSN, başarılı bir veritabanı geri sarma işlemi için gereken en eski günlük kaydının günlük sıra numarasıdır. Örnek veritabanındaki işlem günlüğü aşağıdaki diyagramdakine benzer olacaktır.

Fiziksel günlük dosyasının sanal günlüklere nasıl bölündüğünü gösteren diyagram.

Mantıksal günlüğün sonu fiziksel günlük dosyasının sonuna ulaştığında, yeni günlük kayıtları fiziksel günlük dosyasının başlangıcına kaydırılır.

Mantıksal işlem günlüğünün fiziksel günlük dosyasında nasıl kaydırıldığını gösteren diyagram.

Mantıksal günlüğün sonu hiçbir zaman mantıksal günlüğün başlangıcına ulaşmazsa, bu döngü sonsuz olarak yinelenir. Eski günlük kayıtları, bir sonraki denetim noktası aracılığıyla oluşturulan tüm yeni günlük kayıtları için her zaman yeterli yer bırakacak kadar sık kısaltılırsa, günlük hiçbir zaman dolmaz. Ancak, mantıksal günlüğün sonu mantıksal günlüğün başlangıcına ulaşırsa iki şeyden biri gerçekleşir:

Günlük birden çok fiziksel günlük dosyası içeriyorsa, mantıksal günlük ilk fiziksel günlük dosyasının başlangıcına geri sarmalamadan önce tüm fiziksel günlük dosyaları arasında hareket eder.

Important

İşlem günlüğü boyutu yönetimi hakkında daha fazla bilgi için bkz. İşlem günlüğü dosyasının boyutunu yönetme.

Günlük kesilmesi

Günlük kesilmesi, günlüğün dolmasına engel olmak için gereklidir. SQL Server veritabanında günlük kesilmesi, mantıksal işlem günlüğünden etkin olmayan sanal günlük dosyalarını siler ve bu sayede fiziksel işlem günlüğünün tekrar kullanımına olanak tanıyan bir alan oluşturur. Bir işlem günlüğü asla küçültülmezse, sonunda fiziksel günlük dosyalarına ayrılan tüm disk alanını doldurur. Ancak, günlüğün kesilmesi için önce bir denetim noktası işlemi gerçekleşmelidir. Denetim noktası geçerli bellek içi değiştirilmiş sayfaları ( kirli sayfalar olarak bilinir) ve işlem günlüğü bilgilerini bellekten diske yazar. Denetim noktası gerçekleştirildiğinde, işlem günlüğünün etkin olmayan bölümü yeniden kullanılabilir olarak işaretlenir. Bundan sonra, günlük kesilmesi etkin olmayan bölümü serbestleştirebilir. Denetim noktaları hakkında daha fazla bilgi için bkz . Veritabanı denetim noktaları (SQL Server).

Aşağıdaki diyagramlarda, kesme işleminden önce ve sonra bir işlem günlüğü gösterilmektedir. İlk diyagramda daha önce hiç kesilmemiş bir işlem günlüğü gösterilir. Şu anda mantıksal günlük tarafından dört sanal günlük dosyası kullanılıyor. Mantıksal günlük, ilk sanal günlük dosyasının önünden başlar ve sanal günlük 4'te biter. MinLSN kaydı sanal günlük 3'tedir. Sanal günlük 1 ve sanal günlük 2 yalnızca etkin olmayan günlük kayıtlarını içerir. Bu kayıtlar kısaltılabilir. Sanal günlük 5 hala kullanılmamış ve geçerli mantıksal günlüğün parçası değil.

Trunk edilmeden önce işlem günlüğünün nasıl göründüğünü gösteren diyagram.

İkinci diyagramda, kırpıldıktan sonra günlüğün nasıl göründüğü gösterilir. Sanal günlük 1 ve sanal günlük 2 yeniden kullanım için serbest bırakılmış. Mantıksal günlük artık sanal günlük 3'ün başında başlar. Sanal günlük 5 hala kullanılmadı ve geçerli mantıksal günlüğün bir parçası değil.

İşlem günlüğünün kesildikten sonra nasıl göründüğünü gösteren diyagram.

Günlük kesintisi, bazı nedenlerden dolayı geciktirildiğinde hariç, aşağıdaki olaylardan sonra otomatik olarak gerçekleşir.

  • Basit kurtarma modelinde, bir denetim noktasından sonra.
  • Tam kurtarma modeli veya toplu günlüğe kaydedilen kurtarma modeli altında, bir günlük yedeklemesinin ardından, önceki yedeklemeden sonra bir denetim noktası oluştuysa.

Log kesilmesi çeşitli faktörler tarafından geciktirilebilir. Günlük kısaltılmasında uzun bir gecikme durumunda işlem kayıt günlüğü dolabilir. Bilgi için bkz Günlük kesimini geciktirebilecek faktörler ve Dolu bir işlem günlüğü sorunlarını giderme (SQL Server Hatası 9002).

İşlem öncesi yazma günlüğü

Bu bölümde, diske veri değişikliklerini kaydederken önceden yazma işlemi günlüğünün rolü açıklanmaktadır. SQL Server, ilişkili günlük kaydı (log kaydı) diske yazılmadan önce veri değişikliklerinin diske yazılmamasını garanti eden bir 'write-ahead logging (WAL)' algoritması kullanır. Bu, bir işlem için ACID özelliklerini korur.

WAL hakkında daha fazla bilgi için bkz. SQL Server G/Ç temelleri.

İşlem günlüğüyle ilgili olarak önceden yazma günlüğünün nasıl çalıştığını anlamak için, değiştirilen verilerin diske nasıl yazıldığından emin olmanız önemlidir. SQL Server, verilerin alınması gerektiğinde veri sayfalarını okuduğu bir arabellek önbelleği (arabellek havuzu olarak da adlandırılır) tutar. Bir sayfa arabellek önbelleğinde değiştirildiğinde, hemen diske geri yazılamaz; bunun yerine, sayfa kirli olarak işaretlenir. Veri sayfasında fiziksel olarak diske yazılmadan önce birden fazla mantıksal yazma işlemi yapılabilir. Her mantıksal yazma için, değişikliği kaydeden günlük önbelleğine bir işlem günlüğü kaydı eklenir. günlük kayıtlar, kirli sayfanın arabellek önbelleğinden kaldırılması ve diske yazılmasından önce diske yazılmalıdır. Denetim noktası işlemi, belirli bir veritabanına ait sayfaların bulunduğu tamponları aramak için tampon önbelleğini düzenli aralıklarla tarar ve tüm kirli sayfaları diske yazar. Denetim noktaları, tüm kirli sayfaların diske yazılmasının garantilendiği bir nokta oluşturarak daha sonra kurtarma sırasında zaman kazandırır.

Arabellek önbelleğinden diske değiştirilmiş bir veri sayfası yazmak, sayfayı temizleme olarak adlandırılır. SQL Server,ilişkili günlük kaydı yazılmadan önce kirli bir sayfanın boşaltılmasını engelleyen bir mantığa sahiptir. Günlük arabellekleri boşaltıldığında günlük kayıtları diske yazılır. Bu, bir işlem tamamlandığında veya günlük arabellekleri dolduğunda gerçekleşir.

İşlem günlüğü yedeklemeleri

Bu bölümde, işlem günlüklerini yedekleme ve geri yükleme (uygulama) ile ilgili kavramlar gösterilir. Tam ve toplu günlük kaydı kurtarma modellerinde, verileri kurtarmak için işlem günlüklerinin rutin yedekleri (günlük yedeklemeleri) alınması gerekir. Herhangi bir tam yedekleme çalışırken günlüğü yedekleyebilirsiniz. Kurtarma modelleri hakkında daha fazla bilgi için bkz. SQL Server veritabanlarını yedekleme ve geri yükleme.

İlk günlük yedeklemesini oluşturabilmeniz için önce veritabanı yedeklemesi veya dosya yedeklemeleri kümesindeki ilk yedekleme gibi tam bir yedekleme oluşturmanız gerekir. Veritabanını yalnızca dosya yedeklemelerini kullanarak geri yüklemek karmaşık hale gelebilir. Bu nedenle, uygun olduğunda tam veritabanı yedeklemesi ile başlamanızı öneririz. Bundan sonra, işlem günlüğünü düzenli olarak yedeklemek gerekir. Bu, yalnızca iş kaybına maruz kalma durumunu en aza indirmekle kalmaz, aynı zamanda işlem günlüğünün kesilmesini de etkinleştirir. Genellikle, işlem günlüğü her geleneksel günlük yedeğinden sonra kısaltılır.

Geri yüklemeniz gereken günlük yedeklemelerinin sayısını sınırlamak için verilerinizi düzenli olarak yedeklemeniz önemlidir. Örneğin, haftalık tam veritabanı yedeklemesi ve günlük değişiklik veritabanı yedeklemeleri zamanlayabilirsiniz.

Kurtarma stratejinizi uygularken gerekli RTO ve RPO'yu ve özellikle tam ve fark veritabanı yedekleme sıklığını düşünün.

İşlem günlüğü yedeklemeleri hakkında daha fazla bilgi için bkz . İşlem günlüğü yedeklemeleri (SQL Server).

Yedekleme sıklığı ve iş gereksinimleri

İş gereksinimlerinizi desteklemek için yeterince sık günlük yedeklemesi yapmalısınız; özellikle de hasarlı günlük depolamadan kaynaklanabilir gibi iş kaybına dayanıklılığınız.

Günlük yedeklerini alma sıklığı, iş kaybına maruz kalma toleransınız ile depolayabileceğiniz, yönetebileceğiniz ve potansiyel olarak geri yükleyebileceğiniz log yedekleri miktarını dengeleyerek belirlenir. Kurtarma stratejinizi uygularken gerekli kurtarma süresi hedefini (RTO) ve kurtarma noktası hedefini (RPO) ve özellikle günlük yedekleme temposunu düşünün.

Her 15-30 dakikada bir günlük kayıt yedeği almak yeterli olabilir. İşletmeniz iş kaybına maruz kalma durumunu en aza indirmenizi gerektiriyorsa günlük yedeklemelerini daha sık almayı göz önünde bulundurun. Daha sık yapılan günlük yedeklemeleri, günlük kesme sıklığını artırmanın ek avantajına sahiptir ve bu da günlük dosyalarının daha küçük olmasıyla sonuçlanır.

Kayıt zinciri

Günlük yedeklemelerinin sürekli dizisine günlük zinciri adı verilir. Günlük zinciri, veritabanının tam yedeklemesiyle başlar. Genellikle, yeni bir günlük zinciri yalnızca veritabanı ilk kez yedekleme yapıldığında veya kurtarma modeli, basit kurtarmadan tam veya toplu kayıtlı kurtarmaya geçirildikten sonra başlatılır. Tam veritabanı yedeklemesi oluştururken mevcut yedekleme kümelerinin üzerine yazmayı seçmediğiniz sürece, mevcut günlük zinciri değişmeden kalır. Günlük zinciri bozulmadan, medya kümesindeki herhangi bir tam veritabanı yedeğinden ve ardından kurtarma noktanıza kadar olan tüm sonraki günlük yedeklemelerinden veritabanınızı geri yükleyebilirsiniz. Kurtarma noktası, son günlük yedeklemesinin sonu veya günlük yedeklemelerinden herhangi birinde belirli bir kurtarma noktası olabilir. Daha fazla bilgi için bkz . İşlem günlüğü yedeklemeleri (SQL Server).

Veritabanını hata noktasına kadar geri yüklemek için günlük zincirinin bozulmamış olması gerekir. Yani, işlem günlüğü yedeklemelerinin kesintisiz dizisi hata noktasına kadar genişletilmelidir. Bu günlük dizisinin başlaması gereken yer, geri yüklediğiniz veri yedeklemelerinin türüne bağlıdır: veritabanı, kısmi veya dosya. Veritabanı veya kısmi yedekleme için günlük yedeklerinin dizisi, veritabanı veya kısmi yedekleme işleminin ardından devam etmelidir. Bir dizi dosya yedeklemesi için günlük yedeklemeleri dizisi, tam dosya yedeklemeleri kümesinin başından itibaren genişletilmelidir. Daha fazla bilgi için bkz. İşlem Günlüğü Yedeklemelerini Uygulama (SQL Server).

Kayıt yedeklemelerini geri yükleme

İşlem günlüğü yedeğinin geri yüklenmesi, günlük yedekleme işleminin başlatıldığı andaki veritabanının tam durumunu yeniden oluşturmak için işlem günlüğüne kaydedilen değişiklikleri uygular. Veritabanını geri yüklerken, geri yüklediğiniz tam veritabanı yedeklemesinden sonra veya geri yüklediğiniz ilk dosya yedeklemesinin başlangıcından sonra oluşturulan günlük yedeklemelerini geri yüklemeniz gerekir. Genellikle, en son verileri veya değişiklik yedeklemesini geri yükledikten sonra, kurtarma noktanıza ulaşana kadar bir dizi günlük yedeğini geri yüklemeniz gerekir. Ardından veritabanını kurtaracaksınız. Bu işlem, kurtarma başlatıldığında tamamlanmamış olan tüm işlemleri geri alır ve veritabanını çevrimiçine getirir. Veritabanı kurtarıldıktan sonra, daha fazla yedekleme geri yükleyemezsiniz. Daha fazla bilgi için bkz. İşlem Günlüğü Yedeklemelerini Uygulama (SQL Server).

Kontrol noktaları ve kaydın etkin bölümü

Denetim noktaları kirli veri sayfalarını geçerli veritabanının arabellek önbelleğinden diske boşaltır. Bu durum, veritabanının tam kurtarılması sırasında işlenmesi gereken günlük kayıtlarının etkin bölümünü en aza indirir. Tam kurtarma sırasında aşağıdaki eylem türleri gerçekleştirilir:

  • Sistem durdurulmadan önce diske boşaltılmayan değişikliklerin günlük kayıtları ileriye doğru alınır.
  • Eksik işlemlerle ilişkilendirilmiş, örneğin kaydı olmayan COMMIT veya ROLLBACK günlük kaydı olmayan işlemler gibi tüm değişiklikler geri alınır.

Denetim noktası işlemi

Bir denetim noktası veritabanında aşağıdaki işlemleri gerçekleştirir:

  • Denetim noktasının başlangıcını işaretleyerek günlük dosyasına bir kayıt yazar.

  • Denetim noktası için kaydedilen bilgileri denetim noktası günlük kayıtları zincirinde depolar.

    Denetim noktasına kaydedilen bilgilerden biri, başarılı bir veritabanı çapında geri alma için bulunması gereken ilk günlük kaydının LSN'idir (günlük dizisi numarası). Bu LSN, En Düşük Kurtarma LSN'si (MinLSN) olarak adlandırılır. MinLSN, aşağıdakilerin en küçük değeridir:

    • Denetim noktasının başlangıcının LSN'sini seçin.
    • En eski etkin işlemin başlangıç LSN değeri.
    • Henüz dağıtım veritabanına teslim edilmemiş en eski çoğaltma işleminin başlangıç LSN'si.

    Denetim noktası kayıtları, veritabanını değiştiren tüm etkin işlemlerin listesini de içerir.

  • Veritabanı basit kurtarma modelini kullanıyorsa MinLSN'nin önündeki boşluğu yeniden kullanmak için işaretler.

  • Tüm kirli günlük ve veri sayfalarını diske yazar.

  • Denetim noktasının sonunu işaretleyerek günlük dosyasına bir kayıt yazar.

  • Bu zincirin başlangıcının LSN'sini veritabanı önyükleme sayfasına yazar.

Denetim noktasına neden olan etkinlikler

Denetim noktaları aşağıdaki durumlarda oluşur:

  • Bir CHECKPOINT deyim açıkça yürütülür. Bağlantının geçerli veritabanında bir denetim noktası oluşur.

  • Veritabanında minimum düzeyde günlüğe kaydedilen bir işlem gerçekleştirilir; örneğin, Bulk-Logged kurtarma modelini kullanan bir veritabanında toplu kopyalama işlemi gerçekleştirilir.

  • Veritabanı dosyaları kullanılarak ALTER DATABASEeklendi veya kaldırıldı.

  • SQL Server örneği bir SHUTDOWN deyim tarafından veya SQL Server (MSSQLSERVER) hizmeti durdurularak durdurulur. Her iki eylem de SQL Server örneğindeki her veritabanında bir denetim noktasına neden olur.

  • SQL Server örneği, örneğin veritabanını kurtarmak için gereken süreyi azaltmak için her veritabanında düzenli aralıklarla otomatik denetim noktaları oluşturur.

  • Veritabanı yedeği alınır.

  • Veritabanı kapatma gerektiren bir etkinlik gerçekleştirilir. Seçenek olduğunda AUTO_CLOSE ve veritabanına son kullanıcı bağlantısı kapatıldığında ON bu durum oluşabilir. Başka bir örnek, veritabanının yeniden başlatılmasını gerektiren bir veritabanı seçeneği değişikliğinin yapılmasıdır.

Otomatik denetim noktaları

SQL Server Veritabanı Altyapısı otomatik denetim noktaları oluşturur. Otomatik denetim noktaları arasındaki aralık, kullanılan günlük alanı miktarına ve son denetim noktasından bu yana geçen süreye bağlıdır. Veritabanında birkaç değişiklik yapıldığında otomatik denetim noktaları arasındaki zaman aralığı yüksek oranda değişken ve uzun olabilir. Çok fazla veri değiştirildiğinde otomatik denetim noktaları da sık sık oluşabilir.

Bir sunucu örneğindeki tüm veritabanları için otomatik denetim noktaları arasındaki aralığı hesaplamak için kurtarma aralığı sunucu yapılandırma seçeneğini kullanın. Bu seçenek, sistem yeniden başlatma sırasında Veritabanı Altyapısı'nın veritabanını kurtarmak için kullanması gereken en uzun süreyi belirtir. Veritabanı Altyapısı, kurtarma işlemi sırasında kurtarma aralığında kaç günlük kaydı işleyebileceğini tahmin eder.

Otomatik denetim noktaları arasındaki aralık kurtarma modeline de bağlıdır:

  • Veritabanı, tam veya toplu günlüğe kaydedilen kurtarma modelini kullanıyorsa, günlük kayıtları sayısı Veritabanı Motoru'nun kurtarma aralığı seçeneğinde belirtilen süre içinde işleyebileceği sayıya ulaştığında otomatik bir denetim noktası oluşturulur.

  • Veritabanı basit kurtarma modelini kullanıyorsa, günlük kaydı sayısı bu iki değerden daha az değere ulaştığında otomatik bir denetim noktası oluşturulur:

    • Günlük kayıtları yüzde 70 dolu olur.
    • Günlük kayıtlarının sayısı, Veritabanı Altyapısı'nın kurtarma aralığı seçeneğinde belirtilen süre boyunca işleyebileceği tahmini sayıya ulaşır.

Kurtarma aralığını ayarlama hakkında bilgi için bkz . Sunucu yapılandırması: kurtarma aralığı (min).

Tip

-k SQL Server gelişmiş kurulum seçeneği, veritabanı yöneticisinin bazı denetim noktası türleri için G/Ç alt sisteminin aktarım hızına göre denetim noktası G/Ç davranışını azaltmasına olanak tanır. -k Ayar seçeneği otomatik denetim noktalarına ve başka şekilde sınırlanmamış denetim noktalarına uygulanır.

Otomatik denetim noktaları, veritabanı basit kurtarma modelini kullanıyorsa, işlem günlüğünün kullanılmayan bölümünü kısaltır. Ancak, veritabanı tam veya toplu kayıt kurtarma modellerini kullanıyorsa, günlük otomatik denetim noktaları tarafından kesilmez. Daha fazla bilgi için bkz . İşlem günlüğü.

deyimi CHECKPOINT artık denetim noktalarının bitmesi için istenen süreyi saniye cinsinden belirten isteğe bağlı bir checkpoint_duration bağımsız değişkeni sağlar. Daha fazla bilgi için bkz . CHECKPOINT.

Etkin günlük

MinLSN'den son yazılan günlük kaydına kadar olan günlük dosyasının bölümü, günlüğün etkin bölümü veya etkin günlük olarak adlandırılır. Bu, veritabanının tam kurtarımı için gereken günlüğün bölümüdür. Aktif günlüğün hiçbir bölümü asla kesilip küçültülemez. Tüm log kayıtları MinLSN'den önceki log bölümlerinden kısaltılmalıdır.

Aşağıdaki diyagramda, iki etkin işlem içeren işlem sonu günlüğünün basitleştirilmiş bir sürümü gösterilmektedir. Denetim noktası kayıtları tek bir kayda sıkıştırıldı.

İki etkin işlem ve sıkıştırılmış denetim noktası kaydı içeren bir işlem sonu günlüğünü gösteren diyagram.

LSN 148, işlem günlüğündeki son kayıttır. LSN 147'de kaydedilen denetim noktası işlendiği sırada, Tran 1 taahhüt edildi ve tek aktif işlem Tran 2'ydi. Bu, Tran 2 için ilk günlük kaydını, son denetim noktasındaki aktif işlem için en eski günlük kaydı yapar. Bu, LSN 142'yi, Tran 2 için Başlangıç işlem kaydı olarak MinLSN yapar.

Uzun süre çalışan işlemler

Aktif günlük, tüm tamamlanmamış işlemlerin her bölümünü içermelidir. İşlem başlatıp onaylamayan veya geri almayan bir uygulama, Veritabanı Motoru'nun MinLSN'yi ilerletmesini engeller. Bu durum iki tür soruna neden olabilir:

  • İşlem çok sayıda kaydedilmemiş değişiklik yaptıktan sonra sistem kapatılırsa, sonraki yeniden başlatmanın kurtarma aşaması kurtarma aralığı seçeneğinde belirtilen süreden çok daha uzun sürebilir.
  • Günlük, MinLSN'nin ötesine kesilemediği için çok büyük hale gelebilir. Veritabanı her otomatik denetim noktasında işlem günlüğünün kesildiği basit kurtarma modelini kullanıyor olsa bile bu durum oluşur.

Sql Server 2019 (15.x) ve Azure SQL Veritabanı ile başlayan hızlandırılmış veritabanı kurtarma özelliği kullanılarak uzun süre çalışan işlemlerin kurtarılması ve bu makalede açıklanan sorunlardan kaçınılabilir.

Çoğaltma işlemleri

Günlük Okuyucu Aracısı, işlem çoğaltması için yapılandırılan her veritabanının işlem günlüğünü izler ve işlem günlüğünden çoğaltma için işaretlenen işlemleri dağıtım veritabanına kopyalar. Etkin günlük, çoğaltma için işaretlenmiş ancak henüz dağıtım veritabanına teslim edilmemiş tüm işlemleri içermelidir. Bu işlemler zamanında çoğaltılamazsa, günlüğün kesilmesini önleyebilir. Daha fazla bilgi için bkz. İşlem Çoğaltma.

İlgili içerik

  • Last updated on