Kategori arşivi: SQL Server, Oracle

Sql Server 2000, Sql Server 2005, Sql Server 2008, Sql Server 2012, Sql Server Reporting Services, Oracle, SSIS SQL Server Integration Services

dm_io_virtual_file_stats DMV

SQL Server 2005 ile birlikte gelen DMVler (Dynamic Management Views, Dinamik Yönetim Görüntüleri), SQL Server’in iç dünyasında olup bitenler hakkında önemli bilgiler sunan nesneler kütüphanesidir. Sistem tablolarından beslenen bu nesneler bazen sistemle ilgili anlık bilgiler bazen de geçmiş bilgiler sunar. Bunlarcan onlarca bulunduğu için hepsini bilmek mümkün değil ancak I/O, memory tabanlı performans verileri veya kullanıcı / oturumla ilgili tarihçeye erişmek için kullanacaklarımızı elimizin altında bulundurmamız faydalı olacaktır. Bu sitede yeri geldikçe en çok kullanılanları paylaşmaya çalışacağız.
Okumaya devam et

Index’lerin Aktif/Pasif (Enabled/Disable) Yapılması

SQL Server 2000’de mevcut bir indexi aktif veya pasif yapamıyoruz. Sadece drop edebiliriz. Oysa bazı durumlarda örneğin optimizasyon işlemlerinde veya büyük aktarımlar için (DTS, BCP, BULK INSERT ) kısıtlı zamanlarda geçici olarak bazı indexleri pasif yapma ihtiyacı doğabiliyor. SQL Server 2005 ve sonrasında gelen ALTER INDEX komutu sayesinde bu işlem yapılabilmektedir. Okumaya devam et

SQL Script Dosyalarını Toplu Çalıştırma (OSQL – SQLCMD)

İçerisinde SQL Script’lerin bulunduğu metin dosyalarını komut satırında çalıştırmak için en iyi yöntem OSQL veya SQLCMD programcıklarını kullanmaktır (SQL Server Command Line Tool). Bilindiğim gibi bu araçlar Command Prompt’tan SQL Sunucusuna erişmeyi sağlayıp sorgu çalıştırmamıza imkan tanır. OSQL aracı SQL 2000’den beri kullanılmakta. SQL Server 2005 ile birlikte SqlCmd aracı sunuldu. Aşağıdaki ekranda bu komutların parametreleri görülmektedir.
Okumaya devam et

Linked Server Join Sorgu Performansı

SQL Server üzerinde tanımladığımız Linked Server yapıları uzak sunucuya manual bağlanmadan kolayca sorgular çalıştırmamıza imkan tanır. Linked Server aynı zamanda yerel bir kaynak ile uzak sunucudaki bir kaynağı çağraz sorgulamamızı da (Join) destekler.

SELECT a.*, b.* FROM T1 a
	INNER JOIN ABC.Aliveris.dbo.T2 b
         ON a.SatirKodu1 = b.SatirKodu2

Bu sorgu yereldeki T1 ile ABC isimli uzak sunucu üzerindeki T2 tablosunu Join edip iki taraftaki kolonları listeleyecektir. Fakat bu özelliği kullanırken performans sorunu yaşayabiliriz. Çünkü SQL Server JOIN işlemini yapmadan önce uzak sunucudaki T2 tablosunu kendi tarafına alacak ardından ana sorguyu çalıştıracaktır. Eğer karşı tablo küçük ve bağlantı hızlı ise çok sorun olmayacaktır. Ancak T2 tablosu büyükse veya ağ bağlantısı düşükse performans sorunu yaşayabiliriz. Bu yüzden yerel sunucu ile uzak sunucuyu doğrudan JOIN etmek yerine uzak sunucudaki verileri kendi tarafımıza geçici veya kalıcı bir tabloya aktardıktan sonra JOIN etmemiz daha doğru olacaktır. Hatta tüm tabloyu değil de filtre vererek çekmemiz sadece ihtiyaç duyulan verilerin taşınmasını sağlayacaktır.
Ayrıca uzak sunucu sorgularında Distributed Query yöntemi yerine OpenQuery yönteminin kullanılması her zaman daha hızlı olacaktır. Distributed Query yöntemi, klasik linked server yazım biçimini temsil eder. Yani sorguların SELECT * FROM UzakSunucu.UzakVeriTabani.Şema.TabloAdi şeklinde çalıştırılmasıdır. Bu durumda yerel Query optimizer yol haritasını kendisi belirleyecektir. OpenQuery ise sözkonusu sorgunun yorumlanmadan doğrudan uzak sunucu üzerinde çalıştırılmasını sağlayan bir fonksiyondur. Bu yöntemde tüm yükü uzak sunucu üstlenmiş oluyor.
Konuyla ilgili detayları SQL Server Linked Server (Bağlı Sunucu)
makalemde bulabilirsiniz.

