Kullanıcı Silerken Karşılaşılan Hatalar (Microsoft SQL Server Error: 15141,15174)

                Veritabanlarımızda güvenlik iyileştirmeleri yaptığımız çalışmalar da; kurumdan ayrılan personellerin veya kurumda olsa da artık ihtiyaç olmayan sql kullanıcılarını silme işlemini planladık. Hem servis hem yazılım taraflarında aktif şekilde kullanılan kullanıcıların listesini istedik ve geri kalan tüm kullancıları silme kararı aldık. Emin olamadığımız kullanıcıları da önce pasife çekerek sonrasında silmeyi planladık. Ancak silmeye çalıştığımızın bazı kullanıcıların; bazı databaselerin veya Server Role’lerinin owner’ları olduğu anladık ve hatalar aldık. Şimdi bu hataların çözümüne geçelim:   The server principal owns one or more server role(s) cannot be dropped. (Microsoft SQL Server, Error: 15141) Yukarıdaki hatayı aldığımızda; aşağıdaki sorguya silmek istediğimiz kullanıcı adını yazıyoruz. SELECT sp1.name AS ServerRoleName, sp2.name AS RoleOwnerName FROM sys.server_principals AS sp1 JOIN sys.server_principals As sp2 ON sp1.owning_principal_id=sp2.principal_id WHERE sp2.name='KullaniciAdi'   Sorgu sonucu ‘KullaniciAdi’ isimli user’ın sahip olduğu Server Role’leri geliyor. Bu hata da kullanıcının “SCOMHealthCheck” rolüne sahip olduğunu görüyoruz. Aşağıdaki script ile bu server role’un owner’ını aşağıdaki script ile “sa” […]

Kullanıcı Silerken Karşılaşılan Hatalar (Microsoft SQL Server Error: 15141,15174)

                Veritabanlarımızda güvenlik iyileştirmeleri yaptığımız çalışmalar da; kurumdan ayrılan personellerin veya kurumda olsa da artık ihtiyaç olmayan sql kullanıcılarını silme işlemini planladık. Hem servis hem yazılım taraflarında aktif şekilde kullanılan kullanıcıların listesini istedik ve geri kalan tüm kullancıları silme kararı aldık. Emin olamadığımız kullanıcıları da önce pasife çekerek sonrasında silmeyi planladık.

Ancak silmeye çalıştığımızın bazı kullanıcıların; bazı databaselerin veya Server Role’lerinin owner’ları olduğu anladık ve hatalar aldık. Şimdi bu hataların çözümüne geçelim:

 

The server principal owns one or more server role(s) cannot be dropped. (Microsoft SQL Server, Error: 15141)

Yukarıdaki hatayı aldığımızda; aşağıdaki sorguya silmek istediğimiz kullanıcı adını yazıyoruz.

       SELECT sp1.name AS ServerRoleName, 
       sp2.name AS RoleOwnerName
       FROM sys.server_principals AS sp1
       JOIN sys.server_principals As sp2
       ON sp1.owning_principal_id=sp2.principal_id
       WHERE sp2.name='KullaniciAdi'

 

Sorgu sonucu ‘KullaniciAdi’ isimli user’ın sahip olduğu Server Role’leri geliyor. Bu hata da kullanıcının “SCOMHealthCheck” rolüne sahip olduğunu görüyoruz.

Aşağıdaki script ile bu server role’un owner’ını aşağıdaki script ile “sa” kullanıcısı olacak şekilde değiştiriyoruz.

USE [master]
GO
ALTER AUTHORIZATION ON SERVER ROLE :: [SCOMHealthCheck] TO [sa]
GO

 

Login ‘user_name’ owns one or more database(s). Change the owner of the database(s) before dropping the login.(Microsoft SQL Server, Error: 15174)

Bu hata silmeye çalıştığımız user’ın bir database’in owner’ı olduğunu söylüyor.

Aşağıdaki script ile databaselerin owner kullanıcılarının kim olduğunun kontrol ediyoruz.

SELECT name, suser_sname(owner_sid) AS Database_Owner FROM sys.databases

 

Hatamızdaki örnekte; kullanıcımızın “DenemeDatabase”inin owner’ı olduğunu görüyoruz.

Aşağıdaki kod ile Database_Owner ı değiştiriyoruz ve best practice’e göre  “sa” yapıyoruz. Sonrasında user’ı siliyoruz.

 

USE DenemeDatabase
GO
sp_changedbowner 'sa'

 

 

NOT: Bu hata ile karşılaşmamak için Instance’a yeni bir ServerRole eklerken veya yeni bir database eklerken owner’ı “sa” user olarak ayarlamalıyız. Eğer ayarlamazsak aradan zaman geçtiğinde ve o kullanıcıyı silmek istediğimizde bir database’in veya server role’un owner’ı olmasında dolayı bu hatalar ile karşılaşmaktayız.

 

Aşağıdaki resimde görüldüğü üzere bir database’i create ederken owner default seçili olarak oluşturmamalıyız. SA kullanıcısına owner’lık vermeliyiz.

 

ÖNEMLİ NOT:

Eğer Always On sistemi ile çalışıyorsak; Database Owner’ı değiştirmek istiyorsak Primary Node’da olmamız gerekiyor. Secondary Node’da iseniz update script hata verecektir. Çünkü secondary node’da iken data üzerinde edit yapılamaz.

Bu nedenle Database Owner’ı değiştirmeye çalıştığınız node, secondary ise o node’a failover olmanız gerekmektedir. Dipnot olarak; Secondary node’a failover olmadan database owner’ı değiştirmenin başka bir yolu bulunmamaktadır.  O sebeple bir database oluştururken owner’ı her zaman sa olarak seçmeli ve bu hatalardan kaçınmalıyız.

Benzer Yazılar

SQL SERVER SERViS RESTART HATASI

SQL Server 2 hafta önce

Bu haftaki yazımızda karşılan bir hata üzerindeki; logları ve çözümünü anlatacağım. Aşağıdaki GÖRSEL-1’de görüldüğü üzere SQL servisini restart ettiğimiz sırada bir hata ile karşılaşıyoruz. Servis running state’e geçemiyor. “The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details” şeklinde bir uyarı veriyor. Hatanın çözümüne doğru ilerlerken farklı servis hesaplarıyla veya “Local System” hesabı ile restart etmeye çalıştığınızda servis ilginç bir şekilde ayağa kalkıyor. Ancak Always on sistem çalışıyorsanız farklı servis hesaplarını kullandığınızda always on size haberleşme izni vermiyor. Aynı hesabın şifresi ile ilgili sorunlar olduğu düşünüp hesabın şifresini de değiştirdiğiniz de yine sonuç alamıyorsunuz. Burdan yola çıkıldığında sıkıntı servis hesabında gibi görünüyor olabilir ancak çözüme geçildiğinde regedit üzerinde yapacağımız bir işlem ile sorunu çözüyoruz. Servis hesabının kaydının olduğu regedit kaydını siliyoruz. Regedit üzerindeki servis hesap bilgisi güncellendiğinde sorun çözülmüş olmakta. GÖRSEL-1  Servis restart edildiğinde SQL’in verdiği Error […]

SQL’DE İKİ NODE’UN RESOLVING DURUMA DÜŞMESİ VE ÇÖZÜMÜ

SQL Server 1 ay önce

Bu yazımızda failover olma işlemi esnasında karşılaşılan bir durumdan kısaca bahsedeceğim. Kısa bir yazı olacak ama önemli olduğunu düşünüyorum. Bazen failover olmak istediğinizde cluster secondary’e node’a failover olamaz, hem secondary hem de primary node’unuz resolving durumuna geçer. Bu durumla daha çok otomatik failover olma durumlarında karşılaşılır çünkü sistem failover’a aslında hazır değildir ancak cluster bunu bir şekilde bilemez. Failover olma gerçekleşemez bir anlamda sql cluster askıda kalır ve hiçbir sunucu da sql engine çalışmaya devam edemez. (GÖRSEL-1) GÖRSEL-1 GÖRSEL-1 üzerinde gördüğünüz üzere availability group resolving duruma düşer. Availability replica’lar üzerinde de gördüğünüz üzere primary ve secondary tüm node’lar resolving state’e düşer. Böyle bir durumunda iki farklı çözüm yolumuz var;   Çözüm: ikinci node’a sunucu restart’ı atmak. Bu noktada secondary sql node’a servis restart atmak işe yaramıyor. Zaten db’ler iki taraflı resolving modda. O sebeple ancak sunucu restart atıldığında cluster ayakta olan sunucuyu görüyor ve askıda kalma durumundan ilk başta primary […]

Query Store Nedir?

SQL Server 1 ay önce

Query Store ile birlikte execution planın seçimi ve bu sürecin performansa etkisini anlayabiliriz. SQL Server içerisinde bulunan Query Store özelliği, çalıştırılan sorguların execution planını ve bu sırada oluşan istatistiklerini otomatik olarak yakalar. Böylece query plan değişikliği ile oluşan problemleri de hızlı ve kolay şekilde fark edebiliriz. Elinizde bulunan bir sorguya ait query plan zamanla değişebilir. Bunun birçok sebebi vardır. Tablo yapısına yeni bir column eklenmesi Veri tipinin değiştirilmesi Sorgularda yeni parametrelerin eklenip çıkarılması Verilerde, schemalarda veya sorgu parametrelerindeki değişiklik Burada önemli olan ise bazen bu değişimler sorgunun yavaş çalışmasına neden olur. Query Store ile beraber bu yavaşlığın kök nedenine inmek daha kolay oldu. Ayrıca query store sayesinde ilgili sorguya ait read-write bilgileri ve cpu tüketimi bilgilerine de erişebilirsiniz. Query Store’u veritabanı seviyesinde aktif edebiliyoruz. Veritabanı üzerine sağ tıklayarak properties diyoruz ve Query Store sekmesine geliyoruz. Operation Mode alanından Read Write’ı seçiyoruz. Böylelikle Query Store gerekli bilgiyi toplayabilir ve size ilgili sonuçları […]

0 Yorum

Yorum Yaz

Rastgele