AryasoftIT – ARYASOFT

COUNT() fonksiyonu, belirtilen ölçütlerle eşleşen satır sayısını döndürür. Kısacası veritabanındaki kayıtları sayabilmek için yerleşik COUNT() fonksiyonunu kullanırız.

Parantez içinde tanımlanan kriterleri karşılayan satır sayısını sayar. Satırların kendisini döndürmez; kriterlerinize uyan satır sayısını gösterir.

Peki SQL COUNT() işlevinin farklı varyasyonları olduğunu fark etmiş miydiniz? Bu makalede çeşitli bağımsız değişkenleri ve bunların kullanımlarını açıklamış olacağım.

COUNT(*) – COUNT(1) karşılaştırması

COUNT(*) ve COUNT(1) arasındaki farklar hakkında çeşitli tartışmalar görmüş olabilirsiniz. Ve belki de cevabı bulmaya çalışmak kafanızı daha da karıştırmış olabilir. Herhangi bir fark var mı diye soracak olursanız cevap basit. Hayır – hiçbir fark yok.

COUNT(*), NULL değerler de dahil olmak üzere tablodaki toplam satırları sayar.

COUNT(1) , sorgu sonuç kümesindeki tüm kayıtları 1 değeriyle değiştirir. NULL değerleriniz varsa, bu da 1 ile değiştirilir. Bu nedenle, COUNT(1) ayrıca toplam kayıt sayısını (NULL’lar dahil) döndürür.

Ancak, COUNT(*) ve COUNT(1) için sonuçlar aynıdır.

Bu iddiayı örnek bir sorgu kullanarak test edelim. İçinde 11 kayıt bulunan ofis adında geçici bir tablomuz olduğunu varsayalım. İlk 10 kayıt NOT NULL iken, son kayıtlar NULL.

Fonksiyon olarak * kullanıldığında, NULL’lar da dahil olmak üzere toplam satır sayısını sayar.

Örnekte, tabloda 11 satırımız olduğu için sonuç olarak 11 alacağız.

COUNT(1) ile ilgili kayıtları ilk sütundan itibaren saydığı şeklinde yanlış bir kanı vardır. COUNT(1)’in gerçekte yaptığı şey, sorgu sonucundan elde ettiğiniz tüm kayıtları 1 değeriyle değiştirip satırları saymaktır, yani bir NULL’u bile 1 ile değiştirerek sayarken NULL’ları dikkate alır.

Uygulamalı olarak görecek olursak, aşağıdaki resimde 11. satıra dikkat edin. Tablomuzda, sütun adı için 11. satır NULL’dur, ancak SELECT 1 FROM #office yaptığımızda, bu NULL’u 1 ile değiştirir ve bu nedenle satırları saydığımızda 10 değil 11 elde ederiz.

Dolayısıyla, her ikisi de sayarken NULL’ları dikkate aldığından, COUNT(1) ve COUNT(*) her zaman aynı sayıda satır döndürecektir.

Peki COUNT(column_name) Fonksiyonu Ne Yapar?

Fonksiyon olarak bir sütun adı (column_name) kullanıldığında, NULL’lar hariç toplam satır sayısını sayar, yani NULL’ları dikkate almaz.

Örneğimizde id sütununu saydığımızda 11, name sütununu saydığımızda ise 10 elde edeceğiz. Ofis tablosunu sorgulayarak kontrol edelim.

Son olarak çok merak edilen bir soru ile makaleyi tamamlamak istiyorum.

COUNT(*) COUNT(1) Arasında Performans Farkı Var Mı?

Sonuç olarak COUNT(1) ve COUNT(*) birbirinin yerine kullanılabilen ve aynı sonucu döndüren yapılardır. Her ikisi de NULL değerleri göz ardı etmez ve her ikisi de belirli bir tablonun satır sayısını döndürür. Kolon sayısı fazla olan tablolarda COUNT(*) kullandığınızda performans kaybı yaşayabileceğiniz için COUNT(*) fonksiyonu dikkatli kullanılmalıdır.

Özetle;

COUNT(*) NULL’lar dahil tüm satırları sayar,

COUNT(1) NULL’lar dahil tüm satırları sayar,

COUNT(sütun_adı) tüm satırları sayar ancak NULL’ları saymaz

SQL Server üzerinde farklı veri tabanlarını kullanarak işlem yapmak mümkündür. Aynı Server üzerinde bu işlemi kolayca yaparken network üzerindeki farklı serverlara erişebilmek için Linked Server kullanılır. Linked Server, aynı instance üzerinde farklı veri tabanları arası, farklı sunucularda bulunan veri tabanları arası veya farklı bir kaynaktan veri aktarımı yapılmak istendiğinde kurulan bir yapıdır. Peki bu linked server tam olarak nedir? Linked Server SQL Server ile uzaktaki bir veri kaynağından veri okumanıza ya da sorgu çalıştırmanıza olanak sağlayan bir özelliktir. A ve B veri tabanları arasındaki tablolarda sanki aynı veri tabanındaki tablolarda yapabildiğiniz gibi JOIN vb. işlemleri gerçekleştirebilirsiniz. Bahsettiğimiz veri tabanları aynı sunucu üzerinde olabildiği gibi farklı sunucularda da olabilir. Linked server nasıl kullanılır? Biz örneğimizi aynı sunucu üzerinde bulunan 2 farklı veri tabanı ile gerçekleştireceğiz. Örneğimiz için 2 tane veri tabanı oluşturalım birisi AdventureWorks2014 adında diğeri de Aryasoft adında olsun. Veri tabanlarımızı oluşturduktan sonra sol menüdeki Server Objects menüsü altındaki Linked Servers seçeneğine sağ tıklayarak New Linked Server seçeneğine tıklayarak yeni bir Linked Server oluşturma ekranını açıyoruz.

Açılan pencere aşağıdaki gibi olacaktır. Burada Linked server kısmına bağlantımızın ismini giriyoruz. Local makinede çalıştığım için adres olarak yine localhost’a bağlanıyorum. Siz uzaktaki bir veri tabanı ile çalışıyorsanız o zaman bağlantı adresinizi ona göre değiştirmeniz lazım.

Data Source alanı mutlaka doldurulmalıdır. <Yukarıdaki alanları sırasıyla inceleyecek olursak;

Linked Server : Oluşturduğumuz Linked Server için bir isim belirlediğimiz alan.
Provider : Burada bağlanmak istediğiniz veri tabanı için bir provider seçmelisiniz. Biz SQL Server ile çalışacağımız için Microsoft OLE DB Provider for SQL Server seçeneğini seçiyoruz.
Product name : Bu kısıma istediğiniz ismi verebilirsiniz. Benim tavsiyem eğer farklı sunucudaki bir veri tabanı ile çalışıyorsanız onun sürümünü yazmanızdan yana olacaktır. Örn: MSSQL 2012 Standard
Data source : Bağlantı yapacağımız veri tabanı sunucusunun adresi
Provider String : Buraya bağlanmak istediğiniz diğer veri tabanının ya da Excel dosyasının bilgisini girebilirsiniz. Örn: Excel 97–2003 sürümleri arası için Excel 8.0 yazabilirsiniz.
Catalog : Bağlanmak istediğimiz veri tabanının adı.

Ardından Security sekmesine geçiş yapılır. Eğer aynı sunucu üzerinde işlem yapılacak ise “Be made using login’s current security context” seçimi yapılır. Fakat bağlantı yapacağımız veri tabanı farklı bir sunucu da ise “Be made using this security context” alanını seçtikten sonra “Remote login” ve “With Password” alanlarını bağlantı yapacağımız veri tabanına erişim yetkisi olan bir kullanıcının bilgileri yazılmalıdır.