SQL Server 2008 GROUP BY GROUPING SETS GROUPING_ID ROLLUP CUBE

SQL Server eski sürümlerinden beri GROUP BY ile veri özetlemesini destekler ayrıca ara ve alt toplamlar için WITH ROLLUP ve WITH CUBE yantümcelerini sunar. SQL Server 2008, konuyla ilgili GROUPING SETS isimli yeni bir operatör sunmaktadır. Bu makalede bu konudaki değişiklikleri örneklendireceğiz. GROUP BY, WITH ROLLUP ve WITH CUBE yantümceleriyle ilgili detayı aşağıdaki makalemde bulabilirsiniz.
SQL’de veri özetleme ve gizli “OLAP raporlama”
Okumaya devam et

3GB PAE AWE üçlüsü

SQL Server 3GB PAE AWE ayarları, memory, bellek, ram nasıl ayarlanır.

Bu ayarlarla ilgili birçok soru geldiği ve forumlarda bazen bildiklerimizle çakışacak yorumlar yazıldığından bu makalede bu anahtar kodların tam olarak ne işe yaradığını en kısa ve kolay şekilde yazmaya çalışacağım. 3GB ve PAE ayarları boot.ini dosyasına yazılan kodlardır (boot.ini switches). AWE ise işletim sistemi üzerinde çalışan programlara uygulanan bir ayarlamadır. Bu düzenlemelerin yapılma ihtiyacı 32 bit mimariden kaynaklanmaktadır. Konunun hikayesini, 32 bit adreslemeyi aşağıdaki makalemde bulabilirsiniz.
SQL Server’da Maksimum Memory Kullanımı(AWE)
Bu ayarların mantığını kavramak için konuyla ilgili temel kavramlar olan Application (Uygulama), Process (İşlem) ve Virtual Memory (Sanal Bellek) kavramlarını birer cümleyle anlatmak faydalı olacaktır. İşletim sistemlerinin temel görevlerinden biri Bellek Yönetimi’dir. Talebe göre belleği tahsis eder (malloc) veya belleği serbest bırakır (free). Örneğin C programlama dilinde bu fonksiyonlar kullanarak programcı kendisi de gerektiğinde ihtiyacı kadar bellek talep edebilir ve ardından o alanla ilgili işi bittikten sonra belleği serbest bırakabilir yani sisteme geri verir. Okumaya devam et

SQL Server’da Satırın Fiziksel Konumu (%%physloc%%)

Oracle’da satırların disk üzerindeki fiziksel konumunu döndüren ROWID komutu bulunmaktadır. Bu tür komutlar değerleri veritabanında tutulmadığı o anda hesaplandığı için sahte komut(pseudo-column) olarak tanımlanır. Birçok veritabanı yönetim sisteminde her satır için arka tarafta bir ID bilgisi tutulmaktadır. Fakat bu değerleri geliştirilerin okuması zor olabiliyor. SQL Server 2005’te aynı amaç için %%lockres%% komutu eklendi. Bu komutun SQL Server 2008’deki karşılığı %%physloc%% komutudur. Okumaya devam et

Local System, Local Service, Network Service Hesapları

