SQL Server'dan veritabanlarını Günlük Yineleme Servisi kullanarak taşıma - Azure SQL Managed Instance

Şunlar için geçerlidir:Azure SQL Managed Instance

Bu makalede, Log Yeniden Yürütme Hizmeti (LRS) kullanarak SQL Server veritabanlarını Azure SQL Managed Instance'a geçiş işlemleri açıklanmaktadır. LRS, Azure SQL Managed Instance geçişleri için SQL Server günlük gönderim teknolojisi üzerine kurulmuş ücretsiz bir bulut hizmetidir. Başarılı bir veritabanı geçişi için en iyi yöntemler de dahil olmak üzere önkoşullardan tam geçişe kadar tüm süreci öğrenin.

Not

Artık Azure Arc tarafından etkinleştirilen SQL Server örneğinizi doğrudan Azure portalı üzerinden Azure SQL Managed Instance geçirebilirsiniz. Daha fazla bilgi edinmek için Migrate to Azure SQL Managed Instance gözden geçirin.

Aşağıdaki kaynaklar desteklenir:

• SQL Server Sanal Makinelerde
• Amazon EC2 (Elastik İşlem Bulutu)
• SQL Server için Amazon RDS (İlişkisel Veritabanı Hizmeti)
• Google Compute Engine
• SQL Server için Cloud SQL - GCP (Google Cloud Platform)

Önkoşullar

Önemli

• Veritabanlarını İş Açısından Kritik hizmet katmanına geçirmeden önce, Genel Amaçlı hizmet katmanı için geçerli olmayan bu sınırlamaları göz önünde bulundurun.
• Geçiş işlemi bitene kadar LRS aracılığıyla geri yüklenen veritabanlarını kullanamazsınız.
• LRS, geçiş sırasında veritabanlarına salt okunur erişimi desteklemez.
• Geçiş tamamlandıktan sonra geçiş işlemi sonlanır ve ek değişiklik yedeklemeleriyle sürdürülemez.

Başlamadan önce hem SQL Server örneğiniz hem de Azure için bu bölümdeki gereksinimleri göz önünde bulundurun. Geçişin başarılı olduğundan emin olmak için sınırlamaları ve en iyi yöntemler bölümlerini dikkatle gözden geçirin.

SQL Server

SQL Server için aşağıdaki gereksinimleri karşıladığınızdan emin olun:

• SQL Server sürümleri 2008 ile 2022 arasındaki.
• SQL Server veritabanınız tam kurtarma modelini kullanıyor (zorunlu).
• Veritabanlarının tam yedeklemesi (bir veya birden çok dosya).
• Diferansiyel yedekleme (bir veya birden çok dosya).
• Bir işlem günlüğü dosyası için bölünmemiş log yedeği.
• 2008 ile 2016 arasında SQL Server sürümler için yerel olarak yedek alın ve manually upload Azure Blob Storage hesabınıza yükleyin.
• SQL Server 2016 ve üzeri için Azure Blob Storage hesabınıza yedeklemenizi doğrudan alabilirsiniz.
• Yedeklemeler için CHECKSUM'ün etkinleştirilmesi gerekmese de, istemeden bozuk bir veritabanının taşınmasını önlemek ve geri yükleme işlemlerini hızlandırmak için şiddetle tavsiye edilir.
• Windows Server herhangi bir sürümü, SQL Server sürümü desteklenebilirliğine göre desteklenir.
• SQL Server 2019 ve sonraki sürümler için, kalıcı sürüm deposu PRIMARY olarak ayarlanmış şekilde hızlandırılmış veritabanı kurtarma etkinleştirilmelidir. Daha fazla bilgi için bu makaledeki SQL Managed Instance'a geçiş sonrası bilinen sorunlar bölümüne bakın.
• Hizmet Aracısı'nı Azure SQL Managed Instance geçirilen bir veritabanında kullanmak için, geçiş öncesinde kaynak veritabanında Hizmet Aracısı'nın etkinleştirilmesi gerekir. Daha fazla bilgi için bu makaledeki SQL Managed Instance'a geçiş sonrası bilinen sorunlar bölümüne bakın.

Azure

Azure için aşağıdaki gereksinimleri karşıladığınızdan emin olun:

• PowerShell Az.SQL modülü sürüm 4.0.0 veya üzeri (yüklenmiş veya Azure Cloud Shell aracılığıyla erişilebilir).
• Azure CLI sürüm 2.42.0 veya üzeri (kurulu).
• Sağlanan Azure Blob Storage kapsayıcısı.
• Blob Storage kapsayıcısı için oluşturulan Read ve List izinlerine veya kapsayıcıya erişebilen yönetilen kimliğe sahip paylaşılan erişim imzası (SAS) güvenlik belirteci. Read ve List'den daha fazla izin verilmesi LRS'nin başarısız olmasına neden olur.
• Tek bir veritabanı için yedekleme dosyalarını düz dosya yapısı (zorunlu) kullanarak depolama hesabındaki ayrı bir klasöre yerleştirin. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.

Azure RBAC İzinleri

LRS'nin sağlanan istemciler aracılığıyla çalıştırılması için aşağıdaki Azure rol tabanlı erişim denetimi (RBAC) rollerinden biri gerekir:

• SQL Yönetilen Örnek Katılımcısı rolü
• Şu izne sahip bir rol: Microsoft.Sql/managedInstances/databases/*

En iyi yöntemler

LRS kullanırken aşağıdaki en iyi yöntemleri göz önünde bulundurun:

• Tek bir dosya kullanmak yerine tam ve değişiklik yedeklemelerini birden çok dosyaya bölün.
• Ağ aktarım hızlarına yardımcı olmak için yedekleme sıkıştırmasını etkinleştirin.
• PowerShell veya CLI betiklerini çalıştırmak için Cloud Shell kullanın, çünkü her zaman en son yayımlanan cmdlet'leri kullanacak şekilde güncelleştirilir.
• Geçişin gecikmesini veya kesintiye uğramasını önlemek için sistem güncelleştirmelerinin geçiş penceresinin dışında belirli bir gün ve saatte zamanlanması için bir bakım penceresi yapılandırın.
• Tek bir LRS geçiş işini en fazla 30 gün içinde tamamlamayı planlayın. Bu zaman çerçevesinin sona ermesi üzerine LRS işi otomatik olarak iptal edilir.
• Bozuk bir veritabanını istemeden geçirmeyi önlemek ve daha hızlı bir veritabanı geri yüklemesi için yedeklerinizi alırken etkinleştirin CHECKSUM . SQL Managed Instance CHECKSUM olmadan yedeklemelerde temel bir bütünlük denetimi gerçekleştirse de, her türlü bozulmanın yakalanması garanti değildir. CHECKSUM ile yedekleme almak, SQL Managed Instance geri yüklenen yedeklemenin bozuk olmadığından emin olmak için tek yoldur. CHECKSUM olmadan yapılan yedeklemelerdeki temel bütünlük denetimi, veritabanının geri yükleme süresini artırır.
• İş Açısından Kritik hizmet katmanına geçiş yaparken, veritabanları ikincil çoğaltmalara dağıtılırken, tam geçişten sonra veritabanı erişiminde uzun bir gecikme olacağını göz önünde bulundurun. Özellikle en düşük kapalı kalma süresi gereksinimlerine sahip büyük veritabanları için önce Genel Amaçlı hizmet katmanına geçmeyi ve ardından Business Critical hizmet katmanına yükseltmeyi veya verilerinizi geçirmek için Managed Instance bağlantısını kullanmayı göz önünde bulundurun.
• Geri yüklemek için binlerce veritabanı dosyasını karşıya yüklemek, aşırı geçiş sürelerine ve hatta başarısızlığa neden olabilir. Geçiş işlemini hızlandırmak ve başarılı olduğundan emin olmak için veritabanlarını daha az dosyada birleştirin.
• Tam geçiş süresini en aza indirmek ve hata riskini azaltmak için son yedeklemenizin mümkün olduğunca küçük olduğundan emin olun.

Bakım penceresi yapılandırma

SQL Managed Instance için sistem güncelleştirmeleri, devam eden veritabanı geçişlerinden önceliklidir.

Geçiş, hizmet katmanına göre farklı şekilde etkilenir:

• Genel Amaçlı hizmet katmanında, bekleyen tüm LRS geçişleri güncelleştirme uygulanmadan önce askıya alınır ve yalnızca güncelleştirme uygulandıktan sonra devam ettirilir. Bu sistem davranışı, özellikle büyük veritabanları için geçiş süresini uzatabilir.
• İş Açısından Kritik hizmet katmanında, bekleyen tüm LRS geçişleri iptal edilir ve güncelleştirme uygulandıktan sonra otomatik olarak yeniden başlatılır. Bu sistem davranışı, özellikle büyük veritabanları için geçiş süresini uzatabilir.

Veritabanı geçişleri için öngörülebilir bir süre elde etmek için, sistem güncelleştirmelerini belirli bir gün ve saat için zamanlayacak bir bakım penceresi yapılandırmayı ve belirlenen bakım penceresi zaman çerçevesinin dışında geçiş işlerini çalıştırmayı ve tamamlamayı göz önünde bulundurun. Örneğin, Pazartesi günü başlayan bir geçiş için, pazar günü özel bakım pencerenizi geçişi tamamlamak için en fazla süre tanıyacak şekilde yapılandırın.

Bakım penceresi yapılandırmak gerekli değildir, ancak büyük veritabanları için kesinlikle önerilir.

Not

Bakım penceresi planlı güncelleştirmelerin öngörülebilirliğini denetler ancak planlanmamış yük devretmelerin veya güvenlik düzeltme eki güncelleştirmelerinin gerçekleşmeyeceğini garanti etmez. Planlanmamış bir yük devretme veya güvenlik düzeltme eki (diğer tüm güncelleştirmelere göre önceliklidir) geçişinizi kesintiye uğratabilir.

Birden çok veritabanını geçirme

Aynı Azure Blob Storage kapsayıcısını kullanarak birden çok veritabanını geçiriyorsanız, farklı veritabanları için yedekleme dosyalarını kapsayıcının içindeki ayrı klasörlere yerleştirmeniz gerekir. Tek bir veritabanı için tüm yedekleme dosyaları, veritabanı klasörünün içindeki düz dosya yapısına yerleştirilmelidir ve klasörler iç içe yerleştirilemiyor. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.

Aşağıda, Azure Blob Storage kapsayıcısının içindeki bir klasör yapısı örneği, LRS kullanarak birden çok veritabanını geçirmek için gereken bir yapı.

-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>

-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>

-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>

Depolama hesabı oluşturma

SQL Server örneğin ve SQL Managed Instance dağıtımınız arasında yedekleme dosyaları için aracı depolama alanı olarak bir Azure Blob Storage hesabı kullanırsınız. Depolama hesabı içinde yeni bir depolama hesabı ve blob kapsayıcısı oluşturmak için:

1. Depolama hesabı oluşturma.
2. Depolama hesabının içinde bir blob kapsayıcısı oluşturun.

Güvenlik duvarının arkasındaki Azure depolamayı yapılandırma

Bir güvenlik duvarının arkasında korunan Azure Blob depolamanın kullanılması desteklenir, ancak ek yapılandırma gerektirir. Azure Firewall açıkken Azure Storage'a okuma/yazma erişimi sağlamak için, SQL yönetilen örneğinin alt ağını, depolama hesabı için sanal ağın güvenlik duvarı kurallarına MI alt ağ delegasyonu ve Depolama hizmeti uç noktası kullanarak eklemeniz gerekir. Depolama hesabı ve yönetilen örnek aynı bölgede veya iki eşleştirilmiş bölgede olmalıdır.

Azure depolama alanınız bir güvenlik duvarının arkasındaysa SQL yönetilen örneği hata günlüğünde aşağıdaki iletiyi görebilirsiniz:

Audit: Storage access denied user fault. Creating an email notification:

Bu, SQL Yönetilen Örnek için denetim günlüklerini depolama hesabına yazamadığını bildiren bir e-posta oluşturur. Bu hatayı görürseniz veya bu e-postayı alırsanız, güvenlik duvarınızı yapılandırmak için bu bölümdeki adımları izleyin.

Güvenlik duvarını yapılandırmak için şu adımları izleyin:

1. Azure portalında SQL yönetilen örneğine gidin ve alt ağı seçerek Ubnets sayfasını açın.

   

2. Alt ağlar sayfasında alt ağın adını seçerek alt ağ yapılandırma sayfasını açın.

   

3. Alt ağ temsili altında Microsoft.Sql/managedInstances seçin ve Bir hizmete alt ağı devret açılır listesinden. İzinlerin yayılması için yaklaşık bir saat bekleyin ve Hizmet uç noktaları altında Hizmetler açılır listesinden Microsoft.Storage'i seçin.

   

4. Ardından, Azure portalında depolama hesabınıza gidin, Güvenlik + ağ altında Networking seçin ve ardından Firewalls ve sanal ağlar sekmesini seçin.

5. Depolama hesabınızın Güvenlik duvarları ve sanal ağlar sekmesinde + Var olan sanal ağı ekle'yi seçerek Ağ ekle sayfasını açın.

   

6. Açılan liste menülerinden uygun aboneliği, sanal ağı ve yönetilen örnek alt ağını seçin ve ardından SQL yönetilen örneğinin sanal ağını depolama hesabına eklemek için Ekle'yi seçin.

Blob Storage hesabınızda kimlik doğrulaması

Azure Blob Storage hesabınıza erişmek için SAS belirteci veya yönetilen kimlik kullanın.

Uyarı

Aynı depolama hesabında hem SAS belirteci hem de yönetilen kimliği paralel olarak kullanamazsınız. SAS belirteci veya yönetilen kimlik kullanabilirsiniz, ancak ikisini birden kullanamazsınız.

SAS belirteci

LRS için Blob Storage SAS kimlik doğrulama belirteci oluşturma

SAS belirteci kullanarak Azure Blob Storage hesabınıza erişin.

SQL Server örneğiniz ile SQL Managed Instance dağıtımınız arasında yedekleme dosyaları için aracı depolama alanı olarak bir Azure Blob Storage hesabı kullanabilirsiniz. LRS için yalnızca Okuma ve Listeleme izinlerine sahip bir SAS kimlik doğrulama belirteci oluşturun. Belirteç, LRS'nin Blob Storage hesabınıza erişmesini sağlar ve bunları yönetilen örneğine geri yüklemek için yedekleme dosyalarını kullanır.

Belirteci oluşturmak için şu adımları izleyin:

1. Azure portalında Depolama merkezi gidin ve depolama hesabınızı seçin.

2. Güvenlik + ağ altındaPaylaşılan erişim imzası'nı seçerek Paylaşılan erişim imzası bölmesini açın.

3. Paylaşılan erişim imzası bölmesinde, LRS için sas belirteci oluşturmak üzere ayarları yapılandırın. Ayarları yapılandırmak için aşağıdaki yönergeleri kullanın:

   1. İzin verilen hizmetler: Blob ve Dosya.

   2. İzin verilen kaynak türleri: Hizmet.

   3. İzinler: Yalnızca Okuma ve Listeleme .

      Önemli

      Başka bir izin seçmeyin. Bunu yaparsanız, LRS başlamaz. Bu güvenlik gereksinimi tasarım gereğidir.

   4. Blob sürüm oluşturma izinleri: İsteğe bağlı

   5. İzin verilen blob dizini izinleri: Devre dışı bırakılabilir.

   6. Belirtecin saat dilimini seçin: UTC veya yerel saat.

      Önemli

      Belirtecin saat dilimi ve yönetilen örneğinizin saat dilimi eşleşmeyebilir. Saat dilimlerini dikkate alarak SAS belirtecinin uygun saat geçerliliğine sahip olduğundan emin olun. Saat dilimi farklarını hesaba eklemek için geçiş pencereniz başlamadan önce Kimden değerinin geçerliliğini ve geçişinizin tamamlanmasını bekledikten sonra To değerini iyi ayarlayın.

   7. Belirteci oluşturmak için SAS ve bağlantı dizesi oluştur'u seçin.

   

   SAS kimlik doğrulaması, belirttiğiniz zaman geçerliliği ile oluşturulur.

4. LRS'yi başlatmak için ihtiyacınız olan belirtecin URI sürümü olan Blob Hizmeti SAS URL'si alanında sağlanan değeri kopyalayın.

Not

Depolanan erişim ilkesi tanımlanarak ayarlanan izinlerle oluşturulan SAS belirteçlerinin kullanılması şu anda desteklenmemektedir. SAS belirtecinin Okuma ve Listeleme izinlerini el ile belirtmek için bu yordamdaki yönergeleri izleyin.

SAS belirtecinden parametreleri kopyalama

SAS belirteci veya yönetilen kimlik kullanarak Azure Blob Storage hesabınıza erişin.

LRS'yi başlatmak için SAS belirtecini kullanmadan önce yapısını anlamanız gerekir. Oluşturulan SAS belirtecinin URI'si, bu örnekte gösterildiği gibi soru işareti ()? ile ayrılmış iki bölümden oluşur:

https:// ile soru işareti (?) arasındaki ilk bölüm, LRS'ye giriş olarak beslenen StorageContainerURI parametresi için kullanılır. Veritabanı yedekleme dosyalarının depolandığı klasör hakkında LRS bilgileri verir.

Soru işaretinden (?) sonra dizenin sonuna kadar olan ikinci bölüm parametresidir StorageContainerSasToken . Bu bölüm, belirtilen süre boyunca geçerli olan gerçek imzalı kimlik doğrulama belirtecidir. Bu bölümün örnekte gösterildiği gibi ile sp= başlaması gerekmez. Senaryonuz farklı olabilir.

Parametreleri aşağıdaki gibi kopyalayın:

1. Belirtecin ilk bölümünü, https:// ile soru işaretine kadar (soru işareti hariç) kopyalayın. PowerShell veya Azure CLI'da, LRS'yi başlatırken StorageContainerUri parametresi olarak kullanın.

2. Soru işaretinden (?) sonradan dizenin sonuna kadar belirtecin ikinci bölümünü kopyalayın. PowerShell veya Azure CLI'da, LRS'yi başlatırken StorageContainerSasToken parametresi olarak kullanın.

Not

Belirtecin herhangi bir bölümünü kopyalarken soru işaretini (?) eklemeyin.

Yönetilen kimlik

Yönetilen kimlik kullanmak için, Azure Blob Storage kapsayıcısına erişmek için sistem tarafından yönetilen veya kullanıcı tarafından yönetilen bir kimlik atayın.

Bunu yapmak için aşağıdaki adımları izleyin:

1. Azure portalında yönetilen örnek erişimini yetkilendirmeyi planladığınız Blob Storage hesabına gidin.
2. Erişim denetimi (IAM) öğesini seçin.
3. Ekle'yi ve ardından Rol ataması ekle'yi seçin.
4. Mevcut rolü (Depolama Blobu Veri Okuyucusu) arayın ve seçin. Özel roller, Okuma ve Listeleme izinlerine sahip oldukları sürece en az düzeyde desteklenir.
5. Yönetilen Kimlik'i seçin.
6. Aboneliğinizi tanımlamak için Üyeleri seçin seçeneğini kullanın.
7. Managed Identity açılan listesinde SQL Managed Instance öğesini seçin ve sonra da geçirmek istediğiniz yönetilen örneği seçin.
8. Ayarlarınızı kaydetmek ve erişimi yetkilendirmek için Seç'i seçin.
9. Gözden geçir + ata'yı seçerek işlemi tamamlayın.

Yönetilen örnek depolama erişiminizi doğrulama

Yönetilen örneğinizin Blob Storage hesabınıza erişebildiğini doğrulayın.

İlk olarak, full_0_0.bak gibi tüm veritabanı yedeklemelerini Azure Blob Storage kapsayıcınıza yükleyin.

Ardından yönetilen örneğinize bağlanın ve yönetilen örneğinizin kapsayıcıdaki yedeklemeye erişip erişemeyeceğini belirlemek için örnek bir test sorgusu çalıştırın.

SAS belirteci

Depolama hesabınızda kimlik doğrulaması yapmak için SAS belirteci kullanıyorsanız, ilk olarak <sastoken> değerini SAS belirtecinizle değiştirin. Ardından, örneğinizde aşağıdaki sorguyu çalıştırın:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/databases]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<sastoken>';

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

Yönetilen kimlik

Depolama hesabınıza kimlik doğrulamak için yönetilen kimlik kullanıyorsanız, CREATE CREDENTIAL öğesini depolama hesabı URL'nizle güncelleyin ve aşağıdaki örnek sorguyu örneğinizde çalıştırın.

RESTORE HEADERONLY
    FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak';

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'MANAGED IDENTITY';

yedekleri Blob Storage hesabınıza yükleme

Blob kapsayıcınız hazır olduğunda ve yönetilen örneğinizin kapsayıcıya erişebildiğini onayladıktan sonra yedeklemelerinizi Blob Storage hesabınıza yüklemeye başlayabilirsiniz. Şunlardan birini yapabilirsiniz:

• Yedeklerinizi Blob Storage hesabınıza kopyalayın.
• Ortamınız izin veriyorsa (SQL Server sürüm 2012 SP1 CU2 ve SQL Server 2014'ten başlayarak) BACKUP TO URL komutunu kullanarak SQL Server doğrudan Blob Storage hesabınıza yedek alın.

Mevcut yedeklemeleri Blob Storage hesabınıza kopyalama

SQL Server'nin önceki bir sürümündeyseniz veya ortamınız doğrudan bir URL'ye yedeklemeyi desteklemiyorsa, yedeklerinizi SQL Server örneğiniz üzerinde normalde yaptığınız gibi alın ve Blob Storage hesabınıza kopyalayın.

SQL Server örneğinde yedek alma

Günlük yedeklemelerine izin vermek için tam kurtarma modeline geçirmek istediğiniz veritabanlarını ayarlayın.

-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master;

ALTER DATABASE SampleDB
SET RECOVERY FULL;
GO

Veritabanınızın tam, değişiklik ve günlük yedeklemelerini yerel depolama alanına el ile yapmak için aşağıdaki örnek T-SQL betiklerini kullanın. CHECKSUM gerekli değildir, ancak bozuk bir veritabanının taşınamamasını önlemek ve geri yükleme işlemlerinin hızlanması için önerilir.

Aşağıdaki örnek, yerel diske tam veritabanı yedeklemesi alır:

-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

Aşağıdaki örnek, yerel diske diferansiyel yedek alır.

-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

Aşağıdaki örnek, yerel diske bir işlem günlüğü yedeklemesi alır:

-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
    TO DISK = 'C:\BACKUP\SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;
GO

Yedeklemeleri Blob Storage hesabınıza kopyalama

Yedeklemeleriniz hazır olduktan ve veritabanlarını LRS kullanarak yönetilen örneğe geçirmeye başlamak istiyorsanız, mevcut yedeklemeleri Blob Storage hesabınıza kopyalamak için aşağıdaki yaklaşımları kullanabilirsiniz:

• AzCopy indirin ve yükleyin.
• Azure Storage Explorer indirip yükleyin.
• Azure portalında Storage Explorer kullanın.

Not

Aynı Azure Blob Storage kapsayıcısını kullanarak birden çok veritabanını geçirmek için, tek bir veritabanının tüm yedekleme dosyalarını kapsayıcı içinde ayrı bir klasöre yerleştirin. Her veritabanı klasörü için düz dosya yapısı kullanın. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.

Yedeklemeleri doğrudan Blob Storage hesabınıza alma

Eğer SQL Server 2012 SP1 CU2 ve SQL Server 2014'ten itibaren desteklenen bir SQL Server sürümünü kullanıyorsanız ve şirket ve ağ ilkeleriniz buna izin veriyorsa, yerel SQL Server BACKUP TO URL seçeneğini kullanarak doğrudan SQL Server'dan Blob Storage hesabınıza yedek alabilirsiniz. BACKUP TO URL'ı kullanabiliyorsanız, yedeklemeleri yerel depolama alanına almanız ve Blob Storage hesabınıza yüklemeniz gerekmez.

Yerel yedeklemeleri doğrudan Blob Storage hesabınıza aldığınızda, depolama hesabında kimlik doğrulaması yapmanız gerekir.

SAS belirtecini SQL Server örneğine aktaran bir kimlik bilgisi oluşturmak için aşağıdaki komutu kullanın:

CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
    WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
    SECRET = '<SAS_TOKEN>';

SAS belirteçleriyle ilgili ayrıntılı yönergeler için SQL Server ile Azure Blob Storage kullanma öğreticisini gözden geçirin.

Blob Storage ile SQL Server örneğinizin kimliğini doğrulamak için kimlik bilgilerini oluşturduktan sonra, yedeklemeleri doğrudan depolama hesabına almak için BACKUP TO URL komutunu kullanabilirsiniz. CHECKSUM önerilir, ancak gerekli değildir.

Aşağıdaki örnek, bir URL'ye tam bir veritabanı yedeklemesi alır:

-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
    WITH INIT, COMPRESSION, CHECKSUM;
GO

Aşağıdaki örnek, bir URL'ye diferansiyel veritabanı yedeklemesi alır.

-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
    WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
GO

URL'ye bir işlem günlüğü yedeği almak için aşağıdaki örneği dikkate alın:

-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
    TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
    WITH COMPRESSION, CHECKSUM;

Azure oturum açın ve bir abonelik seçin

Azure oturum açmak için aşağıdaki PowerShell cmdlet'ini kullanın:

Login-AzAccount

Aşağıdaki PowerShell cmdlet'ini kullanarak yönetilen örneğinizin bulunduğu aboneliği seçin:

Select-AzSubscription -SubscriptionId <subscription ID>

Geçişi başlatma

LRS'yi başlatarak geçişi başlatın. Hizmeti otomatik tamamlama veya sürekli modda başlatabilirsiniz.

Otomatik tamamlama modunu kullandığınızda, belirtilen yedekleme dosyalarının sonuncusu geri yüklendiğinde geçiş otomatik olarak tamamlar. Bu seçenek, yedekleme zincirinin tamamının önceden kullanılabilir olmasını ve Blob Storage hesabınıza yüklenmesini gerektirir. Geçiş devam ederken yeni yedekleme dosyalarının eklenmesine izin vermez. Bu seçenek, komutun start son yedekleme dosyasının dosya adını belirtmesini gerektirir. Veri yakalamanın gerekli olmadığı pasif iş yükleri için bu modu öneririz.

Sürekli modu kullandığınızda, hizmet Azure Blob Storage klasörünü sürekli tarar ve geçiş devam ederken eklenen tüm yeni yedekleme dosyalarını geri yükler. Geçiş ancak el ile tam geçiş talep edildikten sonra tamamlanır. Yedekleme zincirinin tamamına önceden sahip değilseniz ve geçiş devam ettikten sonra yeni yedekleme dosyaları eklemeyi planladığınızda sürekli mod geçişini kullanmanız gerekir. Veri yakalamanın gerekli olduğu etkin iş yükleri için bu modu öneririz.

Tek bir LRS geçiş işini en fazla 30 gün içinde tamamlamayı planlayın. Bu süre dolduğunda LRS işi otomatik olarak iptal edilir.

Not

Birden çok veritabanını taşırken, her veritabanının kendi klasöründe olması gerekir. LRS, Azure Blob Storage kapsayıcısının ve tek tek veritabanı klasörünün tam URI yoluna işaret ederek her veritabanı için ayrı olarak başlatılmalıdır. Veritabanı klasörlerinin içindeki iç içe klasörler desteklenmez.

LRS'i otomatik tamamlama modunda başlatma

Yedekleme zincirinin tamamının Azure Blob Storage hesabınıza yüklendiğinden emin olun. Bu seçenek, geçiş devam ederken yeni yedekleme dosyalarının eklenmesine izin vermez.

LRS'yi otomatik tamamlama modunda başlatmak için PowerShell veya Azure CLI komutlarını kullanın. parametresini kullanarak -LastBackupName son yedekleme dosyası adını belirtin. Belirtilen son yedekleme dosyasının geri yüklenmesi tamamlandıktan sonra hizmet otomatik olarak tam geçiş başlatır.

SAS belirtecini veya yönetilen kimliği kullanarak veritabanınızı depolama hesabından geri yükleyin.

Önemli

• Geçişi otomatik tamamlama modunda başlatmadan önce yedekleme zincirinin tamamının Azure Blob Storage hesabınıza yüklendiğinden emin olun. Bu mod, geçiş devam ederken yeni yedekleme dosyalarının eklenmesine izin vermez.

• Son yedekleme dosyasını doğru belirttiğinizden ve dosyadan sonra daha fazla dosya yüklemediğinizden emin olun. Sistem, belirtilen son yedekleme dosyasının ötesinde daha fazla yedekleme dosyası algılarsa geçiş başarısız olur.

SAS belirteci

Aşağıdaki PowerShell örneği, SAS belirteci kullanarak LRS'yi otomatik tamamlama modunda başlatır:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

Aşağıdaki Azure CLI örnek, SAS belirteci kullanarak LRS'yi otomatik tamamlama modunda başlatır:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Yönetilen kimlik

Aşağıdaki PowerShell örneği, yönetilen kimlik kullanarak LRS'yi otomatik tamamlama modunda başlatır:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" `
    -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity  `
    -AutoCompleteRestore `
    -LastBackupName "last_backup.bak"

LRS'i sürekli modda başlatma

İlk yedekleme zincirinizi Azure Blob Storage hesabınıza yüklediğinizden emin olun.

Önemli

LRS'yi sürekli modda başlattıktan sonra, manuel geçişe kadar depolama hesabınıza yeni günlük ve fark yedekleri ekleyebilirsiniz. El ile geçiş işlemi başlatıldıktan sonra ek fark dosyaları eklenemez veya geri yüklenemez.

SAS belirteci

Aşağıdaki PowerShell örneği, SAS belirteci kullanarak LRS'yi sürekli modda başlatır:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Aşağıdaki Azure CLI örnek, LRS'yi sürekli modda başlatır:

az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
    --storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
    --storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"

Yönetilen kimlik

Aşağıdaki PowerShell örneği, yönetilen kimlik kullanarak LRS'yi sürekli modda başlatır:

Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName" `
    -Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
    -StorageContainerIdentity ManagedIdentity

Geçiş işlemi için kod yazın

LRS'yi sürekli modda başlatan PowerShell ve Azure CLI istemcileri eşzamanlıdır. Bu modda PowerShell ve Azure CLI, api yanıtının işi başlatmadan önce başarılı veya başarısız olduğunu bildirmesini bekler.

Bu bekleme sırasında komut, denetimi komut istemine döndürmez. Eğer geçiş deneyimini betiklendiriyorsanız ve betiğin geri kalanına devam edebilmek için denetimi hemen geri vermek amacıyla LRS başlatma komutuna ihtiyacınız varsa, PowerShell'i -AsJob anahtarıyla arka plan görevi olarak çalıştırabilirsiniz. Örneğin:

$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob

Bir arka plan işi başlattığınızda, işin tamamlanması uzun sürse bile iş nesnesi hemen geri döner. İş çalışırken oturumda kesintisiz olarak çalışmaya devam edebilirsiniz. PowerShell'i arka plan işi olarak çalıştırma hakkında ayrıntılı bilgi için PowerShell Başlangıç İşi belgelerine bakın.

Benzer şekilde, Linux'ta arka plan işlemi olarak bir Azure CLI komutu başlatmak için LRS start komutunun sonundaki ve işaretini (&) kullanın:

az sql midb log-replay start <required parameters> &

Geçiş ilerleme durumunu izleme

Az.SQL 4.0.0 ve üzeri , ayrıntılı bir ilerleme raporu sağlar. Yönetilen Veritabanı Geri Yükleme Ayrıntıları - Get bölümünü gözden geçirin ve bir örnek çıktı görün.

PowerShell aracılığıyla devam eden geçiş ilerlemesini izlemek için aşağıdaki komutu kullanın:

Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

Azure CLI üzerinden devam eden geçiş ilerlemesini izlemek için aşağıdaki komutu kullanın:

az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb

Başarısız bir istekle ilgili ek ayrıntıları izlemek için Get-AzSqlInstanceOperation PowerShell komutunu kullanın veya az sql mi op show Azure CLI komutunu kullanın.

Geçişi durdurma (isteğe bağlı)

Geçişi durdurmanız gerekiyorsa PowerShell veya Azure CLI kullanın. Geçişin durdurulması yönetilen örneğinizdeki geri yükleme veritabanını siler, bu nedenle geçişin devamı mümkün olmaz.

PowerShell aracılığıyla geçiş işlemini durdurmak için aşağıdaki komutu kullanın:

Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
    -InstanceName "ManagedInstance01" `
    -Name "ManagedDatabaseName"

geçiş işlemini Azure CLI durdurmak için aşağıdaki komutu kullanın:

az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb

Geçişi tamamlama (sürekli mod)

LRS'yi sürekli modda başlatırsanız, yeni yedekleme dosyalarının oluşturulmasını önlemek için uygulamanızın ve SQL Server iş yükünün durduruldığından emin olun. SQL Server örneğinizdeki son yedeklemenin Azure Blob Storage hesabınıza yüklendiğinden emin olun. Yönetilen örneğinizdeki geri yükleme ilerleme durumunu izleyin ve son günlük kuyruğu yedeklemesinin geri yüklendiğinden emin olun.

Yönetilen örneğinizde son günlük kuyruğu yedeklemesi geri yüklendiğinde, geçişi tamamlamak için elle kesme işlemini başlatın. Tam geçiş tamamlandıktan sonra veritabanı yönetilen örnekte okuma ve yazma erişimi için kullanılabilir hale gelir.

Geçiş işlemini PowerShell aracılığıyla LRS sürekli modunda tamamlamak için aşağıdaki komutu kullanın:

Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"

Azure CLI aracılığıyla LRS sürekli modunda geçiş işlemini tamamlamak için aşağıdaki komutu kullanın:

az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"

Sınırlamalar

LRS ile geçiş yaparken aşağıdaki sınırlamaları göz önünde bulundurun:

• Geçiş işlemi bitene kadar LRS aracılığıyla geri yüklenen veritabanlarını kullanamazsınız.
• Geçiş işlemi sırasında, migrate edilen veritabanları SQL Managed Instance'ta salt okunur erişim için kullanılamaz.
• Geçiş tamamlandıktan sonra geçiş işlemi sonlanır ve ek değişiklik yedeklemeleriyle sürdürülemez.
• Yalnızca veritabanı .bak, .logve .diff dosyaları LRS tarafından desteklenir. Dacpac ve bacpac dosyaları desteklenmez.
• Sistem güncelleştirmelerini belirli bir gün ve saatte zamanlamak için bir bakım penceresi yapılandırmanız gerekir. Zamanlanmış bakım penceresinin dışında geçişleri yürütmeyi ve tamamlamayı planlayın.
• olmadan CHECKSUM alınan veritabanı yedeklemeleri:
  • bozuk veritabanlarını geçirme potansiyeline sahip olabilir.
  • geri yükleme işlemi, etkin veritabanı yedeklemelerinden CHECKSUM daha uzun sürer.
• LRS'nin kullandığı paylaşılan erişim imzası (SAS) belirteci tüm Azure Blob Storage kapsayıcısı için oluşturulmalıdır ve yalnızca Read ve List izinlerine sahip olmalıdır. Örneğin, Read, List ve Write izinleri verirseniz, ek Write izni nedeniyle LRS başlatılamaz.
• Depolanan erişim ilkesi tanımlayarak ayarlanan izinlerle oluşturulan SAS belirteçlerinin kullanılması desteklenmez. SAS belirtecinin Okuma ve Listeleme izinlerini el ile belirtmek için bu makaledeki yönergeleri izleyin.
• Farklı veritabanları için yedekleme dosyalarını düz dosya yapısındaki Blob Storage hesabındaki ayrı klasörlere yerleştirmeniz gerekir. Klasörleri veritabanı klasörlerinin içine yerleştirme desteklenmez.
• Otomatik tamamlama modunu kullanıyorsanız yedekleme zincirinin tamamının Blob Storage hesabında önceden kullanılabilir olması gerekir. Otomatik tamamlama modunda yeni yedekleme dosyaları eklemek mümkün değildir. Geçiş devam ederken yeni yedekleme dosyaları eklemeniz gerekiyorsa sürekli modu kullanın.
• Tek bir veritabanı klasörü içeren tam URI yoluna işaret eden her veritabanı için LRS'yi ayrı olarak başlatmanız gerekir.
• Yedekleme URI yolu, kapsayıcı adı veya klasör adları, ayrılmış anahtar sözcükler oldukları için backup veya Backup içeremez.
• Birden fazla Log İadesi geri yüklemesini aynı depolama kapsayıcısında paralel olarak başlatırken, her bir geri yükleme işlemi için aynı geçerli SAS belirtecini sağladığınızdan emin olun.
• LRS, toplam veritabanı sayısını hizmet katmanının kaynak sınırlarına kadar tek bir örneğe geçirmeyi destekler. Örneğin, Genel Amaçlı hizmet katmanında toplam 100'e kadar veritabanını ve Yeni Nesil Genel Amaçlı hizmet katmanında toplam 500'e kadar veritabanını geri yükleyebilirsiniz.
• LRS, tek bir örneğe 100 eşzamanlı veritabanı geri yüklemesini ve tek bir abonelikteki tüm örnekler için 150 eşzamanlı veritabanı geri yüklemesini destekler. Örneğin, aynı abonelikteki iki örneğe paralel olarak aynı anda 100 veritabanını veya aynı abonelikteki dört ayrı örneğe paralel olarak üç eş zamanlı toplu işlemde 50 veritabanını geri yükleyebilirsiniz.
• Tek bir LRS işi en fazla 30 gün boyunca çalıştırılabilir ve bundan sonra otomatik olarak iptal edilir.
• Güvenlik duvarının arkasında bir Azure Storage hesabı kullanmak mümkün olsa da ek yapılandırma gerekir ve depolama hesabı ile yönetilen örneğin aynı bölgede veya iki eşleştirilmiş bölgede olması gerekir. Daha fazla bilgi edinmek için Güvenlik duvarını yapılandırma'ya bakın.
• Paralel olarak geri yükleyebileceğiniz en fazla veritabanı sayısı, tek abonelik başına 150'dir. Bazı durumlarda destek bileti açarak bu sınırı artırmak mümkündür.
• Geri yüklemek için binlerce veritabanı dosyasını karşıya yüklemek, aşırı geçiş sürelerine ve hatta başarısızlığa neden olabilir. Geçiş işlemini hızlandırmak ve başarılı olduğundan emin olmak için veritabanlarını daha az dosyada birleştirin.
• Geçiş işleminin başında ve sonunda olmak üzere, yük devretme gerçekleşirse geçişin iptal edildiği ve veritabanı SQL Managed Instance'dan silindiği için geçiş işinin baştan elle yeniden başlatılması gereken iki senaryo vardır.
  • İlk tam veritabanı yedeklemesi SQL Managed Instance üzerinde geri yüklenirken ve geçiş işi ilk kez başlatıldığında yük devretme gerçekleşirse, geçiş işinin baştan el ile yeniden başlatılması gerekir.
  • Geçiş tam olarak başlatıldıktan sonra bir hata geçişi gerçekleşirse, geçiş işinin baştan manuel olarak yeniden başlatılması gerekir. Kesinti süresini en aza indirmek ve kesinti süreci sırasında geçiş riskini azaltmak için son yedekleme dosyasının mümkün olduğunca küçük olduğundan emin olun.
• kaynak SQL Server 2019 ve sonraki örneklerde accelerated database recovery devre dışı bırakılırsa, Azure SQL Managed Instance geçiş yaptıktan sonra artık etkinleştiremezsiniz. Ayrıca, kalıcı sürüm deposu (PVS) olarak PRIMARYayarlı değilse, hedef SQL yönetilen örneğinde geri yükleme işlemleriyle ilgili sorunlarla karşılaşabilirsiniz.
• kaynak SQL Server örneğinde Service Broker devre dışı bırakılırsa, geçiş sonrasında hedef SQL yönetilen örneğinde Hizmet Aracısı'nı kullanamazsınız.

Not

Geçiş sırasında veritabanının salt okunur olarak erişilebilir olmasını istiyorsanız, geçişi gerçekleştirmek için çok daha uzun bir zaman çerçevesi ve en düşük kapalı kalma süresiyle, önerilen geçiş çözümü olarak Managed Instance bağlantısının Genel bakış özelliğini kullanmayı göz önünde bulundurun.

İş Açısından Kritik hizmet katmanına geçişle ilgili sınırlamalar

Business Critical hizmet katmanındaki bir SQL Managed Instance geçiş yaparken aşağıdaki sınırlamaları göz önünde bulundurun:

• Büyük veritabanları aktarılırken, veritabanları İş Açısından Kritik hizmet katmanının ikincil çoğaltmalarına tohumlanarak dağıtılırken geçişten sonra veritabanları kullanılamadığı için önemli bir kapalı kalma süresi yaşanabilir. Geçici çözümler, daha uzun kesinti süreli bölümde listelenmiştir.
• Geçiş planlanmamış bir yük devretme, sistem güncelleştirmesi veya güvenlik yaması tarafından kesintiye uğrarsa geçiş en baştan otomatik olarak yeniden başlatılır ve son dakika sürprizleri olmadan öngörülebilir bir geçiş planlamayı zorlaştırır.

Önemli

Bu sınırlamalar, Genel Amaçlı hizmet katmanına değil, yalnızca İş Açısından Kritik hizmet katmanına geçirilirken geçerlidir.

İş Açısından Kritik hizmet katmanında daha uzun tam geçiş

Business Critical hizmet katmanındaki bir SQL Managed Instance'a geçiş yapıyorsanız, veritabanlarının ikincil çoğaltmalara dağıtılırken birincil çoğaltmada çevrimiçi hale gelmesindeki gecikmeyi hesaba katmalısınız. Bu özellikle daha büyük veritabanları için geçerlidir.

Business Critical hizmet katmanındaki bir SQL Managed Instance geçişinin tamamlanması Genel Amaçlı hizmet katmanından daha uzun sürer. Azure tam geçiş tamamlandıktan sonra, veritabanları birincil çoğaltmadan üç ikincil çoğaltmaya dağıtılana kadar kullanılamaz ve bu da veritabanınızın boyutuna bağlı olarak uzun sürebilir. Veritabanı ne kadar büyük olursa, ikincil çoğaltmalara kopyalama işlemi birkaç saate kadar, potansiyel olarak daha uzun sürebilir.

Tam geçiş tamamlandığında veritabanlarının kullanılabilir olması önemliyse aşağıdaki geçici çözümleri göz önünde bulundurun:

• Önce Genel Amaçlı hizmet katmanına geçin ve ardından İş Açısından Kritik hizmet katmanına yükseltin. Hizmet katmanınızı yükseltmek, veritabanlarınızı çevrimiçi tutan bir işlemdir ve yükseltme işleminin son adımı olarak kısa bir yük devretme gerçekleşir.
• Tam geçişten sonra veritabanlarının kullanılabilir olmasını beklemek zorunda kalmadan Business Critical örneğine çevrimiçi geçiş için Managed Instance bağlantısını kullanın.

SQL Managed Instance'a geçtikten sonra bilinen sorunlar

Azure SQL Managed Instance geçiş yaptıktan sonra aşağıdaki bilinen sorunları göz önünde bulundurun:

SQL Managed Instance'a taşındıktan sonra geri yükleme işleminin başarısızlıkları

Veritabanını SQL Server 2019 ve sonraki sürümlerden hızlandırılmış veritabanı kurtarma etkin haldeyken ancak kalıcı sürüm deposu (PVS) PRIMARY dosya grubundan farklı bir değere ayarlanmış olarak Azure SQL Managed Instance'a taşırsanız, hedef SQL yönetilen örnekte geri yükleme operasyonları başarısız olabilir.

Bu sorunu çözmek için, SQL Managed Instance'a geçirmeden önce kaynak SQL Server veritabanında persistent sürüm deposunu (PVS) BİRİNCİL olarak ayarladığınızdan emin olun. PVS'yi PRIMARY olarak ayarlamadan veritabanını zaten geçirdiyseniz, bunu kaynak SQL Server veritabanında ayarlayabilir ve sonra veritabanını SQL Managed Instance'a yeniden geçirebilirsiniz.

SQL Managed Instance'a geçirildikten sonra hızlandırılmış veritabanı kurtarması kullanılamıyor

SQL Server 2019'dan başlayarak, bir veritabanını Azure SQL Managed Instance'a geçirirseniz ve kaynak veritabanında accelerated database recovery devre dışı bırakılırsa, hedef SQL yönetilen örneğinde hızlandırılmış veritabanı kurtarmayı kullanamazsınız.

Kaynak SQL Server veritabanını SQL Managed Instance'a geçirmeden önce hızlandırılmış veritabanı kurtarmayı etkinleştirdiğinizden emin olun bu sorunu geçici olarak çözmek için. Hızlandırılmış veritabanı kurtarmayı etkinleştirmeden veritabanını zaten taşıdıysanız, kaynak SQL Server veritabanında etkinleştirip, ardından veritabanını SQL yönetilen örneğine yeniden taşıyabilirsiniz.

SQL Server 2017 ve önceki sürümler hızlandırılmış veritabanı kurtarmayı desteklemediğinden, bu sorun SQL Server bu sürümlerinden geçirilen veritabanları için geçerli değildir.

SQL Managed Instance taşındıktan sonra Hizmet Aracısı kullanılamıyor

Veritabanını Azure SQL Managed Instance'a geçirirseniz ve kaynak veritabanında <>Service Aracısı devre dışı bırakılırsa, hedef SQL yönetilen örneğinde Hizmet Aracısı'nı kullanamazsınız.

Bu sorunu çözmek için, SQL Managed Instance'a geçirmeden önce kaynak SQL Server veritabanında Service Broker'ı etkinleştirdiğinizden emin olun. Veritabanını Hizmet Aracısı'nı etkinleştirmeden zaten geçirdiyseniz, kaynak SQL Server veritabanında etkinleştirebilir ve sonra veritabanını SQL Managed Instance'a yeniden geçirebilirsiniz.

LRS sorunlarını giderme

LRS'yi başlattıktan sonra, devam eden işlemin durumunu görmek için aşağıdaki izleme cmdlet'lerinden birini kullanın:

• PowerShell için: get-azsqlinstancedatabaselogreplay
• Azure CLI için: az_sql_midb_log_replay_show

Başarısız bir işlemle ilgili ayrıntıları gözden geçirmek için:

• PowerShell için: Get-AzSqlInstanceOperation
• Azure CLI için: az sql mi op show

LRS bir süre sonra başlatılamazsa ve hata alırsanız en yaygın sorunları denetleyin:

• Yönetilen örneğinizdeki mevcut bir veritabanı, SQL Server örneğinizden geçirmeye çalıştığınız veritabanıyla aynı ada sahip mi? Veritabanlarından birini yeniden adlandırarak bu çakışmayı çözün.
• SAS belirteci için izinler yalnızca okuma ve listeleme mi? Read ve List'den daha fazla izin verilmesi LRS'nin başarısız olmasına neden olur.
• Soru işaretinden ()? sonra LRS için SAS belirtecini, şuna benzeyen sv=2020-02-10...içerikle kopyaladınız mı?
• SAS belirteci geçerlilik süresi, geçişi başlatma ve tamamlama zaman penceresi için uygun mu? SQL Managed Instance dağıtımınız ve SAS belirteciniz için kullanılan farklı saat dilimleri nedeniyle uyuşmazlıklar olabilir. SAS belirtecini yeniden oluşturmayı ve geçerli tarihten önceki ve sonraki zaman penceresinin belirteç geçerliliğini genişletmeyi deneyin.
• Aynı depolama kapsayıcısını hedefleyen birden çok Log Replay geri yüklemesini paralel olarak başlatırken, her geri yükleme işlemi için aynı geçerli SAS belirtecinin sağlandığından emin olun.
• Veritabanı adı, kaynak grubu adı ve yönetilen örnek adı doğru yazıldı mı?
• LRS'yi otomatik tamamlama modunda başlattıysanız, belirtilen son yedekleme dosyası için geçerli bir dosya adı var mıydı?
• Yedekleme URI yolunda backup veya backups anahtar sözcükler var mı? backup veya backups gibi ayrılmış anahtar sözcükleri kullanan kapsayıcı veya klasörlerin adını değiştirin.

İlgili içerik

• Azure SQL Managed Instance ile Günlük Yeniden Yürütme Hizmeti'nin Genel Görünümü
• Managed Instance bağlantısının Genel bakış
• SQL Server'dan Azure SQL Managed Instance'a geçiş yapma
• SQL Server ve Azure SQL Managed Instance arasındaki T-SQL farkları
• Azure'a geçirilen iş yüklerini maliyetlendirme ve boyutlandırma için en iyi uygulamalar
• Managed Instance bağlantısı olan LRS ile karşılaştırın