Security kısmında ayrıca Local login, Remote user ve Remote password alanlarının olduğunu farketmişsinizdir. Buradaki Local login bölümü sizin linked server oluşturduğunuz veri tabanında varolan kullanıcıları seçebileceğiniz/yazabileceğiniz alan. Remote user ve password bölümü ise uzaktaki erişmek istediğiniz sunucuda yer alan kullanıcı ve o kullanıcının şifresini gireceğiniz bölüm. Bizim iki veri tabanımız da localde olduğundan dolayı herhangi bir ayar yapmama gerek yok. Buradaki seçenekleri yakından inceleyelecek olursak;

Be made without using a security context : Excel dosyası gibi herhangi bir authentication işlemi gerektirmeyen bağlantılarda kullanılır. Fakat farklı bir SQL Server ile çalışırken Not be made ile aynı şekilde çalışmaktadır ve hata almanıza sebep olabilir.
Be made using the login’s current security context : Bu seçenekte ise local login bilgileri ile uzakta olan sunucuya giriş yapmak için kullanılır. Örneğin eğer local sunucuda Windows Authentication seçeneği kullanılıyorsa uzak sunucuda da Windows Authentication seçeneğinde kullanılan bilgilerle giriş yapmayı deneyecektir.
Be made using this security context : Bu seçenekte ise remote login ve remote password alanına girilen bilgiler ile sunucuya giriş yapılacaktır. Burada girilen bilgiler karşıda bağlanılmaya çalışılan sunucuda mevcut değilse kullanıcı olmadığına dair bir hata ekranı karşınıza çıkar.

Bilgilerimizi doldurup kaydettikten sonra sorgu çalıştırmak için hazır hale gelmiş oluyoruz. Sorgu çalıştırmanın iki farklı yöntemi mevcut. Birisi OpenQuery dediğimiz yöntem diğeri ise Four-part Name adındaki yöntem. İlk olarak Four-part Name örneğine ardından OpenQuery örneğine bakalım ve makalemizi sonlandıralım. Four-part Name : SELECT Name FROM [LOCALSERVER].ECommerce.dbo.Product OpenQuery : SELECT * FROM Openquery(LOCALSERVER, ‘select * from Product’) Son olarak Server Options sekmesine tıklatılır. Bağlantı için aşağıdaki resimde görülebileceği gibi üstteki beş adet seçeneği True olarak işaretlemek yeterli olacaktır.

Bu şekilde OK denir. Linked Servers altına verilen isimle oluşturulmuş olur.

Linked Server üzerinde nasıl sorgu yazılır? Bir sorgu çekelim. –openquery ile Select * from Openquery([LSERVER], ‘select * from AdventureWorks2016.dbo.Person’) –Köşeli parantez içine Linked Server’a verilen isim yazılamalıdır. Select * from [LSERVER].AdventureWorks2016.dbo.Person

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim

Bazen tablolar üzerinde kayıtların listelenmesi yerine kayıtlar üzerinde hesaplamalar yaptırarak sonuçların listelenmesine ihtiyaç duyarız. Bu nedenle tüm kayıtları döndürmeden sadece matematiksel sonuçlar döndürmemiz gerekebilir. SQL bu gibi durumlar için özel fonksiyonlar sunmaktadır. Bu Fonksiyonlara Aggregate Function (Hesaplama Fonksiyonları) denir. Peki bu fonksiyonlar bizlere neler sunmaktadır ; sütundaki tüm değerlerin toplamını bulmak, sütundaki tüm degerlerin ortalamasını bulmak, sütundaki en büyük veya en küçük değeri bulmak, Toplam kayıt sayılarını hesaplamak. Bu fonksiyonları kullanırken bazı dikkat edilecek noktalar vardır. Bu noktalar:

AVG ve SUM fonksiyonları sadece sayısal değerler üzerinde kullanılabilirler.
MIN, MAX ve COUNT fonksiyonları sayısal, string ve geçici veri sütunları üzerinde kullanılabilirler.
Bu fonksiyonlar TEXT, NTEXT ve IMAGE veri tipindeki kolonlar üzerinde kullanılmaz.
Bu fonksiyonlar NULL değerleri hesaba katmaz, yok sayar. Özellikle COUNT işlemleri için bu duruma dikkat etmek gerekir.
Eğer COUNT ile birlikte (*) kullanılırsa tüm satırların verilerini (kolonda NULL veri olsa bile) sayabiliriz.
Toplama fonksiyonunun kullanıldığı bir sorgu artık toplama işlevli bir sorgu olmuş olur.

NOT: Vereceğim örneklerde Nortwind db’ini kullanacağım. SUM() KULLANIMI SUM() fonksiyonu ile belirtilen alandaki değerlerin toplamı elde edilir. Örneğin elimizdeki ürünlerin toplam değerini bulmak için kullanılabilir veya elimizdeki toplam stok adedini bulabiliriz. Sadece sayısal alanlarda kullanılabilir.Yani, metin ve tarih gibi veri türlerinde kullanılamaz. Ayrıca, “SUM()” fonksiyonu sadece NULL değerlerini dikkate almaz. Eğer NULL değerlerin de dikkate alınması gerekiyorsa, “SUM(col_name)” ifadesi yerine “SUM(COALESCE(col_name, 0))” ifadesi kullanılmalıdır. Bu ifade, “col_name” sütunundaki NULL değerleri 0 ile değiştirerek toplama işlemini gerçekleştirir.

SELECT SUM(sütun_adı) FROM tablo_adı WHERE koşul;

Örneğin, Toplam kaç adet malın sipariş verildiğini bulalım.

SELECT SUM(Quantity) AS Toplam_Ürün FROM [Order Details] MIN() KULLANIMI MIN() fonksiyonu belirtilen alandaki en küçük değeri verir. Tablomuzda 100 lerce ürün kaydının olduğunu düşünün. En düşük fiyatın ne olduğunu bulmak istediğimiz durumda tek tek fiyatları kontrol edip en ucuz fiyatı bulabiliriz. Ancak bu oldukça büyük bir zaman kaybına yol açacaktır. Bunun yerine bir sql kodu ile sonuca direk ulaşabiliriz. Aynı şekilde muhasebe departmanı müdürü veya şirektin genel müdürü, personele ödediği en düşük maaşı görmek isteyebilir. Bu durumda da bir sql kodu ile sonuca gidebiliriz. Sadece sayısal alanda değil aynı zamanda da metinsel alanlarda da kullanılabilir. Bu durumda metinsel veriyi A’dan Z’ye dizip en baştaki kaydı (A ile başlayan kayıtları) verecektir.

SELECT MIN (sütun_adi) FROM tablo_adi WHERE koşul;

Ürünler (Products) tablosundaki en küçük fiyatlı ürünü listeleyelim.

SELECT MIN(UnitPrice) AS Minimum_Fiyat FROM Products MAX() KULLANIMI MAX() fonksiyonu belirtilen alandaki en büyük değeri verir. Sadece sayısal alanda değil aynı zamanda da metinsel alanlarda da kullanılabilir. Bu durumda metinsel veriyi A’dan Z’ye dizip en sondaki kaydı verecektir.

SELECT MAX (sütun_adi) FROM tablo_adi WHERE koşul;

Ürünler (Products) tablosundaki en yüksek fiyatlı ürünü listeleyelim.

SELECT MAX(UnitPrice) AS Maksimum_Fiyat FROM Products AVG() KULLANIMI AVG() fonksiyonu ile belirtilen alandaki değerlerin ortalaması elde edilir. Elimizdeki ürünlerin ortalama değerini bulmak için kullanılabilir. Sadece sayısal alanlarda kullanılabilir.

SELECT AVG (sütun_adi) FROM tablo_adi WHERE koşul;

Örneğin, 22 kayıt numaralı tedarikçiye ait ürünlerin tekil değerilerinin ortalama fiyatını almak isteyelim.

