Kategori arşivi: Query Analyzer

SQL Server T-Sql seçme query örnekleri

Geçici Tablo ve Tablo Türü Değişken Arasındaki Fark

Çalışma esnasında bir kayıt listesinin sonucunu geçici saklamak için geçici tablo (temporary table) veya tablo türü değişken (table variable) kullanırız. Peki bunların arasındaki fark nedir ?
SQL Server’de yerel (local) ve genel (global) olmak üzere 2 tür geçici tablo kullanırız. Yerel tabloları başında “#” olacak şekilde isimlendiririz. Genel tabloları başında “##” olacak şekilde isimlendiririz.

--Yerel geçici tablo
SELECT * INTO #t1 FROM Alisveris

--Genel geçici tablo
SELECT * INTO ##t1 FROM Alisveris

Yerel geçici tablo ile genel geçici tablo arasındaki tek fark, yerel tabloya sadece oluşturulduğu oturumdan erişilebilir. Genel tabloya ise diğer oturumlardan da erişilebilir. Geçici tabloların yaşam süresi oturumlarıyla sınırlıdır. Yani oluşturuldukları oturumda DROP edildikleri zaman veya oturum kapatıldığı zaman tablolar silinmiş olur.
Geçici tablolar üzerinde normal tablolarda yaptığımız her türlü (clustered / non-clustered index oluşturma, identity kolon kullanmaz, transaction yönetimi .) DDL ve DML işlemi yapılabilir. Sadece Foreign Key constraint oluşturulamaz. Geçici tablolar normal tablolar gibi diskte (tempdb) tutulur ve transaction log tarafında loglanır.
Tablo türü değişkenler de geçici tablolar gibi aynı amaç için kullanılır. SQL Server’de değişken tanımlanır gibi tanımlanır. Bu tablolar üzerinde sadece cluster index oluşturulabilir.

--Tablo oluştur
DECLARE @Alisveris TABLE (SatirId INT identity(1,1) primary key,
	UrunAdi VARCHAR(50) )

--Kayıt girelim
INSERT @Alisveris VALUES('Urun1')
INSERT @Alisveris VALUES('Urun2')

--Tabloyu okuyalım
SELECT * FROM @Alisveris

Temporary tables ve table variable arasındaki benzer ve farklılıklar şunlardır;

  1. Her ikisi de TEMPDB içerisinde oluşturulur.
  2. Table variable constraint tarafında daha kısıtlı yeteneğe sahip. Primary Key oluşturulabilse de default ve check constraint konusunda başarılı sayılmaz.
  3. Her ikisi üzerinde cluster index oluşturulabilir.
  4. Table variable üzerinde non-cluster index oluşturulamaz.
  5. Table variable için statistic bilgiler oluşturulmaz.
  6. Ve en önemli fark temporary table, transaction yönetimini desteklerken table variable desteklemez.

SQL Server Instance Hangi Portu Kullanıyor

Birden fazla SQL Server instance kurduğumuz makinede hangi instance hangi portu kullanıyor bazen bunu bulmakta zorlanabiliyoruz. Uzaktan makineye erişemiyor olmamızın nedeni çoğu zaman doğru portu bilmiyor olmamızdır. SQL Server’in hangi portu kullandığını birkaç şekilde öğrenebiliriz.
Okumaya devam et

64 bit SSIS – Excel Connection Manager Kullanımı

SQL Server 2008 Integration Services içerisinde veri aktarımı esnasında Excel dosyasını kaynak veya hedef olarak kullanmamıza imkan tanıyan “Excel Source” ve “Excel Destination” bileşenleri bulunmaktadır.

Fakat bu bileşenleri 64 bit SQL Server 2008’in olduğu ortamda kullanmak istediğimizde aşağıdaki hatayla karşılaştık.
[Connection manager “Excel Connection Manager”] Error: SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED: The Excel Connection Manager is not supported in the 64-bit version of SSIS, as no OLE DB provider is available.
Bunun nedeni Excel Connection Manager’in 64bit sürümünün olmayışıdır. Bu bağlantı nesnesini kullanmak için hazırladığımız SSIS paketini 32bit modunda çalıştırmalıyız.
Okumaya devam et

The partner transaction manager has disabled its support for remote/network transactions

