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 Örneği
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.
Not
Microsoft Entra ID daha önce Azure Active Directory (Azure AD) olarak biliniyordu.
Bilinen sorunlar
Geçici çözümü var
MSDASQL kullanan bağlı sunucu sorguları 7416 hatasıyla başarısız oldu
ODBC için Microsoft OLE DB Sağlayıcısını (MSDASQL) kullanan ve bir sağlayıcı dizesi (@provstr) belirten bağlı sunucu sorguları aşağıdaki hatayla başarısız olabilir:
Msg 7416, Level 16
Access to the remote server is denied because no login-mapping exists.
Bu sorun sysadmin sabit sunucu rolünün üyesi olmayan oturum açma işlemlerini etkiler. Bağlantılı sunucu ve oturum açma eşlemeleri doğru yapılandırıldığında bile oluşabilir.
MSDASQL sağlayıcısını kullanan bazı bağlı sunucu yapılandırmalarında, Database Engine daha katı bir bağlantı doğrulama denetimi önceki derlemelerde izin verilen bağlantıları reddedebilir.
Geçici çözüm: Aşağıdaki seçeneklerden birini kullanın:
Yapılandırmanız gerekli değilse bağlı sunucu tanımından @provstr kaldırın.
User ID=<value>@provstr'ye ekleyin. Oturum açma bilgileri yine sağlayıcı dizesinde sağlanmalıUID.
Etkilenen sysadmin oturum açma bilgilerini vermek de hatayı engeller, ancak önerilmez.
SQL Yönetilen Örneği'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 Yönetilen Örneği'a taşırsanız, hedef SQL yönetilen örnekte geri yükleme operasyonları başarısız olabilir.
Bu sorunu çözmek için, SQL Yönetilen Örneği'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 Yönetilen Örneği'a yeniden geçirebilirsiniz.
SQL Yönetilen Örneği'a geçirildikten 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'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 Yönetilen Örneği'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 Yönetilen Örneği taşındıktan sonra Hizmet Aracısı kullanılamıyor
Veritabanını Azure SQL Yönetilen Örneği'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 Yönetilen Örneği'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 Yönetilen Örneği'a yeniden geçirebilirsiniz.
Ücretsiz teklif için yedekleme saklama süresini değiştirme
Veritabanlarınızın yedekleme bekletme ilkesini yalnızca Ücretsiz SQL Yönetilen Örneği içinde REST API, PowerShell ve Azure CLI komutlarını kullanarak değiştirebilirsiniz. yedekleme bekletme ilkesini Azure portalı aracılığıyla değiştiremezsiniz.
"Uzun bekleme nedeniyle 'HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING' ikincil okuma sunucusuna giriş başarısız oldu."
<c0>Microsoft OLE DB Sürücüsü 19 for SQL Server</c0> sürücüsü için, bir <c1>failover grubu</c1> salt okunur ikincil çoğaltmasına veya <c2>Managed Instance bağlantısı</c2> aracılığıyla çoğaltılan bir veritabanına bağlanmaya çalıştığınızda bu hatayı bir özel durum olarak 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.
SQL Yönetilen Örneği kaynaklı bir SQL Server veritabanında DBCC CHECKDB çalıştırılırken hata 8992
SQL Server 2022 veritabanında DBCC CHECKDB komutunu çalıştırdığınızda, bir dizini veya dizini olan bir tabloyu sildikten sonra aşağıdaki hatayı görebilirsiniz. Veritabanının kaynağı Azure SQL Yönetilen Örneği, örneğin yedekleme dosyası geri yüklendikten sonra veya SQL Yönetilen Örneği bağlantı özelliğinden:
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 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 yeniden oluşturmak mümkün değilse, bu sorunu çözmeye yardımcı olmak 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.
Managed Instance bağlantısı oluşturulurken hata 1412
İlk kez bir bağlantı oluşturduğunuzda, işlemin ilk bölümü veritabanının tam bir yedeğini alır ve birincil replikadan ikincil replikaya aktarır. Tam yedeklemenin oluşturulması tamamlandıktan sonra, birincil çoğaltmadaki fark verilerini ikincil çoğaltmaya uygulayarak bağlantı iki çoğaltma arasında veri çoğaltmaya başlar. Yük devretme komutu verilene veya bağlantı kaldırılana kadar bu işlem süresiz olarak devam eder.
Tam yedeklemenin ilk kez tohumlanması sırasında birincil çoğaltmada bir işlem günlüğü yedeklemesi gerçekleşirse, işlem günlüğü kısaltılır. İlk tohumlama için gerekli işlem günlüğündeki veriler artık kullanılamadığından bağlantı oluşturma işlemi 1412 hatasıyla başarısız oluyor.
Azure SQL Yönetilen Örneği SQL Server hata günlüğünde 1412 hatası görürseniz, önce bağlantıyı silin ve ardından yeniden oluşturmanız gerekir. Bu sorunu önceden önlemek için ilk dağıtım aşamasında işlem günlüğü yedeklemelerini duraklatın. İlk dağıtım aşamasında işlem günlüğü yedeklemeleri gerekiyorsa, günlük kesilmesini önlemek için açık bir işlem başlatın. Daha fazla bilgi için bağlantı özelliğinin sorun giderme kılavuzunda Managed Instance bağlantısı oluştururken Error 1412 makalesini gözden geçirin.
Azure portalındaki uzun süreli yedeklemelerin listesi, aynı ada sahip etkin ve silinmiş veritabanları için yedekleme dosyalarını gösterir
Uzun süreli yedeklemeler, Backups sekmesindeki 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 SQL Yönetilen Örneği oluşturulamıyor
Azure SQL Veritabanı veya SQL Yönetilen Örneği için Azure'da bir mantıksal sunucu oluşturduğunuzda, sistem <name>.database.windows.com için bir 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ı serbest bırakmak için bir destek bileti oluşturun.
Hizmet Sorumlusu Microsoft Entra ID ve AKV'ye erişemiyor
Bazı durumlarda, Microsoft Entra ID (formerly 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ğinde, müşteri tarafından yönetilen anahtarla TDE'nin ayarlanması da bazı durumlarda çalışmayabilir.
Workaround: Bu sorunun SQL Yönetilen Örneği' nizde 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 managed instance Overview sayfasına gidin. Settings altında SQL Yönetilen Örneği Microsoft Entra ID yönetici sayfasına erişmek için Microsoft Entra ID öğesini seç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, boş olmayan bir dosyayı doğrudan silmesine 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.
Resource Governor, okunabilir durumdaki bir ikincil çoğaltmada yük devretmeden sonra yeniden yapılandırma gerektiriyor.
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 FILE ve RESTORE DATABASE deyimleri, örnek Genel Amaçlı hizmet katmanında Azure Depolama sınırına ulaştığından başarısız olabilir, ancak Ext-gen Genel Amaçlı hizmet katmanı yükseltme veya İş Açısından Kritik hizmet katmanına ulaşamayabilir.
SQL Yönetilen Örneği genel amaçlı her örneğinde Azure Premium Disk alanı için ayrılmış en fazla 35 TB depolama alanı vardı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 üzerindeki 35 TB Azure sınırını aşabilir.
Örneğin, SQL Yönetilen Örneği Genel Amaçlı örneğinin boyutu 4 TB olan bir diske yerleştirilmiş 1,2 TB boyutunda bir büyük dosya olabilir. 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.
Bu örnek, belirli durumlarda, belirli bir dosya dağılımı nedeniyle, SQL Yönetilen Örneği örneğinin bağlı Azure Premium Disk için ayrılmış olan 35 TB sınırına beklenmedik şekilde ulaşabileceğini göstermektedir.
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 ve bağlı sunuculardaki CLR modülleri veya geçerli örneğe başvuran dağıtılmış sorgular 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.
Bir örnek SQL Server'a bağlandığında diferansiyel yedeklemeler alınmaz.
SQL Server ile Azure SQL Yönetilen Örneği arasında link yapılandırdığınızda, SQL Yönetilen Örneği'nde birincil rolde bulunsun veya bulunmasın 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 Örneği hizmeti, işlem replikasyonu amacıyla bir sistem oturumu oluşturur. Bu oturum açma bilgilerini SSMS'de (Nesne Gezgini>Güvenlik>Logins) veya sys.syslogins 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ı tam olarak desteklemez.
Microsoft Entra oturum açma türlerinin kimliğine bürünme desteklenmez
EXECUTE AS USER veya EXECUTE AS LOGIN kullanılarak kimliğe bürünme, aşağıdaki Microsoft Entra sorumluları için desteklenmez:
- Diğer adla Microsoft Entra kullanıcılar. Bu durumda, işlem hata
15517döndürür. - Microsoft Entra uygulamaları veya hizmet ilkelerine dayalı Microsoft Entra oturum açma bilgileri 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 Örneği yöneticisinin eski birincildeki tüm yayınları temizlemesi ve başka bir bölgeye yük devretme gerçekleştikten sonra 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 boyut üst 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
system_health olay oturumunun event_file hedefi erişilebilir değil
(Mart 2026'da çö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 'https://' ile başlayan geçerli bir URL gerekiyor" hatasını alırsınız.
Bu sorun SQL Server Management Studio (SSMS) veya sys.fn_xe_file_target_read_file işlevini kullanarak oturum verileri okunurken oluştu. Sorun her iki durumda da çözülür.
Davranıştaki bu değişiklik, gerekli bir güvenlik düzeltmesinin istenmeyen bir sonucuydu. Müşteriler, Azure blob depolamada bir system_health hedefiyle event_file oturumunun kendi eşdeğerini oluşturarak bu sorunu geçici olarak çözebilir. 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.
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'da ilgili
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 @ simgesini içeren kullanıcı adları (örneğin, abc@xy) SQL Server kimlik doğrulaması 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ğe uygulanmayan kaynak grubu izinleri
SQL Yönetilen Örneği Katkıda Bulunan Azure rolünü bir kaynak grubuna (RG) uyguladığınızda, SQL Yönetilen Örneği için geçerli değildir ve hiçbir etkisi yoktur.
Workaround: Abonelik düzeyindeki kullanıcılar için SQL Yönetilen Örneği Katılımcı rolü ayarlayın.
Azure portalında Hizmet Sorumlusu'nun yeniden oluşturmasını öneren yanıltıcı hata iletisi
Azure SQL Yönetilen Örneği için Azure portalının Active Directory admin sayfası, Hizmet Sorumlusu 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 Sorumlusunun mevcut olup olmadığını denetlemek için Azure portalındaki Enterprise applications sayfasına gidin. Application type açılan listesinden Managed Identities öğesini seçin, Apply öğesini 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. Bu adımı instructions izleyerek 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 (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. Azure Blob Depolama'da system_health hedefiyle event_file oturumunun kendi eşdeğerini oluşturarak bu sorunu çözebilirsiniz. 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 sanal çekirdek veya örnek depolama boyutundaki herhangi bir değişiklik, 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 güncelleştirmelerinin ve iyileştirmelerinin listesi için bkz. SQL Yönetilen Örneği hizmet güncelleştirmeleri.
Tüm Azure hizmetlerinde yapılan güncelleştirmeler ve iyileştirmeler için bkz. Hizmet güncelleştirmeleri.