SELECT AVG(DISTINCT UnitPrice) AS tekil_ortalama_deger FROM Products WHERE SupplierID = 22 COUNT() KULLANIMI Daha önce yayınladığımız makalede count() fonk kullanımını daha detaylı incelemiştik. Göz atmak isterseniz linke tıklayabilirsiniz https://aryasoft.com/2023/05/05/sql-server-count-fonksiyonu-kullanimi/ Belirtilen şartlara göre listelenen satır sayısını döndürür.

SELECT COUNT (sütun_adi) from tablo_adi where koşul;

Tedarikci Numarası (SupplierID) 5 olan tedarikçiye ait ürünlerin sayısını öğrenelim.

SELECT COUNT(*) AS Ürün_Sayısı FROM Products WHERE SupplierID = 5 COUNT() DISTINCT KULLANIMI DISTINCT ifadesi COUNT ile birlikte kullanıldığında, belirtilen sütundaki benzersiz kayıtların sayısını verir.

SELECT COUNT (DISTIMCT sütun_adi) from tablo_adi where koşul;

Son örneğimiz olarak siparişlerin kaç farklı müşteriden alındığını öğrenelim.

SELECT COUNT (DISTINCT CustomerID) FROM Orders

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim

Bu yazımızda Sql veri tiplerinin özellikleri ve kullanım alanlarından bahsedeceğiz. Veritabanı içerisinde tablolar oluşturulurken, depolanacak her veri için, en ideal veri tipinin belirlenmesi gerekir. Sebebi performansı etkilediği içindir. Küçük uygulamalarda göze çarpmasada büyük uygulamalarda veri tiplerini doğru şekilde belirlemiş olmak, verilerin disk alanında daha az yer kaplamasını, verileri daha seri çekmesini sağlar yani performansa olumlu yönde katkıda bulunur. Veri tabanımızı oluştururken veri tiplerini doğru seçmek bizim için çok önemlidir. Veri tabanımızın performansını etkileyebilecek önemli konulardan birisidir. Şimdi sırasıyla kullanabileceğimiz veri tiplerinin neler olduğunu inceleyelim: Eğer amacınız veri tabanı geliştirme ve yönetimi ise, veri türleri kategorilerindeki benzerlik ve farklılıkları not etmek ve stored procedure’ler için tür ve dizayn parametreleri oluştururken depolama alanınızı buna göre planlamak isteyebilirsiniz. 1) Metinsel Veri Tipleri char: Unicode’u desteklemeyip char(n) şeklinde kullanılırlar. 8000 karaktere kadar değer alabilirler. Belirtilenden(n) az karakter girilse dahi giriş yapılan boyut kadar yer kaplar. Veri giriş boyutları benzer, sabit olan veri kümelerinde kullanılması önerilir nchar: Unicode(uluslararası karakter setini, tanımlı tüm alfabeleri içerir.)destekler. Chardan farklı olarak maksimum 4000 karaktere kadar değer alabilir. varchar: Chardan farklı olarak verinin boyutu kadar yere kaplar. 8000 karaktere kadar depolama yapar. Birbirinden farklı uzunlukta veri girişi yapılacağı zaman kullanılması önerilir. Varchar (MAX) kullanımı ile 2GB’a kadar depolama yapılabilir. nvarchar: Verinin boyutu kadar yer kaplar. Varchardan farklı olarak unicode’u destekler.4000 karaktere kadar değer alabilir. text: Belirtilenden az değer girilse bile boyutu kadar yer kaplar.2GB’a kadar metinsel veri depolar. Unicode’u desteklemez. ntext: Text’den farklı olarak girilen karakter boyutu kadar yer kaplar ve unicode’u destekler. !NOT: Microsoft, Text ve Ntext veri türlerini performans kaybı yaşanma ihtimalinden dolayı kullanmayı önermiyor. 2) Binary (ikilik) Veri Tipleri Binary string veri türleri, bir geliştiricinin serileştirilmiş dosya, byte stream’ler ve diğer özel veriler gibi binary bilgileri depolamasına izin verir. Binary veri türü, sayısal ve karakter dizisi veri türleriyle karşılaştırıldığında aralık ve depolama gereksinimlerindeki farklılıkları vardır. Sabit ve değişken uzunlukta binary string verilerinin her ikisini de kullanabilirsiniz. Bunlar arasındaki farklar ilerleyen bölümlerde yer alan karakter veri türü bölümünde açıklanacaktır. Binary: 1 ve 0 ları temsil eden ikilik taban veri tipidir. Sabit uzunluklu veri tiplerinde kullanılırlar.8000 byte’a kadar depolama yapabilir. Varbinary: Binary’den farklı olarak girilen karakter kadar yer kaplar. Bu yüzden uzunlukların değişken olduğu durumlarda tercih edilir. Image: Resim dosyalarını saklamak için kullanılır. En fazla 2 GB’a kadar veri depolar. Bunun yerine varbinary(MAX) kullanılması tercih edilir. !Not: Image veri türü de bir binary string veri türüdür ancak SQL Server’ın gelecekteki bir sürümünde kaldırılacaktır. Bunun yerine varbinary(max) kullanılmalıdır. 3) Sayısal Veri Tipleri Sayısal veri türleri exact numeric and approximate numeric olmak üzere iki alt kategoriden birine girer.

Exact numeric veri türleri:
- Integer veri tipleri: Tamsayı veri türleri (tinyint, smallint, int, bigint) arasındaki fark, kapasiteleri ve depolama gereksinimleridir. Örneğin, tinyint veri türü 1 baytlık depolama maliyeti ile 0 ila 255 arasındaki değerleri tutabilir. Buna karşılık, bigint veri türü -2^63 (-9,223,372,036,854,775,808) ile 2^63-1 (9,223,372,036,854,775,807) arasında 8 bayt veri tutabilir.
- Decimal veri türleri: Bu veri türleri, saklanacak toplam basamak sayısı (kesinlik) ve ondalık basamağın sağındaki basamak sayısı (ölçek) ile belirtilir. Hassasiyet ne kadar büyük olursa, depolama maliyeti de o kadar yüksek olur. Ondalık(decimal) veri türü ile sayısal(integer) veri türü arasında işlevsel bir fark olmadığını unutmayın. Ondalık, ISO standartlarına uygun bir isimdir; integer ise SQL Server’ın önceki sürümleriyle geriye dönük uyumluluk için kullanılmaktadır.
- Parasal veri türleri: Dört ondalık basamağa kadar ölçekle parasal değerleri depolamak için veri türü. Integer veri türlerinde olduğu gibi, money ile smallmoney arasındaki fark, kapasiteleri ve depolama gereksinimleridir. Smallmoney veri tipi -214.748.3648 ile 214.748.3647 arasındaki değerleri 4 bayt depolama maliyetiyle tutar. Money veri tipi -922.337.203.685.477.5808 ile 922.337.203.685.477.5807 arasındaki değerleri 8 bayt depolama maliyetiyle tutar.
- Boolean veri türü: Bit veri türü, SQL Server tarafından sayısal değerler olarak işlenen Boolean değerlerini (true / false) depolamak için kullanılır; true için 1 ve false için 0.
Approximate numeric veri türleri: Bu veri türlerinin kesinliği daha azdır, ancak exact numeric veri türlerinden daha fazla kapasiteye sahiptir. Değerleri hassasiyet eksikliği nedeniyle doğruluğu kaybeden bilimsel notasyon içerisinde saklar.
- Float: Float veri türünde float sayısının mantisini bilimsel gösterim şeklinde saklamak için kullanılan isteğe bağlı olarak bit sayısı parametre şeklinde alır. Mantis değerinin büyüklüğü float verisinin depolama boyutunu belirler. Mantis 1 ila 24 arasındaysa, şamandıra 4 bayt gerektirir. Mantis 25 ila 53 arasındaysa, 8 bayt gerektirir.

