5 Mayıs 2015 Salı

Bir Unique Index'in eşsizliği, Included Column'lar ile değişir mi?

Merhabalar,

Ortamlarımdan birindeki bir Unique Index'e ekleme yapmam gerektiğinde bunun testini yapmak istedim. Bu testin sonuçlarını sizlerle de paylaşayım.

Öncelikle geçici bir veritabanında aşağıdaki tabloyu oluşturdum:

CREATE TABLE Gecici_Tablo (i int, ii int, e varchar(50))

Daha sonra bu tabloda aşağıdaki Index'leri oluşturdum:

CREATE CLUSTERED INDEX cix on Gecici_Tablo(i)
CREATE UNIQUE INDEX uix on Gecici_Tablo(ii) INCLUDE(e)

Sonra da aşağıdaki kayıtları bu tabloya eklemeye çalıştım:

INSERT INTO Gecici_Tablo values(1, 1, 'a')
INSERT INTO Gecici_Tablo values(1, 1, 'b')
INSERT INTO Gecici_Tablo values(2, 1, 'b')

Yukarıdaki INSERT komutlarından sadece ilki başarıyla tamamlandı, çünkü Unique Index ile eşsizlik sadece Index Key'lerle tanımlanıyor. Bu örneğimizdeki Unique Index'imizdeki tek Index Key de "ii" isimli alandı.

SELECT * FROM Gecici_Tablo

Komutunu çalıştırdığımda sadece aşağıdaki sonuç dönüyor:

1,1,a

Kolay gelsin,
Ekrem Önsoy

SQL Server 2016 dün resmen duyuruldu! Bir de sürpriz var!

Merhaba arkadaşlar,

Dün Amerika'da düzenlenen MSIgnite etkinliğinde Microsoft'un CEO'su Satya Nadella, SQL Server 2016'yı resmen duyurdu.

Bu duyuruyla birlikte aşağıda adresini paylaştığım Blog da yayınlandı. Aşağıdaki blogta (İngilizce) SQL Server 2016'daki belli başlı bazı yenilikleri kabaca bulabilirsiniz. Şahsen bu özelliklerin birçoğu hakkında zaten haberdardım, gerek bloğumdan gerekse Twitter adresimde (@EkremOnsoy) bu özelliklerden bahsediyordum.

Fakat hiç beklemediğim, yeni bir özelliği aşağıdaki blog yazısından öğrendim! SQL Server 2016 ile birlikte Native olarak (yani örneğin XML gibi) JSON veritipi de desteklenecekmiş! Bu demek oluyor ki, PostgreSQL'de zaten bir süredir olan bu veritipi artık SQL Server'da da olacak. İlişkisel verilerinizle Doküman tipi verilerinizi aynı ortamda saklayabileceksiniz! Henüz ayrıntılar net değil veya ben henüz net kaynaklara erişemedim, fakat tahminim JSON ile diğer veritiplerini aynı tabloda barındırabileceğimiz yönünde. Ayrıntılar belli oldukça paylaşırım.

http://blogs.technet.com/b/dataplatforminsider/archive/2015/05/04/sql-server-2016-public-preview-coming-this-summer.aspx

Sevgiler,
Ekrem Önsoy

28 Nisan 2015 Salı

T-SQL İpucu: CONCAT Fonksiyonu

Merhaba arkadaşlar,

Size SQL Server 2012 ile birlikte gelen yeni bir Built-in Function olan CONCAT'ten ve kullanımından bahsetmek istiyorum.

Bildiğiniz gibi SQL Server 2012 öncesinde SELECT içerisindeki bazı değerleri ve metinleri birleştirmek için aşağıdaki gibi bir yöntem uyguluyorduk:

SELECT 'Bir' + ',' + 'İki' + ',' + 'Üç'

Eğer tüm alanlar yukarıdaki gibi metinse, bunda bir sorun olmuyordu. Fakat yukarıdaki kodu aşağıdaki gibi değiştirdiğimizde

SELECT 'Bir' + ',' + 'İki' + ',' + 'Üç' + ',' + 12345

INT ile VARCHAR uyuşmadığı için Conversion hatası alıyorduk. Ben bunu bu örnekte doğrudan literal değerlerle örnekledim, ama biliyorsunuz ki VARCHAR ve INT veritiplerinden oluşan alanlardaki verileri birleştirmeye çalıştığımızda da aynı hatayı alacağız.

İşte bunları çok düşünmemek ve pratik bir şekilde alan değerlerini tek bir metinde birleştirmek için aşağıdaki gibi CONCAT komutunu kullanabiliriz.

SELECT CONCAT('Bir', ',', 'İki', ',', 'Üç', ',', 12345)

Böylece veritipini çok düşünmeden String ve Int alanları aynı fonksiyon içinde birleştirebilirsiniz.

Ayrıca CONCAT, NULL değerlerle de gayet iyi başa çıkıyori ISNULL ile falan kontrol ettirmenize gerek kalmıyor, örneğin:

SELECT 'Bir' + ',' + 'İki' + ',' + 'Üç' + ',' + NULL + 12345

Bu komutu çalıştırdığınızda sonuç NULL döner, fakat aşağıdakini çalıştırdığınızda sonuç:

Bir,İki,Üç,12345

Olacaktır.

İyi kodlamalar!
Ekrem Önsoy

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.