18 Nisan 2015 Cumartesi

Transactional Replication için çok tatlı bir SP

Selam millet,

Size bugün Susantha Bathige 'nin bir makalesinden öğrendiğim bir SP'den bahsetmek istiyorum. Bu SP, Transactional Replication yapılandırmaları için kullanılıyor. Çok pratik olarak, replike edilen Publication'ların aktarım istatistikleri hakkında bilgi veriyor. Kullanımı, çok basit, Publication'ların olduğu sunucuda SP'yi parametresiz olarak çalıştırıyorsunuz; şöyle:

EXEC sp_replcounters;
GO

Bunun akabinde, aşağıdaki gibi bir sonuç dönüyor:


Sorgu sonucu

Bir sorgu çalıştırarak, hantal olan Replication Monitor arayüzünü kullanmadan, tak diye böyle bir sonucu bu SP sayesinde alabiliyoruz, bu SP'ye buradan teşekkürler ediyorum.

Efendim gelelim SP'nin çalıştırılması sonucu dönen alanların anlamlarına, şöyle izah edeyim:
- database: malumunuz Publication'lara ait veritabanlarının isimleri.
- replicated transactionsTransaction Log dosyasında Distribution veritabanına gönderilmeyi bekleyen Transaction sayısı. Yani an itibariyle Publisher'daki Transaction Log dosyasında bekliyor bu kayıtlar. Eğer bu değer çok çok büyükse, o zaman Distributor ile Publisher arasında bir gecikme veya tıkanma veya başka bir sorun var demektir. Hemen müdahale etmeniz gerekir. Aksi takdirde Transaction Log dosyası (eğer bir üst sınır belirlemediyseniz) şişer, şişer ve bulunduğu diski doldurur. Bu noktadan sonrası çok riskli. Veritabanınız Suspend duruma düşebilir, yeni bir işlem yapılamaz, eğer bu veritabanının Transaction Log dosyası, diğer veritabanlarının Transaction Log dosyalarıyla birlikte aynı diskteyse, diğer veritabanlarının Transaction Log dosyalarının içleri de dolduktan sonra diskte boş yer kalmadığı için büyüyemeyeceklerdir ve o veritabanlarında da artık yeni işlem yapılamaz ve onlar da Suspend duruma düşebilirler. Bu noktada, Replikasyon yapılandırmalarınızın gecikme alarmını muhakkak kurmalısınız. Ayrıca disk doluluk oranı uyarınız, Transaction Log dosyası doluluk uyarınız, muhakkak olmalı. Sorun çıkarması muhtemelen ve kritik veritabanlarının farklı disklere dağılımını, bu açıyı düşünerek de tekrar gözden geçirmek isteyebilirsiniz.
- replication rate trans/sec: Distribution veritabanına gönderilen Transaction'ların saniye başına ortalama sayısı.
- replication latency (sec): Transaction'ların Distribution veritabanına gönderilmeden önce Transaction Log dosyasında ortalama kaç saniye durduklarını gösterir. Bu çok önemli. Bu değer ile replikasyonumuzda ne kadar gecikme yaşandığını anlarız.
- replbeginlsn: Transaction Log dosyasındaki o anki Truncation Point (yani örneğin Transaction Log yedeği alındıktan sonra Transaction Log dosyasındaki kayıtların tam olarak hangi noktadan itibaren silinebileceğini gösteren LSN [Log Sequence Number = Kayıt Sıra Numarası])
- replnextlsnBir sonraki Commit edilmiş ve Distribution veritabanına gönderilmeyi bekleyen kaydın LSN numarası.

Kolay gelsin,
Ekrem Önsoy

7 Şubat 2015 Cumartesi

The operation cannot be performed on database "your_database_name" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group. ALTER DATABASE statement failed. (Microsoft SQL Server, Error: 1468)

ERROR:
The operation cannot be performed on database "your_database_name" because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group. ALTER DATABASE statement failed. (Microsoft SQL Server, Error: 1468)

DESCRIPTION:
If you try to delete a database before removing it from an AlwaysOn Availability Group, then this error occurs.

SOLUTION:
To avoid from this problem, first you should remove the database from the Availability Group that contains it and then delete the database.

11 Ocak 2015 Pazar

HATA: AlwaysOn AG ReadIntent Only Readable Secondary bağlantı hatası

HATA:
Error: Microsoft ODBC Driver 11 for SQL Server : Unable to access the 'veritabanı_adı' database because no online secondary replicas are enabled for read-only access. Check the availability group configuration to verify that at least one secondary replica is configured for read-only access. Wait for an enabled replica to come online, and retry your read-only operation.