Bit: Bir byte uzunluğunda tam sayı veri tipidir. Genellikle evet/hayır şeklinde mantıksal bilgileri tutmak için kullanılır. Int: 4 byte büyüklüğünde, -2 milyar /+2 milyar arasında değer tutabilen tam sayı veri tipidir. Bigint: 8 byte büyüklüğünde -2⁶³ ve 2⁶³ arasında değer tutabilen tam sayı veri tipidir. Smallint: 2 byte büyüklüğünde -32.768 ve 32.768 arası değer alabilen tam sayı veri tipidir. Tinyint: 1 byte büyüklğüne sahip, 0–255 arası tam sayı veriler için kullanılan tam sayı veri tipidir.

Decimal,numeric: İkisinin de kullanımı aynıdır.Bu veri tipinde saklanacak sayının basamak sayısı tanımlanabilir. Veri tipi boyutu belirtilen basamak sayılarına göre değişkenlik gösterebilir.-38 ve +38 basamak arası verileri depolayabilir. -10³⁸ ,10³⁸ arası ondalık ve tam sayı türünde veri saklayabilir.

4) Parasal Veri Tipleri Money: 8 byte boyutunda, yaklaşı -2⁶⁴ ile 2⁶⁴ arasında parasal değerleri tutmak için kullanılır. 4 basamağa kadar duyarlı ondalık tipli verileri saklar. Smallmoney: 4 byte uzunluğunda yaklaşık -214.000 ile 214.000 arası parasal değerleri tutmak için kullanılır. Money tipinde olduğu gibi 4 basamağa kadar duyarlı ondalık tipli verileri saklarken kullanılır. 5)Tarih-Zaman Veri Tipleri Date: Tarihleri YYYY-AA-GG (yıl-ay-gün) formatında saklar. 3 byte uzunluğunda veri tipidir. Smalldatetime: Tarih ve zaman verilerini yıl-ay-gün ve saat-dakika-saniye-salise şeklide saklar. 4 byte uzunluğunda veri tipidir. Datetime: YYYY-AA-GG şeklinde tarih ve zaman verilerini tutan 8 byte uzunluğunda veri tipidir. 1 Ocak 1753–31 Aralık 9999 arası veriler için kullanılır. Datetime2: Datetime’dan farklı olarak 1 Ocak 0001–31 Aralık 9999 tarihleri arası verileri tutan ekstra olarak salise hassasiyeti daha yüksektir. Kapladığı alan salise hassasiyetine göre 6–8 byte arası değişebilir. Time: Sadece saat verilerini saat-dakika-saniye-salise(7 basamaklı) şeklinde saklayan , boyutu kullanıcı tarafından değiştirilebilen 3–5 byte arası yer kaplayan veri tipidir. Datetimeoffset: Ülkelere göre değişen zaman farkını hesaplayıp tutarken kullanılır. 6) Diğer Veri Tipleri Sql_variant: sayı,metin, binary gibi farklı veri tiplerini depolamak için kullanılan veri tipidir. Yani bir sütun ya da fonksiyonda birden fazla veri tipi kullanmamız gerektiğinde tercih etmeliyiz.

xml: XML türünde veri saklamak için kullanılır. Kapasitesi 2 GB’dır. Bellekteki boyutu, saklanan XML verisine göre değişkenlik gösterir. Xml veri türü, Extensible Markup Language verilerinin (XML) depolanmasına ve değiştirilmesine izin verir. Xml veri türünün bir karakter veri türüne göre avantajı, xml veri türünün XML node ve feature’lerinin XQuery ifadeleri kullanılarak bir T-SQL sorgusu içinde bu veri türüne sorgu atılmasına izin vermesidir. Xml veri türü isteğe bağlı olarak bir XML şemasının uygulanmasına da izin verir. Her bir xml veri türü örneği 2 GB’a kadar veri saklayabilir.

Geometry: Öklid koordinat sistemine ait verileri tutmak için kullanılır. Geometrik şekillerin en-boy-yükselik verilerini saklar. Timestamp: Tabloya kayıt eklendiğinde , güncellendiğinde binary türünde özel değer alan veri tipidir.

Uniqueidentifier: 16 byte uzunluğunda benzersiz GUID tipinde veri tutar.İki GUID birbirinden tamamen farklıdır eşit olamazlar. uniqueidentifier veri türü, 16 baytlık boyutunda depolanan genel benzersiz tanımlayıcıların (GUID’ler) oluşturulmasına ve saklanmasına izin verir. uniqueidentifier veri türünde saklanacak değerler, NEWID() sistem fonksiyonu kullanılarak SQL Server’da oluşturulabilir, harici uygulamalar tarafından da üretilebilir veya string değerlerden dönüştürülebilir. Bu iki GUID’lerin aynı olma ihitmali çok düşüktür, ama imkansız değildir.
Hierarchyid veri türü, aynı tablodaki satırlar arasındaki hiyerarşik ilişkilerin kaydedilmesini ve sorgulanmasını basitleştirmek için kullanılır. Örneğin, bir kuruluş şemasında bulunan düzeyler veya malzeme listesi. SQL Server, hierarchyid bir binary veri türünü değişken uzunlukta depolar; hiyerarşi değerinin gösterimi built-in fonksiyonlarla sağlanır.
Rowversion veri türü, otomatik olarak oluşturulan 8 baytlık bir binary değeri, her satır eklendiğinde veya güncellendiğinde artan bir tabloda depolar. Rowversion veri değerlerinde tarih veya saat bilgileri depolanmaz, fakat bir satırın client tarafından en son okunduğundan bu yana değişip değişmediğini tespit etmek için kullanılabilir (örneğin optimistic locking uygularken).
Geometry veri türü, verileri Öklid (float) koordinat sisteminde depolamak için kullanılır. Çizgileri, çokgenleri ve diğer basit geometrik şekilleri tanımlayan koordinat dizileri geometry veri tipinde saklanabilir. Geometri verileri üzerinde işlem yapmak için özel built-in fonksiyonlar bulunmaktadır.
Geography veri türü, verileri GPS enlemi ve koordinatlı boylam gibi bir yuvarlak toprak koordinat sisteminde depolamak için kullanılır. Geography veri türünde olduğu gibi, şekil tanımları geography türünde saklanabilir ve bu veriler üzerinde işlem yapmak için özel built-in fonksiyonlar bulunmaktadır .
Sql_variant türü, örneğin tamsayı, ondalık ve karakter verilerinin aynı sütunda depolanmasını sağlayan diğer yerleşik veri türlerinin verilerini depolamak için kullanılabilen özel bir türdür. sql variant kullanımı tipik veri tabanı tasarımları için en iyi uygulama değildir ve kullanımı tasarım sorunlarına yol açabilir. sql variant veri türü konu bütünlüğü sağlamak için burada listelenmiştir.

Aşağıdaki veri türleri tablolarda veya view’lardaki sütunlarında kullanılamaz; stored procedure’ler içerisinde değişken veya parametre olarak kullanılırlar:

Cursor veri türü, bir veri kümesinin satır satır işlenmesini sağlayan bir veri türüdür. Ayrıntısı bu bölümün kapsamı dışındadır.
Table veri türü, standart veri tabanı tablosunun özelliklerinin çoğuna sahip olan, ancak yalnızca oluşturulduğu oturum bağlamında var olan bir tablo değişkeni veya bir stored procedure parametresi tanımlamak için kullanılır. table veri türleri, daha sonra işlenmek üzere T-SQL ifadelerinin sonuçlarını geçici olarak depolamak için kullanılır. Bu yazı serisinin ilerleyen bölümlerinde table veri türünün kullanımları hakkında bilgi edineceksiniz.