SQL Server içerisinde Linked Server, OPENROWSET, OPENQUERY, OPENDATASOURCE, RPC, BEGIN DISTRIBUTED TRANSACTION yöntemlerini kullanarak uzaktaki bir sunucudaki veritabanı üzerinde tanımlama ve düzenleme işlemlerini transaction yönetiminde yapmak için karşı sunucuda Distributed Transaction Coordinator (DTC) servisini aktifleştirmemiz gerekir. Yani aşağıdaki gibi bir sorgu çalıştırdığımızda eğer karşı makineden DTC çalışmıyorsa MSDTC on server ‘DW’ is unavailable. hata mesajını alırız.

BEGIN DISTRIBUTED TRANSACTION
SELECT * FROM DW.Deneme.dbo.Urun
ROLLBACK

Okumaya devam et

SQL Server’de Uyarı Log Dosyaları Yönetimi

SQL Server’de kullanıcıların girişlerini, hataları, uyarıları, backup sonuçları gibi iç sistemle veya kullanıcı işlemleriyle ilgili mesajları Log dosyalarına yazar. Bu dosyalar varsayılan olarak SQL Server’in kurulum klasörünün altıdaki Log klasörünün altında bulunur.
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log
Bu klasörün altında ERRORLOG.1, ERRORLOG.2, ERRORLOG.3 . şeklinde dosyalar oluşturulur.
SQL Server her servis yeniden başladığında o tarihe ait yeni bir dosya oluşturur bir sonraki açılışa kadar aynı dosyayı log verilerini yazar. Bu da özellikle çok uzun süre açık kalan canlı sistemlerde log dosyalarının büyümesine neden olmaktadır. Bu da servisin dosyayı parse etmesi, sistem yöneticininin dosyada bir mesaj aramasını ağırlaştırır. Burada bir optimizasyon yapmak adına servisi kapatmadan SQL Server’in bundan sonra yeni bir log dosyasını oluşturmasını sağlayabiliriz. Bunun sp_cycle_errorlog prosedürü veya DBCC ERRORLOG komutu kullanılır. Bunlar birini çalıştırdığımızda otomatik olarak yeni bir log dosyası oluşacaktır. Böylece büyümüş olan log dosyaları daha küçük parçaları bölünmüş olur.
Burada diğer önemli konu SQL Server’in default olarak son 6 log dosyasını tutuyor olmasıdır. SQL Server’in dosyaları silmeden önce kaç dosya bırakacağını Management » SQL Server Logs menüsünü sağ tıklayıp Configure bölümünden ayarlayabiliriz.

“Configure SQL Server Error Logs” penceresindeki “Limit the number of error log files before they are recycled” seçeneğini aktifleştirip kaç dosyanın aktif olacağını belirleyebiliriz.

Sonuçta ne kadar log dosyası kayıtlarımızda bulunursa istenmeyen bir durum olduğundan o kadar eskiye gidip log dosyaları bizi yönlendirebilir.
SQL Server’de yönetimle ilgili log dosyalarını okumak için sys.xp_readerrorlog veya sp_readerrorlog prosedürleri kullanılır.
SQL Server’in güncel olarak kullandığı Error Log setine ait fiziksel dosyanın konumunu servis başladığında yazdığı log cümlelerinde aşağıdaki ifadeyi filtreleyerek öğrenebiliriz.

USE master
GO
xp_readerrorlog 0, 1, N'Logging SQL Server messages in file', NULL, NULL, N'asc'
GO

Stored Procedure – Tek Parametreyle Tek veya Tüm Kayıtları Seçme

Dışarıdan parametre alan bir Stored Procedure içerisinde parametreye göre bazen sadece o değere eşit olan kaydı bazen de tüm kayıtları getirmesini isteyebiliriz. Bu tür durumlarda tablodan seçim yapmadan önce parametrenin boş ve dolu olduğuna bakarız. Eğer dolu ise WHERE bölümüne kolon filtresi ekleriz boş ise herhangi bir kısıtlama eklemeyiz ki tüm tablo listelensin. Bu amaçla genellikel prosedür üzerinde seçmeli parametre tanımlanır.

CREATE PROCEDURE GetKategori(@KategoriId int=NULL)
AS
IF @KategoriId IS NULL
	SELECT * FROM Kategori
