Yazar arşivleri: Ahmet Kaymaz

SQL Server Para Formatı

T-SQL kütüphanesinde içerisinde sayısal bir veriyi yerel para formatında gösterecek bir fonksiyon bulunmamaktadır. Ancak parasal değer MONEY formatında saklanmışsa bu değeri Management Studio üzerinde SELECT ettiğimizde ondalık ayraç (decimal symbol) bilgisini sunucudaki “Region and Language” alanından okuyarak düzenleyebilir.

DECLARE @X MONEY
DECLARE @Y NUMERIC(9,2)
SET @X=125075.25
SET @Y=125075.25
SELECT @X
SELECT @Y

Bu sorgunun sonucu sırasıyla aşağıdaki gibi görünecektir.
125075,25
125075.25

Görüldüğü gibi MONEY türündeki veri için ondalık ayraç olarak virgülü kullandı. Ayrıca veri türü MONEY olduğu zaman virgül ve nokta ayraçları sorun çıkarmadan çevrilebilir. Aşağıdaki iki ifade de “125075,25¨ değeri döner.

SELECT CAST('125075.25' as MONEY)
SELECT CAST('125,075.25' as MONEY)

Değeri gösterirken binlik ayraç (digit grouping) bilgisini de göstermek için CONVERT() fonksiyonu kullanılır. CONVERT fonksiyonuna 3. parametre 1 değeri verildiği zaman binlik ayraçı da göstermiş olacaktır.

SELECT CONVERT(VARCHAR(10), @X, 1)

125,075.25
CONVERT fonksiyonu sadece MONEY türündeki veriler için bu şekilde formatlama yapabilir. Değerin türü MONEY değilse önce MONEY türüne çevirmek gerekecek.

SELECT CONVERT(VARCHAR(10), CAST(125075.25 as MONEY), 1)

T-SQL WITH TIES Seçeneği

Lokasyon ve tutar alanlarının bulunduğu bir tablo düşünelim.

SQL Server’de bu tablodaki satırların TOP N kayıtlarını almak istediğimizde aşağıdaki gibi bir sorgu yazarız.

SELECT TOP 2 location_id, amount FROM Deneme
ORDER BY amount DESC


En yüksek cirolu ilk 2 mağazayı almış olduk. Fakat bazı durumlarda en yüksek cirolu tüm satırları almak isteyebiliriz. En yüksek ciro bu örnekte 420 değeridir. Bu değerden 4 satır bulunmaktadır. Bu satırlarının hepsini almak için SQL Server’de WITH TIES yantümcesi kullanılır. Bu ifade ORDER BY ile sıralanmış sonuç listesi sıralama mantığına uyan aynı değerdeki tüm kayıtları listeler. WITH TIES yan tümcesi ancak ORDER BY ile birlikte kullanılabilir. Sorguyu aşağıdaki gibi güncellediğimiz TOP 2 olarak belirlediğimiz halde tüm 420 değerindeki satırlar listelenmiş olacaktır.

SELECT TOP 2 WITH TIES location_id, amount FROM Deneme
ORDER BY amount DESC

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

VS – JScript Editor Extensions

Visual Studio gibi başarılı bir editörün özellikle 2010 sürümünden sonra geliştirilen eklentileri programcılar için önemli kolaylıklar sağlamaktadır. Fakat çoğu zaman editörü yavaşlattığı için zorunlu olmadıkça bu eklentileri yüklemiyorum. Fakat geçenlerde Java Script tarafında code-behind tarafındaki #region ifadesine benzer bir yöntemin olup olmadığını araştırırken Microsoft’un çıkardığı “JScript Editor Extensions” isimli extension çok işimi gördü. Bu sayede Java Script tarafındaki parantezlerle boğuşmamış olacağız. Daha kolay iç içe kod yazabileceğiz.

Bu sorun için macro çözümleri de geliştirilmiş ancak çok ilgimi çekmedi. Araçla ilgili detaylar aşağıdaki adreste bulunmaktadır;
https://visualstudiogallery.msdn.microsoft.com/872d27ee-38c7-4a97-98dc-0d8a431cc2ed

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

Database cannot be upgraded because it is read-only or has read-only files

Birkaç gün önce sunucu iyileştirme kapsamında SQL Server 2008 instance üzerinde bulunan bir veritabanını detach edip network üzerinden ikinci sunucuya kopyalayıp aynı şekilde SQL Server 2008 R2 üzerine attach etmeye çalışırken aşağıdaki hatayla karşılaştım.
Msg 3415, Level 16, State 3, Line 1
Database [database_name] cannot be upgraded because it is read-only or has read-only files. Make the database or files writeable, and rerun recovery.
Msg 1813, Level 16, State 2, Line 1
Could not open new database [database_name]. CREATE DATABASE is aborted.

Mesajın içeriğine bakınca database dosyalarının işletim sistemi üzerinde salt-okunur olduğunu düşündüm. Oysa dosyaları read-only durumda değildi. SQL Server’i çalıştıran kullanıcının permission ayarlarına baktım onlar da full görünüyordu. Yaptığım araştırmalarda bu işin nedenlerinin farklı olabileceği ve farklı şekillerde çözülebileceği söyleniyor. Muhtemel neden ve çözümleri aşağıda bulabilirsiniz;
Öncelikle bu dosyaların attach edilmesi esnasında başka bir instance tarafından kullanılmadığında ve dosya özelliklerinden ve ya kullanıcı yetkilerinden salt-okunur olmadıklarından emin olmamız gerekiyor.
Birinci çözüm olarak “Everyone” kullanıcısına full access yetkisi verilir. Dosyalar attach edildikten sonra işlem başarılı olduktan sonra Everyone yetkisi geri alınır.
İkinci çözüm veya sorunun nedeni olarak SQL Server kullanıcısına bakılabilir. Benim sorunum buydu. SQL Server servisi AUTHORITY\NETWORKSERVICE kullanıcısıyla başlatılmıştı. Bu kullanıcının attach etmek hakkı olmadığı için servis kullanıcısını LOCAL ACCOUNT olarak değiştirince sorun çözüldü.