Veri Türü Önceliği Sorgularınızdaki farklı veri türlerini birleştirirken veya karşılaştırırken (örneğin Where veya Join içerisinde), SQL Server’ın bir değerin veri türünü diğer değerin veri türüne dönüştürmesi gerekir. Hangi veri türünün dönüştürüleceği, ikisi arasındaki önceliğe bağlıdır. SQL Server’da, tüm veri türlerinin sıralaması önceliğe göredir. Herhangi iki veri türü kendi aralarında biri düşük önceliğe, diğeri yüksek önceliğe sahip olacaktır. Dönüştürme sırasında SQL Server, daha düşük veri türünü daha yüksek olan veri türüne dönüştürmeye çalışır. Tipik olarak bu işlem özel koda ihtiyaç duyulmadan örtülü (implicit) olarak gerçekleşir. Ancak bu veri tipi öncelik düzenini temel olarak anlamanız önemlidir, böylece veri türlerini birleştirmek veya dönüştürmek için ne zaman manuel olarak (explicit) dönüştürmeniz gerektiğini anlarsınız.

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim

SQL Server yedekleme(backup) ve geri yükleme(restore) bileşeni, SQL Server veritabanlarınızda depolanan kritik verileri korumak için temel bir koruma sağlar. SQL Server, bir veritabanı yönetim sistemi (DBMS) olduğundan, SQL Server yüklü bir sistemde birden fazla veritabanı bulunabilir. Bu veritabanları, işletmeler için önemli verileri içerir ve bu verilerin kaybedilmesi felaketle sonuçlanabilir. Bu nedenle, SQL Server’daki veritabanlarının yedeklenmesi çok önemlidir. Yıkıcı veri kaybı riskini en aza indirmek için, verilerinizde yapılan değişiklikleri düzenli olarak korumak için veritabanlarınızı yedeklemeniz gerekir. İyi planlanmış bir yedekleme ve geri yükleme stratejisi, veritabanlarının çeşitli hatalardan kaynaklanan veri kayıplarına karşı korunmasına yardımcı olur. Veritabanı yedeklemesi, bir veritabanının tüm verilerinin veya belirli bir kısmının başka bir depolama ortamına kopyalanmasıdır. Bu yedek kopya, veri kaybı yaşanması durumunda orijinal veritabanını geri yüklemek için kullanılabilir. Yedekleme işlemi, veritabanının boyutuna ve yedekleme yöntemine bağlı olarak uzun sürebilir. Ancak, veritabanının yedeklenmesi önemli bir işlem olduğundan, yedekleme sıklığı ve yöntemi iyi planlanmalı ve yedek kopyaların saklanacağı bir depolama alanı belirlenmelidir.