Kendimiz bir servis yazdığında veya SQL Server kurulumunda en çok karşımızı çıkan konusu servisi hangi kullanıcı çalıştıracak. Bu iş genel olarak Local System, Local Service, Network Service kullanıcı hesapları tercih edilir. Bu küçük yazıda bu kullanıcıların farkını belirtip SQL Server cephesinde nasıl bir tercih yapmamız gerektiğini not alacağız.
Local System : Makine üzerindeki en yetkili hesaptır. Hatta Administrator hesabından daha yetkilidir diyebiliriz. Hem yerel hem de network kaynaklarına erişebilir. Bu hesabın adı gerçekte “NT AUTHORITY\SYSTEM” olarak geçmektedir. Temelde NT AUTHORITY\SYSTEM ve Builtin\Administrators yetkilerini içerir. Bu yüzden SQL Server tarafından default olarak sysadmin rolünü alır.
Network Service : Local System / Administrator kullanıcısına göre daha az yetkili olup network kaynaklarına erişecek servis kullanıcısıdır. Bu hesabın kullanıcı adı “NT AUTHORITY\NETWORK SERVICE” olarak geçmektedir.
Local Service : Network Service kullanıcısıyla aynı sınırlı yetkilere sahip olup tek farkı network kaynaklarına erişemez. Bu hesabın kullanıcısı “NT AUTHORITY\LOCAL SERVICE” olarak geçmektedir. Bu account SQL Server veya SQL Server Agent servisleri tarafından desteklenmemektedir. Bu kullanıcı genellikle makinenin dışındaki kaynaklara erişmeyecek servisler tarafında tercih edilir.
SQL Server servisi için mümkün olduğunca Local non-system veya Service kullanıcısını kullanmak yerine bu iş oluşturulmuş bir Domain hesabının kullanılması tavsiye edilir. Ve bu domain hesabının da olabildiğince minimum yetkilere sahip olması gerekmektedir. Eğer SQL Server üzerinden dosya paylaşımı, linked server gibi network kaynak erişimi olacaksa doğru yetkilendirilmiş AD kullanıcısı tercih edilmesi daha doğru olacaktır. Ayrıca birden fazla SQL Server sunucusu varsa bunların tek bir domain kullanıcısı tarafından başlatılması yönetim kolaylığı sağlayacaktır. Eğer SQL Server’in bulunduğu makine Domain’de bulunmuyorsa yerel kullanıcı servisi kullanıcısı olarak tercih edilebilir. Tabi bu kullanıcının Administrator yetkilerine sahip olmamasına dikkat edilmelidir.
Özetle SQL Server ve alt birimlerini için mümkün olduğunca az yetkili bir kullanıcıyla çalıştırmak ve SQL Server ve Agent için ayrı kullanıcıları tercih etmek tavsiye edilir.

The SSIS subsystem failed to load

SQL Server’in bulunduğu makineyi değiştirdikten sonra mevcut sistemde tanımlı Job’ları da yeni sunucuya aktardık. Yöntem olarak msdb veritabanını attach ettik. Bu Job’lar SSIS paketlerini çalıştırıyor. Job’ları çalıştırdığımızda aşağıdaki hatayı aldım.
Unable to start execution of step 1 (reason: The SSIS subsystem failed to load [see the SQLAGENT.OUT file for details]; The job has been suspended). The step failed.
Bu sorunun nedeni eski ile yeni sunucunun SQL Server kurulum klasörlerinin farklı oluşuymuş. Çünkü SQL Server TSQL, CmdExec, SSIS, PowerShell, Snapshot, LogReader, Distribution . gibi SQL Server Agent üzerindeki alt sistemlere ait DLL bilgilerini msdb.dbo.syssubsystems tablosunda tutuyor. Bu tablodaki kütüphane adresleri eski sunucuda farklı olduğu için sistem SSIS paketlerini hangi motorla çalıştıracağını bilemiyor.
Bu sorunun kolay bir çözüm var. sp_verify_subsystems prosedürü ilgili alt sistemler için doğru DLL adreslerini yeniden oluşturuyor. Aşağıdaki gibi tablodaki mevcut kayıtları silip ilgili prosedürü çalıştırmamız yeterli olacaktır.

--Mevcut kayıtları sil
DELETE FROM msdb.dbo.syssubsystems

--Tabloyu yeni DLL adresleriyle yeniden doldur
EXEC msdb.dbo.sp_verify_subsystems 1