Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Şunlar için geçerlidir:
Azure SQL Yönetilen Veritabanı Sunucusu
Bu makalede, Azure SQL Yönetilen Örneği ile ilgili bilinen sorunlar ve bunların çözüm tarihi veya olası geçici çözümü listelenir. Azure SQL Yönetilen Örneği hakkında daha fazla bilgi edinmek için bkz. Azure SQL Yönetilen Örneği nedir? ve Azure SQL Yönetilen Örneği'ndeki yenilikler?
Not
Microsoft Entra Id daha önce Azure Active Directory (Azure AD) olarak biliniyordu.
Bilinen sorunlar
Geçici çözümü var
SQL Yönetilen Örneği'ne geçiş sonrası geri yükleme işlem hataları
Veritabanını SQL Server 2019'dan Azure SQL Yönetilen Örneği'ne ve hızlandırılmış veritabanı kurtarma etkinleştirilmiş sonraki sürümlere geçirirseniz, ancak kalıcı sürüm deposu (PVS) dosya grubu dışında PRIMARY bir değere ayarlanmış olarak yapılandırılırsa, hedef SQL yönetilen örneğinde geri yükleme işlemi hatalarıyla karşılaşabilirsiniz.
Bu sorunu geçici olarak çözmek için, SQL Yönetilen Örneği'ne geçirmeden önce kaynak SQL Server veritabanında kalıcı sürüm depoyu (PVS) PRIMARY olarak ayarladığınızdan emin olun. Veritabanını PVS'yi PRIMARY olarak ayarlamadan zaten geçiş yaptıysanız, bunu kaynak SQL Server veritabanında ayarlayabilir ve ardından veritabanını SQL Yönetilen Örneği'ne yeniden geçiş yapabilirsiniz.
SQL Yönetilen Örneği'ne geçiş yaptıktan sonra hızlandırılmış veritabanı kurtarması kullanılamıyor
SQL Server 2019'dan başlayarak bir veritabanını Azure SQL Yönetilen Örneği'ne geçirirseniz ve kaynak veritabanı hızlandırılmış veritabanı kurtarmayı devre dışı bırakmışsa, hedef SQL yönetilen örneğinde hızlandırılmış veritabanı kurtarmayı kullanamazsınız.
Bu sorunu çözmek için, kaynak SQL Server veritabanında hızlandırılmış veritabanı kurtarmayı etkinleştirmeniz gerektiğinden emin olun ve ardından SQL Yönetilen Örneği'ne geçirin. Hızlandırılmış veritabanı kurtarmayı etkinleştirmeden veritabanını zaten geçirdiyseniz, kaynak SQL Server veritabanında etkinleştirebilir ve sonra veritabanını SQL yönetilen örneğine yeniden geçirebilirsiniz.
SQL Server 2017 ve önceki sürümleri hızlandırılmış veritabanı kurtarmayı desteklemediğinden, bu sorun SQL Server'ın bu sürümlerinden geçirilen veritabanları için geçerli değildir.
SQL Yönetilen Örneği'ne geçirildikten sonra Hizmet Aracısı kullanılamıyor
Bir veritabanını Azure SQL Yönetilen Örneği'ne geçirirseniz ve kaynak veritabanında Hizmet Aracısı devre dışı bırakılırsa, hedef SQL yönetilen örneğinde Hizmet Aracısı'nı kullanamazsınız.
Bu sorunu aşmak için, kaynak SQL Server veritabanında Service Broker'ı SQL Yönetilen Örneğe geçirmeden önce etkinleştirdiğinizden emin olun. Zaten Service Broker'ı etkinleştirmeden veritabanını geçirdiyseniz, bunu kaynak SQL Server veritabanında etkinleştirebilir ve ardından veritabanını SQL Yönetilen Örneğe tekrar geçirebilirsiniz.
Ücretsiz teklif için yedekleme saklama süresini değiştirme
Veritabanlarınızın yedekleme saklama ilkesini yalnızca REST API, PowerShell ve Azure CLI komutlarını kullanarak ücretsiz SQL yönetilen örneğinde değiştirebilirsiniz. Azure portalı aracılığıyla yedekleme bekletme ilkesini değiştiremezsiniz.
"Uzun bekleme nedeniyle 'HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING' ikincil okuma sunucusuna giriş başarısız oldu."
Bu hatayı, Microsoft OLE DB Sürücüsü 19 for SQL Server sürücüsü için bir özel durum olarak, yük devretme grubunun salt okunur ikincil çoğaltmasına veya Yönetilen Örnek bağlantısı aracılığıyla çoğaltılan bir veritabanına bağlanmaya çalıştığınızda görebilirsiniz.
İkincil çoğaltma yeniden başlatıldığında veya geri dönüştürüldiğinde, bakım veya yük devretme nedeniyle gerçekleşen işlemlerde satır sürümleri eksik olduğundan, ikincil çoğaltma oturum açma işlemleri için kullanılamadığında bu hata oluşur. Bir örnek yeniden başlatıldığında veya yük devredildiğinde, tempdb içinde depolanan sürümleme verileri temizlenir. Yük devretme veya yeniden başlatmadan önce başlatılan uzun süre çalışan etkin işlemler varsa ikincil okuma sorguları durduruluyor.
Birincil replikada etkin işlemleri ya geri döndürün ya da onaylayın. Bu hatayı önlemek için, birincil çoğaltmadaki uzun süreli yazma işlemlerini en aza indirin.
Hata 8992, SQL Yönetilen Örneği'nden gelen bir SQL Server veritabanında DBCC CHECKDB çalıştırılırken oluşuyor.
Bir dizini veya dizini olan bir tabloyu sildikten sonra, ve veritabanı Azure SQL Managed Instance'dan gelen bir yedekleme dosyasının geri yüklenmesiyle ya da DBCC CHECKDB aracılığıyla oluşturulmuşsa SQL Server 2022 veritabanında komutunu çalıştırdığınızda aşağıdaki hatayı görebilirsiniz:
Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.
Sorunu geçici olarak çözmek için önce dizini veya dizini içeren tabloyu Azure SQL Yönetilen Örneği'ndeki kaynak veritabanından bırakın ve sonra veritabanını yeniden SQL Server 2022'ye geri yükleyin veya bağlayın. Veritabanını kaynak Azure SQL Yönetilen Örneği'nden yeniden oluşturmak mümkün değilse, bu sorunu çözmek için Microsoft desteğine başvurun.
Dikkat
Bu senaryoda açıklandığı gibi bir dizini bıraktıktan sonra tabloda bölümlenmiş dizin oluşturursanız, tabloya erişilemez hale gelir.
Azure portalında uzun süreli yedeklemelerin listesi, aynı ada sahip etkin ve silinmiş veritabanları için yedekleme dosyalarını gösterir
Uzun süreli yedeklemeler, Yedeklemeler sekmesinde bir Azure SQL Yönetilen Örneği için Azure portal sayfasında listelenebilir ve yönetilebilir. Sayfada etkin veya silinmiş veritabanları, uzun süreli yedeklemeleri hakkında temel bilgiler ve yedeklemeleri yönetme bağlantısı listelenir. Yönet bağlantısını seçtiğinizde, yedekleme listesini içeren yeni bir yan bölme açılır. Filtreleme mantığıyla ilgili bir sorun nedeniyle, listede hem etkin veritabanı hem de silinen veritabanları için aynı ada sahip yedeklemeler gösterilir. Yanlış bir veritabanı için yedeklemelerin silinmesini önlemek amacıyla, silinecek yedeklemeleri seçerken özen gösterilmesi gerekir.
Geçici çözüm: Örnekte farklı dönemlerde var olan aynı ada sahip veritabanlarına ait yedeklemeleri ayırt etmek için listede görüntülenen Yedekleme zamanı (UTC) bilgilerini kullanın. Alternatif olarak, DatabaseState parametresini ve DatabaseDeletionTime dönüş değerini kullanarak uzun vadeli yedeklemeleri yönetmek için Get-AzSqlInstanceDatabaseLongTermRetentionBackup ve Remove-AzSqlInstanceDatabaseLongTermRetentionBackup powerShell komutlarını veya az sql midb ltr-backup list ve az sql midb ltr-backup delete CLI komutlarını kullanın.
@query parametresi kullanıldığında yordam sp_send_dbmail başarısız olabilir
sp_send_dbmail saklı yordamı, @query parametresi kullanıldığında başarısız olabilir. Saklı yordam bir sysadmin hesabı altında yürütülürken hatalar oluşur.
Bu sorun, kimliğe bürünme kullanma sp_send_dbmail şekliyle ilgili bilinen bir hatadan kaynaklanır.
Geçici çözüm: sp_send_dbmail hesabı altında değil, oluşturduğunuz uygun bir özel hesapta arama yaptığınızdan emin olun.
İşte sp_send_dbmail aracılığıyla e-posta gönderen mevcut nesneleri değiştirme ve özel bir hesap oluşturma örneği.
USE [msdb];
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_user_name = N'user_name';
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_name = N'msdb';
GO
-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = N'user_name',
@profile_name = N'profile_name',
@is_default = 0;
GO
Sunucu Güven Grubu'ndan SQL yönetilen örneği kaldırıldıktan sonra dağıtılmış işlemler yürütülebilir
Sunucu Güven Grupları, dağıtılmış işlemleri yürütmek için önkoşul olan yönetilen örnekler arasında güven oluşturmak için kullanılır. SQL yönetilen örneğini Sunucu Güven Grubu'ndan kaldırdıktan veya grubu sildikten sonra da dağıtılmış işlemleri yürütebilirsiniz. Dağıtılmış işlemlerin devre dışı bırakıldığından emin olmak için SQL yönetilen örneği üzerinde manuel olarak kullanıcı tarafından başlatılan yük devretme gerçekleştirin.
Daha önce silinmiş mantıksal sunucuyla aynı ada sahip bir SQL Yönetilen Örneği oluşturulamaz.
Azure SQL Veritabanı veya SQL Yönetilen Örneği için Azure'da bir mantıksal sunucu oluşturduğunuzda, sistem için <name>.database.windows.combir DNS kaydı oluşturur. Bu DNS kaydı benzersiz olmalıdır. SQL Veritabanı için bir mantıksal sunucu oluşturursanız ve ardından silerseniz, ad yedi gün boyunca ayrılmış olarak kalır. Bu süre boyunca, silinen mantıksal sunucuyla aynı ada sahip bir SQL Yönetilen Örneği oluşturamazsınız. Geçici çözüm olarak, SQL Yönetilen Örneği için farklı bir ad kullanın veya mantıksal sunucu adının serbest bırakılması için bir destek bileti oluşturun.
Hizmet Sorumlusu Microsoft Entra Id ve AKV'ye erişemiyor
Bazı durumlarda, Microsoft Entra Id (eski adıyla Azure Active Directory) ve Azure Key Vault (AKV) hizmetlerine erişmek için kullanılan Hizmet Sorumlusu ile ilgili bir sorun vardır. Sonuç olarak, bu sorun SQL Yönetilen Örneği ile Microsoft Entra kimlik doğrulaması ve saydam veri şifrelemesi (TDE) kullanımını etkiler. Bu sorunla aralıklı bağlantı sorunu olarak karşılaşabilir veya CREATE LOGIN/USER FROM EXTERNAL PROVIDER veya EXECUTE AS LOGIN/USER gibi deyimleri çalıştıramayabilirsiniz. Yeni bir Azure SQL Yönetilen Örneği üzerinde müşteri yönetimli anahtarla TDE'nin ayarlanması bazı durumlarda da çalışmayabilir.
Geçici çözüm: Bu sorunun SQL Yönetilen Örneğinizde oluşmasını önlemek için, güncelleştirme komutlarını yürütmeden önce veya güncelleştirme komutlarından sonra bu sorunla zaten karşılaşmış olmanız durumunda Azure portalında SQL yönetilen örneğinizin Genel Bakış sayfasına gidin. Ayarlar'ın altında Microsoft Entra ID'yi seçerek SQL Yönetilen Örneği Microsoft Entra ID yönetici sayfasına erişin. Aşağıdaki hata iletisini arayın:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Bu hata iletisiyle karşılaşırsanız, bunu seçin ve bu hata çözülene kadar sağlanan adım adım yönergeleri izleyin.
Boş olmayan bir dosyayı kaldırmaya çalışırken yanlış hata döndürüldü
SQL Server ve SQL Yönetilen Örneği, kullanıcının boş olmayan bir dosyayı bırakmasına izin vermez. Eğer bir ALTER DATABASE REMOVE FILE ifadesi kullanarak boş olmayan bir veri dosyasını kaldırmaya çalışırsanız, şu hata ile karşılaşabilirsiniz:
Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.
Hizmet katmanını değiştirme ve örnek oluşturma işlemleri devam eden veritabanı geri yükleme işlemi tarafından engellenir
Devam eden RESTORE bir deyim, Veri Geçiş Hizmeti geçiş işlemi ve yerleşik belirli bir noktaya geri yükleme, geri yükleme işlemi bitene kadar hizmet katmanı güncelleştirmelerini engelleyebilir veya mevcut örneği yeniden boyutlandırabilir ve yeni örnekler oluşturabilir.
Geri yükleme işlemi, geri yükleme işleminin çalıştığı aynı alt ağda bulunan yönetilen örneklerde ve örnek havuzlarında bu işlemleri engeller. Örnek havuzlarındaki örnekler etkilenmeyecek. Hizmet katmanı oluşturma veya değiştirme işlemleri başarısız olmaz veya zaman aşımına uğramaz; geri yükleme işlemi tamamlandıktan veya iptal edildikten sonra devam ederler.
Geçici çözüm: Geri yükleme işlemi bitene kadar bekleyin veya oluşturma veya güncelleştirme-hizmet katmanı işlemi daha yüksek önceliğe sahipse geri yükleme işlemini iptal edin.
Okunabilir bir ikincil çoğaltmada Resource Governor'ın yük devretmesi ardından yeniden yapılandırılması gerekiyor.
Kullanıcı iş yüküne atanan kaynakları sınırlamanıza olanak tanıyan Resource governor özelliği, yük devretme sonrasında bazı kullanıcı iş yüklerini yanlış bir şekilde sınıflandırabilir veya hizmet katmanında kullanıcı tarafından başlatılan bir değişiklik (örneğin, maksimum sanal çekirdek veya maksimum örnek depolama boyutu değişikliği) olabilir.
Geçici çözüm: ALTER RESOURCE GOVERNOR RECONFIGURE kullanıyorsanız okunabilir ikincil çoğaltma başlatıldığında sql görevini yürüten bir SQL Aracısı işinin parçası olarak veya düzenli aralıklarla çalıştırın.
Küçük veritabanı dosyalarıyla depolama alanını aşma
CREATE DATABASE, ALTER DATABASE ADD FILEve RESTORE DATABASE deyimleri başarısız olabilir çünkü örnek Genel Amaçlı hizmet katmanında Azure Depolama sınırına ulaşır, ancak Yeni Nesil Genel Amaçlı hizmet katmanı yükseltmesi veya İş Açısından Kritik hizmet katmanına ulaşmaz.
SQL Yönetilen Örneği'nin her Genel Amaç örneğinde, Azure Premium Disk alanı için ayrılmış en fazla 35 TB depolama alanı bulunmaktadır. Her veritabanı dosyası ayrı bir fiziksel diske yerleştirilir. Disk boyutları 128 GB, 256 GB, 512 GB, 1 TB veya 4 TB olabilir. Diskte kullanılmayan alan için ücret alınmaz, ancak Azure Premium Disk boyutlarının toplam toplamı 35 TB'ı aşamaz. Bazı durumlarda, toplamda 8 TB gerekmeyen bir SQL yönetilen örneği, iç parçalanma nedeniyle depolama boyutu üzerinde 35 TB Azure sınırını aşabilir.
Örneğin, Genel Amaçlı bir SQL Yönetilen Örneği, boyutu 1,2 TB olan büyük bir dosyayı 4 TB'lık bir diske yerleştirebilir. Ayrıca her birinde 1 GB olan ve ayrı 128 GB disklere yerleştirilmiş 248 dosya olabilir. Bu örnekte:
- Ayrılan toplam disk depolama boyutu 1 x 4 TB + 248 x 128 GB = 35 TB'dir.
- Örnekteki veritabanları için toplam ayrılmış alan 1 x 1,2 TB + 248 x 1 GB = 1,4 TB'dir.
Bazı durumlarda, spesifik bir dosya dağıtımı nedeniyle, SQL Yönetilen Örneği, Azure Premium Diske bağlı olarak ayrılmış 35 TB sınırına ulaşabilir, bu da beklemeyebileceğiniz bir durumdur.
Bu örnekte, mevcut veritabanları çalışmaya devam eder ve yeni dosyalar eklenmediği sürece sorunsuz bir şekilde büyüyebilir. Tüm veritabanlarının toplam boyutu örnek boyutu sınırına ulaşmasa bile yeni disk sürücüleri için yeterli alan olmadığından yeni veritabanları oluşturamaz veya geri yükleyemezsiniz. Döndürülen hata net değil.
Sistem görünümlerini kullanarak kalan dosyaların sayısını belirleyebilirsiniz. Bu sınıra ulaşırsanız DBCC SHRINKFILE deyimini kullanarak küçük dosyalardan bazılarını boşaltmayı ve silmeyi deneyin veya bu sınıra sahip olmayan İş Açısından Kritik katmana geçin.
Veritabanı adları yerine gösterilen GUID değerleri
Çeşitli sistem görünümleri, performans sayaçları, hata iletileri, XEvents ve hata günlüğü girdileri gerçek veritabanı adları yerine GUID veritabanı tanımlayıcılarını görüntüler. Gelecekte gerçek veritabanı adlarıyla değiştirilebileceği için bu GUID tanımlayıcılarına güvenmeyin.
Geçici çözüm: Gerçek veritabanı adını, GUID veritabanı tanımlayıcıları biçiminde belirtilen fiziksel veritabanı adından çözümlemek için sys.databases görünümünü kullanın.
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
CLR modülleri ve bağlı sunucular bazen yerel IP adresine başvuramaz
SQL Yönetilen Örneği'nde ve bağlantılı sunucularda veya geçerli örneğe başvuran dağıtılmış sorgularda bulunan CLR modülleri bazen yerel örneğin IP'sini çözümleyemez. Bu hata geçici bir sorundur.
Çözüm yok.
Geçersiz kimlik bilgileri kullanılarak okuma replikasına bağlanırken yanıltıcı hata mesajı.
Geçersiz kimlik bilgilerini kullanarak ApplicationIntent=ReadOnly Business Critical katmanındaki bir örneğin okuma-ikincil replikasına bağlanmayı denediğinizde, master veritabanının salt okunur olduğunu belirten bir hata raporu alırsınız. Örnek, kimlik bilgilerinin geçersiz olduğunu doğru şekilde bildirmiyor.
SQL Server'a bağlı bir örnek olduğunda farklı yedekleme alınmaz.
SQL Server ile Azure SQL Yönetilen Örneği arasında bir bağlantı yapılandırdığınızda, birincil rolde olsun veya olmasın, SQL yönetilen örneğinde otomatik tam ve işlem günlüğü yedeklemeleri alınır. Ancak, şu anda artımlı yedeklemeler alınmadığından, geri yükleme süreleri beklenenden daha uzun olabilir.
İşlemsel çoğaltmada kullanılan sistem oturum açma bilgilerinin sayısı artırıldı
Azure SQL Yönetilen Örnek hizmeti, işlem replikasyonu amacıyla bir sistem girişi oluşturur. Bu oturum açma bilgilerini SSMS'de (Nesne Gezgini>Güvenlik>Oturum Açma Bilgileri'ndesys.syslogins) veya sistem görünümünde bulabilirsiniz. Oturum açma adı biçimi DBxCy\WF-abcde01234QWERT şeklindedir ve oturum açma, public sunucu rolüne sahiptir. Belirli koşullar altında bu oturum açma bilgileri yeniden oluşturulur ve bir iç sorun nedeniyle önceki oturum açma bilgileri silinmez. Bu hata, oturum açma sayısının artmasına neden olabilir. Bu oturum açma bilgileri bir güvenlik tehdidini temsil etmediğinden bunları güvenle yoksayabilirsiniz. Bu oturum açma bilgilerini silmeyin, çünkü işlem çoğaltması için en az biri kullanılıyor.
Microsoft Entra oturumları ve kullanıcıları SSDT'de desteklenmez
SQL Server Veri Araçları Microsoft Entra oturum açma bilgilerini ve kullanıcılarını tam olarak desteklemez.
Microsoft Entra oturum türlerinin kimliğe bürünmesi desteklenmiyor
EXECUTE AS USER veya EXECUTE AS LOGIN kullanarak kimliğe bürünme, aşağıdaki Microsoft Entra ilkeleri için desteklenmez:
- Diğer adla Microsoft Entra kullanıcıları. Bu durumda, işlem hata
15517döndürür. - Microsoft Entra uygulamalarını veya hizmet asıllarını temel alan Microsoft Entra oturumları ve kullanıcılar. Bu durumda, işlem
15517ve15406hatalarını döndürür.
Coğrafi yük devretme işleminden sonra işlem çoğaltması yeniden yapılandırılmalıdır.
Yük devretme grubundaki bir veritabanında işlem çoğaltmasını etkinleştirirseniz, SQL Yönetilen Örnek yöneticisinin eski birincildeki tüm yayınları temizlemesi ve başka bir bölgeye yük devretme gerçekleştiğinde bunları yeni birincilde yeniden yapılandırması gerekir. Daha fazla bilgi için bkz. Çoğaltma.
Hata günlükleri kalıcı değil
SQL Yönetilen Örneği'de kullanılabilen hata günlükleri kalıcı değildir ve boyutları maksimum depolama sınırına dahil değildir. Yük devretme yaşanırsa hata günlükleri otomatik olarak silinebilir. SQL Yönetilen Örneği birkaç sanal makinede birkaç kez taşındığından hata günlüğü geçmişinde boşluklar olabilir.
Çözümlendi
Paraguay için 2024 saat dilimi güncelleştirmeleri için ara kılavuz
(Şubat 2026'da çözüldü)
14 Ekim 2024'te Paraguay hükümeti saat dilimi politikasında kalıcı bir değişiklik olduğunu duyurdu. Paraguay, utc-3'ü standart saati olarak etkin bir şekilde benimseyerek yıl boyunca Yaz Saati (DST) üzerinde olmaya devam ediyor. Sonuç olarak, saatler daha önce zamanlandığı gibi 23 Mart 2025'te saat 12:00'de 60 dakika ilerlemedi. Bu değişiklik Paraguay Standart saat dilimini etkiler. Microsoft, Şubat ve Mart 2025'te ilgili Windows güncelleştirmelerini yayımladı. Etkilenen saat dilimini kullanan SQL yönetilen örnekler bu değişikliği yansıtır ve yeni UTC-3 ofsetine hizalanır.
Bağlantı türünün değiştirilmesi yük devretme grubu uç noktası üzerinden bağlantıları etkilemez
(Kasım 2025'te çözüldü)
Bir örnek bir yük devretme grubuna katılırsa, örneğin bağlantı türünün değiştirilmesi, yük devretme grubu dinleyici uç noktası üzerinden kurulan bağlantılar için etkili olmaz.
Ölçeklendirme işlemi sırasında yük devretme grubu dinleyicisi kullanılarak geçici örnek erişilemezliği
(Nisan 2025'te çözüldü)
SQL yönetilen örneğini ölçeklendirmek bazen, örneğin farklı bir sanal kümeye taşınmasını ve hizmet tarafından korunan ilişkili DNS kayıtlarının da taşınmasını gerektirir. SQL yönetilen örneği bir yük devretme grubuna katılırsa, ilişkili yük devretme grubu dinleyicisine karşılık gelen DNS kaydı (örnek geçerli coğrafi birincil salt okunur dinleyiciyse, örnek geçerli coğrafi ikincil ise okuma-yazma dinleyicisi) yeni sanal kümeye taşınır.
Geçerli ölçeklendirme işlemi tasarımında dinleyici DNS kayıtları, SQL yönetilen örneğini yeni sanal kümeye tamamen geçirmeden önce kaynak sanal kümeden kaldırılır. Bazı durumlarda, bu tasarım, örneğin IP adresinin dinleyici kullanılarak çözülememesi durumunun uzun süre devam etmesine neden olur. Bu süre boyunca, dinleyici uç noktasını kullanarak ölçeklendirilen örneğe erişmeye çalışan bir SQL istemcisinin aşağıdaki hata iletisiyle oturum açma hataları yaşaması beklenebilir:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Ölçeklendirme işleminin yeniden tasarlanmasıyla bu sorun giderilecektir.
msdb'deki el ile yedekleme tablosu kullanıcı adını korumuyor
(Ağustos 2023'te çözüldü) içinde otomatik yedeklemeler msdb için yakın zamanda sunulan destek şu anda kullanıcı adı bilgilerini içermiyor.
SQL Server kimlik doğrulaması kullandığınızda , '@' ile kullanıcı adları desteklenmez
Ortada simgeyi @ içeren kullanıcı adları (örneğin, abc@xy) SQL Server kimlik doğrulamasını kullanarak oturum açamaz.
CHECKSUM olmadan el ile yedekleme geri yükleme işlemi başarısız olabilir
(Haziran 2020'de çözüldü) Belirli durumlarda, CHECKSUM olmadan SQL yönetilen örneğinde yaptığınız veritabanlarının el ile alınan yedeğini geri yüklemek başarısız olabilir. Bu gibi durumlarda, başarılı olana kadar yedeklemeyi geri yüklemeyi yeniden deneyin.
Geçici çözüm: CHECKSUM etkinleştirilmiş SQL yönetilen örneklerindeki veritabanlarının el ile yedeklerini alın.
SQL Yönetilen Örneğine uygulanmayan kaynak grubu izinleri
SQL Yönetilen Örneği Katkıda Bulunan Azure rolünü bir kaynak grubuna (RG) uyguladığınızda, bu, SQL Yönetilen Örneği üzerinde geçerli olmaz ve herhangi bir etkisi yoktur.
Geçici çözüm: Abonelik düzeyindeki kullanıcılar için SQL Yönetilen Örneği Katkıda Bulunanlar rolünü ayarlayın.
Azure portalında Service Principal'ın yeniden oluşturulmasını öneren yanıltıcı hata mesajı
Azure SQL Yönetilen Örneği için Azure portalının Active Directory yönetici sayfası, Service Principal zaten mevcut olsa bile aşağıdaki hata iletisini gösterebilir:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
SQL yönetilen örneğinin Hizmet Sorumlusu zaten varsa ve/veya SQL yönetilen örneğinde Microsoft Entra kimlik doğrulaması çalışıyorsa bu hata iletisini ihmal edebilirsiniz.
Hizmet Sorumlusu'nun mevcut olup olmadığını denetlemek için Azure portalındaki Kurumsal uygulamalar sayfasına gidin, Uygulama türü açılan listesinden Yönetilen Kimlikler'i seçin, Uygula'yı seçin ve arama kutusuna SQL yönetilen örneğinin adını yazın. Örnek adı sonuç listesinde görünüyorsa, Hizmet Sorumlusu zaten var ve başka bir eylem gerekmez.
Hata iletisindeki yönergeleri izlediyseniz ve bağlantıyı seçtiyseniz, SQL yönetilen örneğinin Hizmet Sorumlusu yeniden oluşturulur. Bu durumda, Microsoft Entra kimlik doğrulamasının düzgün çalışması için yeni oluşturulan Hizmet Sorumlusuna Microsoft Entra Id okuma izinleri atayın. Yönergeleri izleyerek bu adımı Azure PowerShell ile de çalıştırabilirsiniz.
system_health olay oturumunun event_file hedefi erişilebilir değil
(Mayıs 2025'te kısmen çözüldü) Olay oturumunun hedefinin event_filesystem_health içeriğini okumayı denediğinizde, 40538 "belirtilen herhangi bir dosya yolu için değer olarak ile başlayan geçerli bir URL gereklidir" hatasını https:// alırsınız.
Başlangıçta bu sorun SQL Server Management Studio'da (SSMS) veya sys.fn_xe_file_target_read_file işlevini kullanarak oturum verileri okunurken ortaya çıkar.
Mayıs 2025'te bu sorun SSMS'den oturum verilerini okumak için çözüldü. İşlevi kullanarak sys.fn_xe_file_target_read_file olay verileri okunurken sorun çözülmez.
Davranıştaki bu değişiklik, gerekli bir güvenlik düzeltmesinin istenmeyen bir sonucudur. Bu sorunu çözmek için, Azure Blob Depolama’da bir system_health hedefi ile event_file oturuma kendi eşdeğerinizi oluşturabilirsiniz. Kendi eşdeğeriniz olan system_health oturumunu oluşturacak şekilde değiştirilebilen bir T-SQL betiği de dahil olmak üzere daha fazla bilgi için system_health kısmına bakın.
Hizmet katmanı yükseltmesi sonrasında veritabanları arası Hizmet Aracısı iletişim kutularının yeniden başlatılması gerekiyor
(Ocak 2020'de çözüldü) Veritabanları arası Hizmet Aracısı iletişim kutuları, hizmet katmanını değiştirme işleminden sonra iletileri diğer veritabanlarındaki hizmetlere teslim etmeyi durdurur. İletiler kaybolmaz ve gönderen kuyruğunda bulunabilir. SQL Yönetilen Örneği'nde vCores veya örnek depolama boyutu değişiklikleri service_broke_guid görünümünde değerinin tüm veritabanları için değişmesine neden olur. Diğer veritabanlarındaki Hizmet Aracılarına referans veren DIALOG deyimi kullanılarak oluşturulan herhangi bir hedef hizmete mesaj iletmeyi durdurur.
Geçici çözüm: Bir hizmet katmanını güncelleştirmeden önce veritabanları arası Hizmet Aracısı iletişim kutusu konuşmalarını kullanan tüm etkinlikleri durdurun ve daha sonra yeniden başlatın. Teslim edilmemiş iletiler bir hizmet katmanı değişikliğinden sonra kalırsa, kaynak kuyruktan iletileri okuyun ve hedef kuyruğa yeniden gönderin.
İçeriğe katkıda bulunma
Azure SQL belgelerine katkıda bulunmak için Docs katkıda bulunan kılavuzuna bakın.
İlgili içerik
SQL Yönetilen Örneği hizmet güncellemelerinin ve iyileştirmelerinin listesi için SQL Yönetilen Örneği hizmet güncellemeleri sayfasına bakın.
Tüm Azure hizmetlerinde güncelleştirmeler ve iyileştirmeler için bkz . Hizmet güncelleştirmeleri.