En iyi backup planı nasıl kurulur? Bizim için en iyi bakım planı, kurumun bakım planını destekleyebileceği şekilde backup almaktır. Kurumun bunun için yeterli disk alanı var mı? Database mimarisi ne durumda? AlwaysOn yapısı var mı? Yedekleme yapacağımız üçüncü bir disk alanı var mı? Geri dönüş senaryoları için test edilecek bir ortam var mı?… Bu gibi soruları ortamın gerekliliğini sorgulayarak bu kurulumları yapmak en sağlıklısı olacaktır. En iyi backup planı, bu bakım planlarının kurulacağı kurumların ihtiyaçlarına ve kurumun verilerinin önem düzeyinize göre değişiklik gösterir. Ancak, genel olarak en iyi backup planının aşağıdaki özelliklere sahip olması gerekir: 1. Sık ve düzenli yedekleme: Verilerinizin önemine göre, sık ve düzenli yedeklemeler yapılmalıdır. Bu, veri kaybı durumunda kayıp verileri en aza indirir. Mesela 15 dk da bir log backup almakla 4 saatte bir log backup almak arasında oldukça büyük bir fark vardır. Herhangi bir kesinti veya felaket sonucunda 4 saate kadar olan kurguda veri kaybı kaçınılmazdır. 2. Çoklu yedekleme türü: En iyi backup planı, tam(full), diferansiyel(diff) ve günlük(log) yedekleme gibi farklı yedekleme türlerini içermelidir. Bu, yedekleme işlemlerinin hızlı ve etkili bir şekilde gerçekleştirilmesini sağlar. Bizim için en iyi senaryo (önerebileceğimiz) haftada bir full backup, günlük diff backup ve her 15 dk da bir log backup almaktır. Ama tabii ki kurumların kritikliğine göre veri kaybını minimalize etmek için full backupları günlük olarak da alabilir haftalık olarak da alınabilir. Mesela veri giriş çıkışlarının (I/O)yoğunluğuna göre bu backup planları değişiklik gösterebilir. haftalık 1 full, Günlük 1 diff backup almak yerine Günde 1 full ve günde 2 diff alınarak olası bir felaket durumunda yedekten dönmek, sistemsel kesinti yaşanmaması ve Yıkıcı veri kaybı riskini en aza indirmeyi, verilerinizde yapılan değişiklikleri düzenli olarak korumak adına böyle bir senaryo oluşturulabilir. AlwaysOn’u olan ortamlarda ise backup alma önceliğini primaryden secondary makinaya vermemiz durumundaysa primary makineye gelen yük azaltılarak performans kayıpları önlenir, iş sürekliliği sağlanmış olur. 3. Güvenli depolama: Yedeklemelerinizi güvenli bir şekilde depolamanız gerekir. Depolama alanı, verilerinizin güvenliğini sağlamak için yedeklenen verilerin şifrelenmesini içermelidir. Diğer bir önemli noktaysa, AVG’de olan ortamda backuplar alınırken mevcut makine diski haricinde üçüncü bir disk ortamına sahip olunması ,ana makinenin herhangi bir felaket sonucu kaybedilmesi durumunda yedeği hızlı ve sağlam dönebilmek için değerlidir. Bu sayede olası geri dönüş senaryolarında zaman ve süreklilik kaybının önüne geçilir. 4. Doğrulama ve test etme: En iyi backup planı, yedeklenen verilerin doğruluğunu ve bütünlüğünü düzenli olarak test eder. Çıktı parametrelerinin tutulması ve geri dönüş senaryosu oluşturulması önemlidir. Böylece, yedekleme işlemlerinin başarılı olduğundan emin olunur. 5. Yedeklemelerin saklama süresi: Yedeklemelerin saklama süresi, yedeklemelerin düzenli olarak silinmesini ve depolama alanının gereksiz şekilde doldurulmamasını sağlar. Kurumların ihtiyaçlarına göre saklama süresi 1 hafta da olabilir, bir ay da. Burada önemli olan şey bahsettiğimiz gibi disk alanlarının gereğinden fazla doldurulmamasıdır. Bu sayede hız ve performanstan kayıp yaşamamış oluruz. Alınan yedeklerin boyutları zamanla büyüyeceği ve disk alanını dolduracağı için backupları “kompress backup” yöntemiyle tutmak, hem backup maliyeti açısından hem de hızlı backup almak açısından daha avantajlı olacaktır. (Compress backup konusuna başka bir makalede değinmiştik. İsterseniz bu linke tıklayarak okuyabilirsiniz. https://aryasoft.com/2023/04/25/compressbackup/) 6. Yedekleme işlemlerinin otomatikleştirilmesi: En iyi backup planı, yedekleme işlemlerinin otomatik olarak gerçekleştirilmesini içerir. Böylece, insan hatası veya unutulma nedeniyle yedekleme işlemlerinin atlanması engellenir. 7. Sağlıklı backup geri dönüşü (restore): Doğru yedekleme stratejisi, geri yükleme işleminin daha hızlı ve daha sorunsuz bir şekilde tamamlanmasına yardımcı olabilir. Ayrıca, geri yükleme sürecinin ne kadar süreceğini önceden yapılan testlerde çıkan parametrelerden çıkarım yaparak iş sürekliliği planlamasında yardımcı olabilirsiniz. Yukarıdaki özellikleri içeren bir backup planı kurarak verilerin güvenliği ve bütünlüğünü sağlayabilirsiniz. Ancak, verilerinizin önemi ve değişkenliği gibi faktörlere göre, backup planınızı düzenli olarak gözden geçirmeniz ve gerektiğinde güncellemeniz önemlidir. Son olarak backuplarınızın düzenli kontrolünü sağlayabileceğiniz scripti aşağıya bırakıyorum.

SELECT s.database_name, s.backup_start_date, CASE s.[type] WHEN ‘D’ THEN ‘Full’ WHEN ‘I’ THEN ‘Differential’ WHEN ‘L’ THEN ‘Transaction Log’ END AS BackupType, s.server_name FROM msdb.dbo.backupset s INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id WHERE s.backup_start_date > DATEADD(dd, -7, GETDATE()) and (s.type=’D’ OR s.type=’I’ OR s.type=’L’) ORDER BY backup_start_date DESC, backup_finish_date ASC GO

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim

Eğer bir veritabanı yöneticisiyseniz her gün işe başladığınızda en az 15 dakikanızı ayırarak rutin bir kontrol yapmanız önemlidir. Tabii bu süre kaç tane ortamı yönettiğinize ve yönettiğiniz sistemin yoğunluğuna göre değişebilir. Bu kısa süreli kontroller ay sonu raporlarınızı hazırlarken size büyük bir zaman ve performans artısı olarak geri dönmüş olur. Aşağıda rutin kontrolleri yapmanız gereken maddeleri ve açıklamalarını sizinle paylaşmış bulunmaktayım.

Düzenli Yedeklemeler (Backup): Günlük olarak backupların alınıp alınmadığını kontrol ederek başlayabiliriz. Bu kontrol veritabanınızın korunması ve olası veri kaybı senaryolarına karşı hazırlıklı olmanızı sağlar.
Disk Space kullanımını ve Drive Space Thresholds İzleme: Bu madde performans sorunlarını önlemek için önemlidir. Disk alanınızın yüzde 100’e ulaşması, bilgisayarınızın veya sunucunuzun performansını olumsuz yönde etkileyebilir. Disk alanı kullanımını izleyerek, sürücünüzün kapasitesinin sınırına yaklaştığını ve performans sorunlarının meydana gelebileceğini belirleyebilirsiniz. Günlük kontrol ederek sorunları önceden fark edip, çözümü için gerekli adımları atabilirsiniz.
Uzun Süre Çalışan Sorguları Ve Deadlockları İzleme: Uzun süren sorgular ve deadlocklar, veritabanı performansını olumsuz yönde etkileyebilecek önemli sorunlardır. Bu nedenle, bu sorunların erken tespit edilmesi ve çözülmesi, veritabanı sisteminin sağlıklı bir şekilde çalışmasını sağlamak için önemlidir. Bildiğiniz gibi uzun süren sorgular, veritabanı sunucusunu yavaşlatabilir ve diğer kullanıcıların sorgularını bekletir. Bu durum, kullanıcı deneyimini olumsuz yönde etkiler ve şirketin iş süreçlerine zarar verebilir. Ayrıca, uzun süren sorgular, veritabanı sunucusu üzerinde gereksiz yere yük oluşturur ve bu da donma ve çökme gibi daha ciddi sorunlara yol açabilir. Deadlocklar, veritabanı işlemlerinde bir dizi işlemi kilitleyen ve diğer işlemlerin aynı kaynaklara erişimini engelleyen bir durumdur. Bu durumda, bir işlem diğer işlemlere erişim izni vermez ve veritabanı sistemi tamamen durur. Bu da veritabanı sunucusu üzerinde ciddi bir performans düşüklüğüne ve hatta sistem çökmesine neden olabilir.Deadlocklar, genellikle veritabanı tasarımındaki hatalardan veya uygulama yazılımındaki hatalardan kaynaklanır ve bu nedenle erken tespit edilmeli ve çözülmelidir.
CPU ve Bellek Kullanımı Gibi Temel Performans Ölçümlerini İzleme: Rutininize bu adımı da eklemeniz önemli olacaktır. Bir veritabanı sisteminin CPU ve bellek kullanımı, sistem performansının en önemli göstergelerindendir. Yüksek CPU kullanımı, sunucunun aşırı yük altında olduğunu ve sorguların yavaşladığını veya hatta sistem çökmesine neden olabileceğini gösterir. Bu nedenle, CPU kullanımı gibi performans ölçümlerinin izlenmesi, veritabanı sistemindeki aşırı yük durumlarının tespit edilmesine ve önlenmesine yardımcı olur.
Blocking Hakkında İzleme ve Uyarı: Galiba bu madde bir veritabanı sistemi için en ciddi sorunlardan birisi olabilir. Bu sorunlar, birden fazla işlem veya sorgu arasında kaynaklar (kayıt, tablo, vb.) üzerinde çakışmalar yaşandığında ortaya çıkar. Bu durum, işlemleri veya sorguları yavaşlatabilir veya tamamen durdurabilir. Bloklama, bir işlemin diğer işlemlere erişimini engelleyen bir durumdur. Örneğin, bir işlem bir tabloyu kilitlediğinde, diğer işlemlerin aynı tabloya erişimi engellenir. Bu durum, bir işlem diğerlerini bekletir ve performansı ciddi şekilde etkiler. Bloklama sorunu, veritabanı sistemi üzerindeki işlem yükünün artmasıyla daha sık meydana gelir. Gerekli sorgu incelemelerinin yapılarak kill edilmesi veya gerekiyorsa bu sorgunun tekrardan düzenlenmesi için yetkili kişilerle konuşulması gerekmektedir.
Failed Jobs İzleme ve Uyarma : Başarısız işlemler, bir veritabanı sistemi veya uygulama yazılımında birçok farklı nedenle ortaya çıkabilir. Örneğin, bir veritabanı sistemi veya uygulama yazılımındaki bir hata, bir sunucu kesintisi veya bir ağ sorunu nedeniyle bir işlem başarısız olabilir. Bu nedenle, başarısız işlemlerin izlenmesi ve uyarıların alınması, veritabanı sistemi veya uygulama yazılımının sağlıklı bir şekilde çalışmasını sağlamak için önemlidir. Ayrıca, başarısız işlemlerin izlenmesi, gelecekte benzer sorunların önlenmesine yardımcı olabilir. Örneğin, bir işlem belirli bir veri kaynağına erişim sağlayamadığında başarısız olabilir. Bu tür bir sorunun izlenmesi ve çözülmesi, benzer sorunların gelecekteki işlemlerde tekrarlanmasını önleyebilir.
Başarısız Oturum Açma İşlemlerini (Failed Logins ) İzleme ve Uyarma: Bir DBA olarak sistemin güvenliğini sağlamak açısından Başarısız giriş denemelerini incelemek gerekir. Bu durum birinin sistem veya uygulamaya izinsiz erişmeye çalıştığını gösterebilir. Bu denemelerin izlenmesi ve uyarılmasıyla, IT ekipleri potansiyel güvenlik tehditlerini hızlı bir şekilde tespit edebilir ve önlemek için uygun önlemler alabilir. Bu başarısız giriş denemeleri aynı zamana kullanıcı deneyimlerini de etkileyen bir husustur. Kullanıcılar için sinir bozucu olabilir ve sistem veya uygulamaya olan güvenlerini kaybetmelerine neden olabilir. Bu olayların izlenmesi ve uyarılması, IT ekiplerinin sorunları proaktif olarak tespit etmelerine ve büyük sorunlar haline gelmeden önce bunları çözmelerine olanak tanır, böylece kullanıcı deneyimini artırır. Başarısız giriş denemelerinin izlenmesi ve uyarılması, sorun giderme amaçları için de faydalı olabilir. Kullanıcılar oturum açmakta zorluk yaşıyorlarsa, IT ekipleri sorunu hızlı bir şekilde tespit edebilir ve düzeltici önlem alarak süreyi en aza indirgeyebilir ve kullanıcılara olumsuz etkilerini azaltabilir.
Büyük Tabloların Büyümesini İzleme ve Uyarma: Veritabanındaki büyük tablolar, sorguların ve işlemlerin yavaşlamasına neden olurken aynı zamanda depolama kaynaklarını da tüketir. Büyük tabloların daha da büyümesi, veri bütünlüğünü de etkiler. Örneğin, bir tablonun çok büyük olması, yedekleme işlemlerinin uzun sürmesine ve yedekleme sırasında veri kaybına neden olabilir. Bu sorunların giderilmemesi performans kaybına neden olabilir. Bu da bizim istemediğimiz bir durum:) Günlük olarak kontrolleri sağlamakta fayda vardır.
Kullanıcılar, Roller ve Erişim Hakları Gibi Güvenlik Değişikliklerini İzleme ve Uyarma: Bu maddenin incelenmesi, veritabanı yöneticilerinin veritabanı güvenliği konusunda daha güvenli bir ortam oluşturmasına yardımcı olur. Bunun yanı sıra, belirli bir kullanıcının yanlışlıkla veya kötü niyetle yetkisi artırılmışsa, veritabanında veri manipülasyonu ve hatta veri kaybı riski oluşabilir. Bu nedenle, kullanıcılar, roller ve erişim haklarındaki herhangi bir değişikliğin izlenmesi ve uygun şekilde uyarılara dönüştürülmesi, veritabanı yöneticilerinin veri bütünlüğünü korumasına yardımcı olur. Ayrıca, veritabanı kullanıcılarının güvenliği ve gizliliği açısından, kullanıcı hesaplarının silinmesi veya erişim haklarının kısıtlanması gibi değişiklikler de izlenmelidir. Bu değişikliklerin izlenmesi, veritabanı yöneticilerinin kullanıcı hesaplarının güvenli bir şekilde yönetilmesine yardımcı olmasını sağlar. Sonuç olarak, kullanıcılar, roller ve erişim haklarının değiştirilmesi, veritabanı yöneticilerinin kontrolünde olmalı ve izlenmelidir. Bu sayede, veritabanı güvenliği, uyum, veri gizliliği ve bütünlüğü, kimlik avı ve iç tehditler gibi birçok konuda daha güvenli hale getirilir. Monitoring ve alerting işlemleri, bu konularda farkındalık yaratır ve olası tehditlerin önceden tespit edilmesine yardımcı olur.
Sunucu Ayarlarında ve Yapılandırmalarında Yapılan Değişiklikleri İzleme ve Uyarma: Veritabanı sunucuları, veritabanı sistemlerinin doğru ve verimli çalışması için bir dizi ayar ve yapılandırmaya sahiptir. Bu ayarlar, sunucunun donanım kapasitesi, işletim sistemi, veritabanı yazılımı ve ağ performansı gibi faktörlere göre belirlenir.Örneğin, belirli bir ayarın yanlış yapılandırılması, sunucunun verimli çalışmasını engelleyebilir veya veritabanı bütünlüğünü riske atabilir. Bu maddenin de günlük olarak incelenmesi gerekmektedir.
Replikasyon and Log Shipping Durumunu İzleme: Veritabanı yöneticileri, birincil sunucu ve ikincil sunucu arasında veri kopyalama işlemlerinin gerçekleştirildiği veri replikasyonu ve log gönderimi işlemlerinin durumunu izlemek isterler. Bu, veri bütünlüğünün korunmasını ve yedekleme işlemlerinin başarılı bir şekilde gerçekleştirilmesini sağlar.

