19 Eylül 2015 Cumartesi

HATA: Server '' is not configured for RPC.

HATA: 
Server '' is not configured for RPC.

AÇIKLAMA:
X sunucunuzda Y sunucusu için kurduğunuz bir Linked Server'ı kullanarak X sunucunuzdan aşağıdaki kodu çalıştırdığınızda:

EXEC ('USE [master]') AT []

yukarıdaki gibi bir hata mesajıyla karşılaşabilirsiniz. Çalıştırdığınız komut başka herhangi bir komut da olabilirdi, yukarıda kullandığım "USE [master]" komutu sadece durumu anlatmak içindir.

RPC, Remote Procedure Call demektir ve SQL Server'a has bir özellik değil. Maksadı, uzaktaki sunucuda bir komut çalıştırmaktır.

ÇÖZÜM:
Linked Server yapılandırmanızı, aşağıdaki gibi, RPC'yi etkinleştirecek şekilde değiştirmeniz gerekiyor.

USE [master]
GO
EXEC master.dbo.sp_serveroption @server=N'', @optname=N'rpc out', @optvalue=N'true'
GO

Ekrem Önsoy

15 Eylül 2015 Salı

"msdb" veritabanını temiz tutmak

Selam millet,

Bazen gerçekten gerektiği için ve bazen neden alındığının bile belli olmadığı ve hatta bu yedeklerle ne zaman, kimin ve ne yapılacağının bile bilinmediği ortamlar gördüm. Transaction Log yedeklerinden bahsediyorum. Şirketin RPO ve RTO ihtiyaçları çerçevesinde ve özellikle kritik Production sistemler için Full ve Differential yedeklerin yanında sıklıkla Transaction Log yedeği alınması oldukça normaldir. Recovery Model'ın değişik modlarının ve Transaction Log dosyalarının nasıl yönetileceği tamamen çok geniş ve ayrı konular, ben bu kısa yazımda sizlere Transaction Log'ların sıklıkla alındığı ortamlarda "msdb" veritabanında düzenli temizlik yapılmadığında nasıl bir manzara ile karşılaşılabileceğine dair fikir vermek istiyorum.

Bugün Domain'de olmayan ve bu nedenle (ve tabii ki biraz da ilgili arkadaşımın ilgisizliği nedeniyle) ve benim bu sunucuya henüz kendi denetim ve izleme Script'lerimi kurmamam nedeniyle yukarıda bahsettiğim gibi bir rezaletle karşılaştım.

Efendim, görüntü aşağıdaki gibi:

"msdb" veritabanı yeterince temizlenmediğinde...

Gördüğünüz gibi yedekleme ile ilgili tüm tablolar almış başını gitmiş. Emin olun bundan çok daha beter ve rezil manzaralar da var, gördüm. Bununla birlikte, hazır bunu da görmüşken sizlerle de paylaşıp dikkatinizi çekeyim dedim.

Peki bu tablolar neden böyle dolar? Aslında yukarıda özetle değindiğim konuya tekrar değineyim. Genellikle Full veritabanı yedekleri günde bir kere veya haftada bir kere alınır (tabii ki duruma göre değişir!) ve keza Differential yedeklerin de günde en fazla 4 kere alındığını görmüşlüğüm var. Fakat Transaction Log yedekleri çok daha sıklıkla alınır, mesela her 5 dakikada bir sefer gibi (her 1 dakikada bir alındığını da gördüm!). Bu ne demek? Günde ortalama 288 adet Transaction Log yedek dosyası ve "msdb" sistem veritabanındaki ilgili yedek tablolarında 288 adet kayıt demek. İlgili SQL Server Instance'ındaki veritabanı sayısı, Transaction Log yedek alma sıklığı ve "msdb" veritabanının temizlenmeme süresi hesaba katıldığında, ilgili yedek tabloları gerçekten acayip fazla şişebilir.

Tek çekince tabii ki bu tabloların şişip yer kaplaması değil, genelde ve birçok ortamda bu tabloların tutulduğu "msdb" veritabanının dosyaları "C:" diskindedir. Çünkü DBA barındırmayan birçok şirkette SQL Server kurulumları "next, next" şeklinde yapılır ve Best Practice'ler takip edilmez. Hal böyle olunca, bu veritabanlarının büyümesi C: diskini tamamen doldurur, ki çoğu durumda Windows işletim sistemi ve hatta "tempdb" veritabanı da bu disktedir. Tabii ki bu durumda bir taraftan işletim sistemi teklemeye, "garip gurip" hatalar vermeye başlar, bir taraftan da kullanıcılar "tempdb"den "ilginç" hatalar almaya başlarlar.

Peki "msdb" veritabanınızı bu yedek tarihçesi kirliliğinden nasıl kurtaracaksınız? Aşağıdaki komut ile!

USE msdb;
GO
DECLARE @most_old_record_date DATETIME;

SELECT @most_old_record_date = DATEADD(DAY, - 365, GETDATE());

EXEC msdb.dbo.sp_delete_backuphistory @oldest_date = @most_old_record_date;

Açıkçası yukarıda sizinle paylaştığım Script, benim asıl araç gereç kutumdakinin biraz değiştirilmiş versiyonu. Benim kendi kullandığım Script'lerin bir ana yapılandırma tablosu var, yukarıdaki -365 gibi tüm değerler o tablodan alınır. Size de tavsiyem, "msdb" veritabanında en azından 1 senelik kayıt eğer şartlar mümkünse bulundurun. Böylece örneğin geriye dönük olarak aldığınız yedeklerin boyutunun ne kadar büyüdüğünü tespit edebilirsiniz. Hoş bir istatistiki bilgi.

Şimdilik bu kadar! Esen kalın.
Ekrem Önsoy


An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'DOMAIN\USERNAME', error code 0x5.

HATA:
An exception occurred while enqueueing a message in the target queue. Error: 15404, State: 19. Could not obtain information about Windows NT group/user 'DOMAIN\USERNAME', 
error code 0x5.


AÇIKLAMA:
Dün de bu hata ile karşılaşınca, hatırlayıp arşivime baktım ve bu hata ile 2010 senesinde de karşılaştığımı gördüm.

SQL Server Error Log'larında yukarıdaki gibi hata mesajları görüyordum. Domain kullanıcıları SQL Server'a giriş yapamıyordu ve hatta yeniden başlattığımızda SQL Server servisi bir Domain Account'u kullandığı için başlatılamıyordu.

ÇÖZÜM:
Bu sefer bu hatanın nedeni bu sorunu yaşadığım sunucu üstündeki Time servisinin senkron olmamasından kaynaklanıyordu. Bu servisi tekrar senkron hale getirince sorun çözüldü.

Kolay gelsin!
Ekrem Önsoy