ELSE
	SELECT * FROM Kategori WHERE KategoriId=@KategoriId

Okumaya devam et

Tablodaki Satır Değişmiş mi ? (CHECKSUM ve timestamp)

SQL Server’da uygulamamız için kritik olan tablodaki bazı veya tüm alanların değişip değişmediğini öğrenmemiz gerektiğinde bunun için ya log, history gibi arşiv tabloları oluşturulur veya o satır değiştiği zaman o satır için tanımlı versiyon numarasını değiştiririz. Tarihçe tablolarını oluşturmamız hem değişiklik olup olmadığını hem de verilerin eski ve yeni değerlerini görmemize imkan tanır. Ancak değişiklik olup olmadığını anlamak için tarihçe tablosu ile ana tabloyu JOIN edip kolon seviyesinde fark olup olmadığına bakmamız gerekir. Bu da uğraştırıcı bir durum olduğu için sadece bu amaç için tarihçe tablosu oluşturmak mantıklı olmayabilir. SQL Server’in sunduğu CHECKSUM() fonksiyonu ve timestamp veri türü bu aşamada kolaylık sağmaktadır. Kontrol sayısı olarak türkçeleştirebileceğimiz CHECKSUM() fonksiyonu parametre olarak aldığı değer için bir hash değeri döndürür. Bu değer normal bir veri olabileceği gibi bir kolon veya kolonlar listesi de olabilir.
Okumaya devam et

SQL Deyimlerinin Yürütülme Sırası

T-SQL’de temel olarak veri arama, bulma ve işleme işlemleri gerçekleştirilir. En çok kullanılan yantümce hiç şüphesiz “SELECT” deyimidir. Peki SELECT ve onunla birlikte kullandığımız ifadeler hangi sırayla yürütülmektedir. SQLHacks’de denk geldiğim bu küçük bilgiyi paylaşmakta fayda görüyorum. Bir SELECT cümlesi yüzeysel olarak aşağıdaki formata sahiptir.
SELECT DISTINCT TOP (list)
FROM (LeftTable)
(join type) JOIN (RightTable)
ON (condition])
WHERE (condition)
GROUP BY (list)
WITH (CUBE | ROLLUP)
HAVING (condition)
ORDER BY (list)

SQL Server öncelikle FROM alanındaki kaynakları işler. Ardından kaynaklar üzerinde tanımlı koşulları çalıştırır. Varsa gruplama, özetleme işlemlerini uygular ve son olarak hangi alanlar istenmişse onları seçer.
Bu ifadeler için değerlendirilme, yürütülme sırası aşağıdaki gibidir;

  1. FROM (LeftTable – Sol Tablo)
  2. ON (condition – Şart, koşul)
  3. (join type) JOIN (RightTable – JOIN türü, Sağ tablo)
  4. WHERE (condition – Şart, koşul)
  5. GROUP BY (list – özetleme alanları)
  6. WITH (CUBE | ROLLUP)
  7. HAVING (condition – özetlenmiş alan filtreleri)
  8. SELECT
  9. DISTINCT
  10. ORDER BY (list – sıralama alanları)
  11. TOP (list – kayıt adeti)

SQL İlk ve Son Kayıtlar

Daha önce yazdığım SQL MAX MIN SUM İçin Farklı Alternatifler makaleye benzer olarak. Günlük raporlamada kolaylık sağlayacak bir ipucunu paylaşalım. Şu ana kadarki yazılarda en büyük, en küçük, ortanca, her gruptan n kayıt, rastgele seçim gibi ipuçlarını paylaştık. Bu yazı da herhangi bir grubun ilk ve son kayıtlarının kolayca nasıl bulacağımızı yazacağız. Bu amaç için Oracle cephesinde FIRST ve LAST isimli analitik fonksiyonlar bulunmaktadır. SQL Server 2005 ve sonrasında sunulan DENSE_RANK() fonksiyonu aracılığıyla bunları kolayca seçebiliriz. Bu fonksiyonu kullanarak her grubu içindeki 2. alana göre artan veya azalan sıralayacağız. Artan sıraladığımızda en son kayıtlar, azalan sıraladığımızda ilk kayıtlar “1¨ olarak numaralandırılacaktır.
Okumaya devam et