Ayrıca, veri replikasyonu ve log gönderimi işlemleri sırasında, veri bütünlüğünün ve veri güvenliğinin korunmasına özen göstermek gereklidir. Monitoring ve alerting işlemleri, bu konuda da yardımcı olabilir. Örneğin, günlük dosyaları veya replikasyon işlemleri üzerinde yapılan herhangi bir değişiklik, otomatik olarak belirlenebilir ve veri bütünlüğünün korunması için gerekli önlemler alınabilir. Bu ölçümler, veritabanı performansındaki olası sorunları erken tespit etmek ve önlemek için kullanılabilir. Bu da, veritabanı sistemi üzerindeki iş yükünü azaltarak, kullanıcı deneyimini ve şirketin iş süreçlerini olumlu yönde etkiler. Tabii ki sizler de bu maddelerin sayısını arttırabilir veya kendi veritabanı ortamınıza göre düzenleme yapabilirsiniz.

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim

SQL SERVER HEALTH CHECK NEDİR ? SQL Server Health Check, SQL Server veritabanı yönetim sistemlerinin performansını ve güvenilirliğini değerlendirmek için kullanılan bir yöntemdir. Bu işlem, SQL Server sisteminin genel sağlık durumunu değerlendirmek ve olası sorunları tespit etmek için kullanılır. SQL SERVER HEALTH CHECK NİYE YAPILIR? SQL Server Health Check, bir SQL Server veritabanının performansını, güvenilirliğini ve genel sağlığını değerlendirmek ve geliştirmek için yapılan bir incelemedir. Bu inceleme, SQL Server’ın mevcut durumunu ve sorunlu alanlarını belirlemek için kullanılır. SQL Server Health Check, birçok nedenle yapılabilir. Örneğin:

Performans sorunları: Veritabanının yavaş çalışması, sorguların çok uzun sürmesi veya sunucunun yüksek CPU veya bellek kullanımı gibi performans sorunları varsa, bir Health Check yapmak faydalı olabilir.
Veritabanı güvenilirliği: Veritabanının yedekleme, geri yükleme ve felaket kurtarma gibi önemli işlemlerini yönetmek için yapılan kontrollerdir.
Genel sağlık durumu: SQL Server’ın genel sağlığı ile ilgili sorunlar varsa, örneğin, erişim sorunları veya yavaş yanıt süresi, Health Check bu sorunların nedenini belirlemek için yararlıdır.

Bir SQL Server Health Check, veritabanının tüm bileşenlerinin incelenmesini içerir. Sunucu donanımı, işletim sistemi, SQL Server yazılımı ve veritabanı yapılandırması dahil olmak üzere tüm bileşenler incelenir. Bu inceleme sonucunda elde edilen veriler, bir rapor halinde sunulur ve bu rapor, performans sorunlarını veya diğer sorunları çözmek için gereken adımları belirlemek için kullanılabilir.

HEALTH CHECK’İN İÇERİĞİ NEDİR ? SQL Server Health Check, veritabanının performansını, güvenilirliğini ve verimliliğini artırmak için bir dizi test, inceleme ve analiz içeren kapsamlı bir değerlendirme sürecidir. Health Check’in içeriği, aşağıdaki temel bileşenleri içerir:

Performans Analizi: Veritabanının performansını etkileyen faktörler incelenir ve performans sorunları tespit edilir. Bu aşamada, veritabanının yüksek erişimli işlemlerinin yanı sıra ağ trafiği ve donanım kullanımı gibi diğer faktörler de incelenir.
Güvenlik Analizi: Veritabanının güvenliği incelenir ve güvenlik açıkları tespit edilir. Bu aşamada, veritabanının kullanıldığı yerlerdeki güvenlik standartlarına uygun olup olmadığı kontrol edilir.
Yedekleme ve Kurtarma Analizi: Veritabanının yedekleme ve kurtarma süreçleri incelenir ve veritabanının tamamen kurtarılabilmesi için gereken adımlar analiz edilir. Bu aşamada, yedekleme stratejileri, yedekleme planları, veri kaybı riskleri, kurtarma süreleri gibi faktörler incelenir.
İyileştirme Önerileri: Veritabanının performansını artırmak, güvenliğini sağlamak ve verimliliğini artırmak için öneriler sunulur. Bu aşamada, öneriler, donanım ve yazılım yükseltmeleri, yapılandırma değişiklikleri, güvenlik önlemleri, yedekleme stratejileri gibi konuları içerir.
Raporlama: Health Check sonuçları, detaylı bir rapor şeklinde sunulur. Bu rapor, veritabanının performansını, güvenilirliğini ve verimliliğini artırmak için alınabilecek aksiyonları ve iyileştirme önerilerini içerir.

