24 Ekim 2014 Cuma

Olmayan Core ile sahte paralelizm

Merhaba!

Bugün yine Itzik'in bir yazısını okurken yeni bir şey öğrendim, sizlerle de paylaşmak istedim.

Örneğin SQL Server veritabanı uygulamalarınız için bir test ortamı oluşturdunuz; fakat test sunucunuzun donanımı üretim sunucunuz kadar güçlü değil, ki genelde de böyledir. Haklı olarak test ortamında çalıştırdığınız sorgular için üretilen Execution Plan'lar ile üretim ortamındakiler aynı olsun istiyorsunuz. 

Bunun için test ortamındaki SQL Server Instance'ını -P parametresiyle başlatabiliyoruz, bunu zaten SQL Server ile haşır neşir olan çoğumuz bilir. Bilmeyenler için de şöyle izah edeyim, SQL Server Configuration Manager'ı açın, ilgili SQL Server Database Engine servisinizin özelliklerine gidin ve Startup Parameters'a -Pn parametresini ekleyin, n burada CPU Core sayısı olarak duruyor. Yani örneğin -P8 eklemiş olursanız, fiziksel makineniz 4 Core'lu da olsa SQL Server 8 Core varmış gibi üretecek Execution Plan'ları. Tabii ki bu değişikliğin etkinleşebilmesi için SQL Server Database Engine servisinizi yeniden başlatmanız gerekecek.

Bilmediğim ve çoğu kişinin de bilmediği yöntem ise aşağıdaki yöntem. Bu yöntem Undocumented bir yöntem, yani Microsoft tarafından dokümantasyona eklenmemiş, yani resmen desteklenmiyor. Bir şekilde, ya bir Microsoft çalışanı tarafından resmi olmayan bir şekilde bir yerde yazıldı çizildi de biliniyor ya da bir yerdeki CSS'ten biri veya bir PFE bir müşteride kullandı da öğrenildi.

Peki nedir bu yöntem? Nasıl kullanılır? İnternette bu yöntem hakkında çok bilgi yok şu anda. Komut ise aşağıdaki gibi:

DBCC OPTIMIZER_WHATIF(1,8);

Eğer bu komutu çalıştırırsanız, hiç yukarıdaki -P parametresinde olduğu gibi SQL Server servisini yeniden başlatmanız falan gerekmeyecek. Bu komutnu etkisi, sadece içinde bulunduğunuz oturum için geçerli olacak.

Oturumunuzu yine normal seyrine çevirmek isterseniz de bu komutu aşağıdaki parametrelerle çalıştırabilirsiniz:

DBCC OPTIMIZER_WHATIF(1,0);

Ekrem Önsoy

23 Ekim 2014 Perşembe

Sequence ve Identity kullanımında atlamalara dikkat!

Merhaba,

Bu sabah aşağıdaki makaleyi okurken Identity'lerdeki atlamaların mantığını anladım. Kendi makinemdeki test amaçlı kurulu bir VM'de de test ettim.

Öncelikle bu sorunu bir projede fark etmiştim, bir kişinin makinesine (dizüstü bilgisayar) bir veritabanıyla birlikte çalışan bir uygulama kurmuştuk, SQL Server Express Edition'ı da yükledik tabii makineye. Sonra zaman zaman tablolardaki Identity değerlerinde zıplamalar olduğunu görmüş, ama buna anlam verememiştik.

Aşağıdaki Itzik'in makalesinde nedeni anlaşılıyor. Yaptığım testlerde de doğruladım. Örneğin aşağıdaki gibi bir tablo oluşturun:

-- Tablo oluştur
CREATE TABLE t1_identityCacheTest(i INT IDENTITY(1,1))
-- İçine kayıt koy
INSERT INTO t1_identityCacheTest DEFAULT VALUES
INSERT INTO t1_identityCacheTest DEFAULT VALUES
-- Kayıtları göster
SELECT * FROM t1_identityCacheTest
-- Sonuç:
2
-- SQL Server Instance'ı bir Failover Clustering senaryosunda Failover oluyormuş gibi veya bir Availability Groups senaryosunda Node değiştiriyormuş gibi birden servis kapansın (Task Manager -> End process).

-- SQL Server servisini tekrar başlat
-- İçine kayıt koy
INSERT INTO t1_identityCacheTest DEFAULT VALUES
-- Kayıtları göster
SELECT * FROM t1_identityCacheTest
-- Sonuç:
1002

Bunun nedeni ise SQL Server 2012 ile birlikte artık varsayılan olarak Identity (ve tabii Sequence için) Cache kullanılması. Cache kullanılması Identity ve Sequence performansı için çok iyi oluyor, performans testini de yapmış Itzik.

Arkadaşın makineye kurduğumuz uygulamanın Identity'li tablolarındaki atlamanın nedeni ise, adamın dizüstü makinesini çat diye kapıyor oluşuydu.

Bunların yanında şunu da tekrar hatırlatmakta fayda var, Cache kullanılmasa bile Identity'lerde atlama / boşluk olasılığı her zaman var, örneğin hata alan bir işleminizdeki Identity numarasının boş kalması gibi...

Itzik'in makalesi:

Kolay gelsin,
Ekrem Önsoy

30 Eylül 2014 Salı

Transaction Log'a alternatif mi geliyor?

Merhaba!

Az önce TechEd 2014'te Always On ile ilgili bir sunumu izlerken Senior Program Manager Lead Luis Vargas'ın şöyle bir soruyu:

- Eğer Primary ile Secondary'ler arasındaki bağlantı koparsa, Primary'de Transaction Log'un şişmesini nasıl engelleriz?

Şöyle cevaplandırdığını duydum:
- Bugün Transaction Log büyümeye devam edecek, çünkü herhangi bir veriyi kaybetmek istemeyiz. Bu nedenle Transaction Log dosyası ancak tüm Secondary'ler ilgili Log'ları aldığında temizlenecektir (Truncate olacak). Örneğin eğer birkaç saatlik bir kesinti olduysa ve Transaction Log doluluğu tehlikeli bir noktaya geldiyse, o zaman ilgili replikaları Availibility Group'tan çıkarabilirsiniz ve bağlantı geri sağlandığında replikaları tekrar eklersiniz. Gelecekte bu Transaction'ları Transaction Log'un dışında başka bir yerde konumlandırmayı düşünüyoruz.

Bu sizin ne kadar ilginizi çeker bilemiyorum, ama benim çok ilgimi çekti!

Kolay gelsin,
Ekrem Önsoy

19 Eylül 2014 Cuma

Database Corruption

Arkadaşlar merhaba,

Az önce bir arkadaşım telaşlı bir durumda aradı ve kısa bir süre sonra telaşının nedeni anlaşıldı. 150GB boyutundaki bir veritabanı Corrupt olmuştu.

Bu arkadaşım çalıştığı firmada sistem yöneticisi olarak çalışıyor ve birçok konuda kendisi sorumlu. Windows ve diğer işletim sistemlerinin yönetiminden, ağdan, güvenlikten ve veritabanından gibi. Daha geçenlerde görüşmüştük kendisiyle ve bana şirketinin bütçe ayırmadığından dolayı veritabanı yönetimi konusunda danışmanlık hizmeti alamadığından yakınmıştı.

"Umarım dokunmadın?" dedim, "Dokundum…" dedi. "Ne yaptın?" dedim, "internetten okudum ve DBCC CHECKDB…" derken lafını kestim, "ALLOW_DATA_LOSS parametresiyle çalıştırdın değil mi?" dedim "Evet, 15 saattir devam ediyor. Ne yapabiliriz?" dedi. Bu noktada kendisine yapabileceğim hiçbir şey kalmadığını, bu veritabanına dair en iyi yedeği bulması gerektiğini, eğer sorun güç kesintisindense bunu, SAN'dense onu düzeltip yedekten öyle dönmesi gerektiğini söyledim.

DBCC CHECKDB komutunu Microsoft'ta baştan sona tekrar yazan kişi Paul S. Randal'dır, kendisiyle daha dün başka bir konuda gece e-posta yoluyla konuşuyorduk. Paul DBCC CHECKDB ile ilgili verdiği derslerde, yazdığı makalelerde özellikle ve bıkmadan vurgular, veritabanınız Corrupt olduysa, DBCC CHECKDB'yi "ALLOW_DATA_LOSS" komutuyla çalıştırmak eğer yedeğiniz de yoksa ve o kadar çaresizseniz ve bol bol da vaktiniz varsa ancak o zaman yapılabilirdir.

Bununla birlikte, lütfen ama lütfen beni veya başka bir SQL Server danışmanını Corruption hakkında internetten okuyup bir şeyler uyguladıktan sonra değil, önce arayın. Çünkü yaptığınız her müdahale ile bizim bir şeyleri kurtarma ihtimalimizi azaltıyorsunuz.

Bir veritabanınız herhangi bir nedenden dolayı kullanılamaz duruma geldiğinde ilk bakacağınız şey yedekleriniz olmalı. Ardından eğer veritabanınızı o durumdan kurtarma ihtimalinizi değerlendirmek istiyorsanız ve kurumunuzun bünyesinde de deneyimli bir veritabanı uzmanı yoksa lütfen bir veritabanı danışmanına başvurun.

Lütfen sağlıklı işleyen bir yedekleme stratejiniz olduğundan emin olun, emin olamıyorsanız yine bir veritabanı danışmanına başvurun. Ayrıca sadece veritabanlarınızın yedeklerini almakla yetinmeyin, güzel ve işleyen bir veritabanı yedek kontrol sisteminiz olduğundan da emin olun. Unutmayın, şirketlerin en değerli varlıkları verilerdir.

Ekrem Önsoy

9 Eylül 2014 Salı

CHOOSE fonksiyonu

Merhaba arkadaşlar,

SQL Server'daki CHOOSE fonksiyonunu biliyor muydunuz? Bu fonksiyon SQL Server 2012 ile birlikte geldi. 

SELECT ..., 'xxx' = CASE WHEN yyy = 1 THEN 'xy' ... END ...

Yukarıdaki örnekteki gibi durumlar için pratik bir kullanım sağlayabilir CHOOSE komutu. Örneğin:

SELECT CHOOSE (alan1, 'Manager', 'Director', 'Developer', 'Tester' ) AS Result FROM tablom1;

CHOOSE ile yukarıdaki yazdığım komutun CASE WHEN'lisi şöyle:

SELECT 'Result' = CASE WHEN alan1 = 1 THEN 'Manager'  WHEN alan1 = 2 THEN 'Director' WHEN alan1 = 3 THEN 'Developer' WHEN alan1 = 4 THEN 'Tester' END FROM tablom1

Performans açısından bir katkısı yok, ama dediğim gibi kod yazma konusunda kolaylık sağlıyor.

Bu fonksiyon hakkında daha fazla bilgi için BOL'dan faydalanabilirsiniz:

Ekrem Önsoy