AÇIKLAMA:
Bu hatayı bir AlwaysOn Availability Group Listener'ı vasıtasıyla bir ReadIntent Only Readable Secondary sunucuya bağlanmaya çalışırken alabilirsiniz.

ÇÖZÜM:
Eğer bu hatayı alıyorsanız, AlwaysOn Availability Group'u içerisinde ReadIntent Only olarak belirlediğiniz Readable Secondary sunucunuzun SQL Server servisinin çalıştığından, port'ların açık olduğundan ve bu sunucunun erişilebilir olduğundan emin olun. Eğer AlwaysOn Availability Group'unuz içerisinde ReadIntent Only olarak ayarladığınız bir sunucu yoksa, o zaman bu hatayı alan kullanıcının kullandığı uygulamanın Connection String'inde "ApplicationIntent=ReadOnly" gibi bir parametrenin olmadığından emin olun. Eğer bu uygulama SQLCMD ise, bu parametre "-K ReadOnly" olacaktır.

Kolay gelsin,
Ekrem Önsoy

6 Ocak 2015 Salı

Policy Based Management'tan ne kadar yararlanıyorsunuz?

Merhaba!

Policy Based Management (PBM) özelliğinden ne kadar faydalanıyorsunuz?

Birçok ortamda PBM'den faydalanılmıyor. Halbuki Best Practice'lerimizi PBM ile kontrol etmemiz çok kolay. Örneğin SQL Server Instance'ımdaki veritabanlarımın AutoClose ve AutoShrink özellikleri False mu? AutoUpdateStatistics ve AutoCreateStatistics True mu? PageVerify CHECKSUM mı? Veri dosyalarımın büyütülme şekli doğru mu? Belli boyutları aşan dosyalarım var mı ki bunların büyümesini kapatayım ve yeni dosya oluşturayım? Bunları Job'larla veya daha kötüsü manuel kontrol etmemiz dolambaçlı ve sıkıntılı, hele ki PBM gibi bir nimet varken.

Condition'larınızı belirleyin, Policy'nizi tanımlayın. Daha sonra da Evaluation Modu'una göre Error Log'a kaydedilecek hatalar için Alert tanımlayın ve Policy'ler çiğnendiğinde kendinize ve/veya ilgili kişilere haber verilmesini sağlayın.

Bu yazıyı bir dürtme, hatırlatma anlamında yazıyorum, o yüzden ayrıntısıyla değinmeyeceğim PBM'e, zaten internette de birçok makale bulabilirsiniz.

Sevgiler,
Ekrem Önsoy

14 Kasım 2014 Cuma

Transaction Log Shipping Status report

Hello there,

I realise that a good amount of DBAs do not take advantage of the built-in reports in the SQL Server Management Studio (SSMS). I have been using Log Shipping in the production servers for more than 7 years. I have used in-house developer tools to monitor the status of my log shipped databases and SSMS' built-in reports. Every shop can not build their own monitoring tools and some do not have a budget to buy a 3rd party tool; but everyone can benefit from the built-in reports of SSMS!

When it comes to IT generally, monitoring is crucial; with this in mind, to a DBA, monitoring is everything. We manage our systems with monitoring tools. Some need to act proactively and others to react to problems before our managers or users start yelling at us.

Oh , yea, I would write something about monitoring Log Shippings. If yours is a small shop and if you are a small shop probably you will have a primary production server and probably you will configure Log Shipping only on that primary server, then you can use SSMS' Transaction Log Shipping Status report. I wanted to stress out this report because I do not see people write about it on the internet. So I thought this report could be beneficial to junior DBAs or some shops who does not have a DBA or some IT professionals (I call them "all-in-one", no offence!) who has to carry about every IT related stuff in the office.

Here's a screen shot about the report I am talking about:

Transaction Log Shipping Status report

I had to crop the left side of the report because it was too large to fit on my screen, besides I would blur it all that column as they are the database names of one of my production servers.

Anyway, as you can see from the screenshot above, you can see everything you need to know about the status of a database's Log Shipping. How long it's been the last backup has been performed, the threshold and if the alert would be triggered if the threshold was crossed and the details about other fundamental jobs, Copy and Restore of Log Shipping.

Here's how you can open this report:
- Open SSMS and go to Object Explorer,
- Right click on the SQL Server Instance name and select "Reports" and then "Standard Reports"
- You will see "Transaction Log Shipping Status" report at the bottom of the list, click on it and there you go.

You will see much more reports about server monitoring in this chest, you can play with them to learn more.

I hope it helps!

Cheers,
Ekrem Önsoy