Bu bileşenler, SQL Server Health Check’in temel içeriğini oluşturur. Ancak, bazı durumlarda ekstra testler ve analizler de yapılabilir. Health Check, veritabanının özelliklerine ve ihtiyaçlarına göre özelleştirilebilir.

HEALTH CHECK HANGİ SIKLIKLA YAPILMALI? SQL Server Health Check’in ne kadar sıklıkla yapılması gerektiği, veritabanının ihtiyaçlarına ve kullanım sıklığına bağlı olarak değişebilir. Aşağıdaki faktörler, Health Check’in sıklığını belirlemek için göz önünde bulundurulması gereken önemli faktörlerdir:

Veritabanının Boyutu ve Karmaşıklığı: Veritabanı büyüdükçe ve daha karmaşık hale geldikçe, Health Check yapılması daha sık gerekli olabilir. Veritabanı boyutu ve karmaşıklığı, veritabanının performansı, güvenliği ve verimliliği üzerindeki etkileri nedeniyle Health Check’in sıklığını belirleyebilir.
İş Yükü: Veritabanı üzerindeki iş yükü arttıkça, veritabanının performansı, güvenliği ve verimliliği de etkilenebilir. Bu nedenle, iş yüküne bağlı olarak Health Check yapılması gerekebilir.
Yeni Sürümlere Geçiş: Yeni bir SQL Server sürümüne geçiş yapmak, veritabanının performansını, güvenliğini ve verimliliğini artırabilir. Bu nedenle, yeni bir SQL Server sürümüne geçiş yaptıktan sonra Health Check yapılması önerilir.
Mevzuat ve Uyumluluk Gereksinimleri: Bazı sektörlerde, veritabanı işletmelerinin belirli mevzuat ve uyumluluk gereksinimlerine uymaları gerekmektedir. Bu gereksinimler, Health Check’in sıklığını etkileyebilir.

Genel olarak, veritabanının ihtiyaçlarına ve kullanım sıklığına bağlı olarak, Health Check yılda bir veya iki kez yapılması önerilir. Ancak, yukarıda belirtilen faktörlere bağlı olarak, bu sıklık daha sık veya daha seyrek olabilir. FİRMALAR BU HİZMETTEN NEDEN FAYDALANMAK İSTER? Firmalar SQL Server Health Check hizmetinden faydalanmak isterler çünkü bu hizmet, işletmelerin veritabanı performansını artırmak, güvenliği sağlamak ve daha verimli hale getirmek için önemli bir araçtır. Ayrıca, işletmeler, SQL Server Health Check hizmetinden faydalanarak aşağıdaki faydaları elde edebilirler:

Performans Sorunlarının Tespit Edilmesi: SQL Server Health Check, veritabanındaki performans sorunlarını tespit ederek bunları çözmeye yardımcı olur. Bu sayede, veritabanının performansı artırılarak müşteri memnuniyeti artırılabilir.
Güvenlik Açıklarının Tespit Edilmesi: SQL Server Health Check, veritabanındaki güvenlik açıklarını tespit ederek riskleri azaltmaya yardımcı olur. Bu sayede, verilerin güvenliği sağlanır ve işletme itibarı korunur.
İyileştirme Önerileri Sunulması: SQL Server Health Check, veritabanının daha verimli hale getirilmesi için iyileştirme önerileri sunar. Bu sayede, veritabanının performansı artırılır ve işletme maliyetleri düşürülür.
Yedekleme ve Kurtarma İşlemlerinin Etkin Hale Getirilmesi: SQL Server Health Check, yedekleme ve kurtarma işlemlerinin daha etkin hale getirilmesine yardımcı olur. Bu sayede, veri kaybı riski azaltılır ve iş sürekliliği sağlanır.
Sorunların Erken Tespit Edilmesi: SQL Server Health Check, veritabanındaki sorunları erken tespit ederek bunların çözülmesine yardımcı olur. Bu sayede, sorunlar büyümeden önlenebilir ve işletmenin veritabanı daha az arıza verir.

Bu nedenlerden dolayı, işletmeler SQL Server Health Check hizmetinden faydalanarak veritabanı performansını artırabilir, güvenliği sağlayabilir ve daha verimli hale getirebilirler. MÜŞTERİLERİN BEKLENTİSİ NEDİR ? Müşterilerin beklentileri, SQL Server Health Check hizmetinin sunacağı faydaları içerir. Müşteriler genellikle veritabanlarının daha yüksek performans, daha yüksek güvenlik, daha yüksek verimlilik ve daha yüksek uygunluk sağlamasını istemektedirler. SQL Server Health Check, veritabanının bu hedeflere ulaşmasına yardımcı olacak aksiyonları belirler ve müşterilere detaylı bir rapor sunar. Bu rapor, iyileştirme önerileri ve aksiyon planları içerir. Müşteriler, bu önerileri uygulayarak veritabanlarının performansını artırabilir, veritabanlarına yönelik güvenlik tehditlerini azaltabilir, veritabanlarının daha verimli çalışmasını sağlayabilir ve uyumluluk gereksinimlerini karşılayabilir. Müşterilerin beklentileri genellikle, veritabanlarının iş süreçlerinin etkin bir şekilde yürütülmesine yardımcı olacak şekilde iyileştirilmesi yönündedir. HEALTH CHECK ‘TE MÜŞTERİLERE HANGİ HİZMETLERİ SUNUYORUZ ? SQL Server Health Check, müşterilere aşağıdaki hizmetleri sunar:

Veritabanı Performans Analizi: Veritabanının performansını analiz ederek, performans sorunlarını tespit eder ve bunları çözmek için öneriler sunar. Bu hizmet, veritabanının daha hızlı çalışmasını ve daha iyi yanıt vermesini sağlayabilir.
Güvenlik Analizi: Veritabanının güvenliğini analiz ederek, güvenlik açıklarını tespit eder ve bunları çözmek için öneriler sunar. Bu hizmet, veritabanının daha güvenli hale gelmesini sağlayabilir.
Veritabanı Yedekleme ve Kurtarma Analizi: Veritabanı yedekleme ve kurtarma stratejilerini analiz ederek, yedekleme ve kurtarma işlemlerindeki sorunları tespit eder ve bunları çözmek için öneriler sunar. Bu hizmet, veritabanının yedekleme ve kurtarma süreçlerinin daha güvenli ve daha verimli olmasını sağlayabilir.
Veritabanı Uyumluluk Analizi: Veritabanının mevzuat ve uyumluluk gereksinimlerine uygun olup olmadığını analiz ederek, uyumluluk sorunlarını tespit eder ve bunları çözmek için öneriler sunar. Bu hizmet, veritabanının uyumluluk gereksinimlerini karşılamasını sağlayabilir.
Genel Veritabanı Analizi: Veritabanının genel durumunu analiz ederek, veritabanı yönetimini geliştirmek için öneriler sunar. Bu hizmet, veritabanının daha verimli ve daha etkili bir şekilde yönetilmesini sağlayabilir.

SQL Server Health Check, müşterilere veritabanlarının performansını, güvenliğini, uyumluluğunu ve yönetimini iyileştirmeleri için öneriler sunarak, veritabanı yönetimini geliştirmelerine yardımcı olur.

Size ve Veritabanlarınıza Yardımcı Olmak İçin Bekliyoruz!

İletişime geçerek hemen destek alabilirsiniz.

İletişim