Takip et

Azure SQL’de Gizli Cevherler: Bilmeniz Gereken Komutlar ve Fonksiyonlar

Azure SQL Veritabanı, bulut ortamında yönetilen, yüksek performanslı ve ölçeklenebilir bir veri çözümüdür. Peki, bu gücün tamamını kullandığınızdan emin misiniz? Çoğu geliştirici ve veritabanı yöneticisi, Azure SQL’in sunduğu standart T-SQL özelliklerine aşina olsa da, gözden kaçan bazı komutlar, fonksiyonlar ve anahtar kelimeler, performansınızı artırmanın, maliyetlerinizi düşürmenin ve güvenliği sağlamanın anahtarı olabilir. Bu makalede, Azure SQL’deki bu “gizli cevherleri” keşfedecek, gerçek dünya senaryolarıyla destekleyerek, veritabanı yönetim deneyiminizi bir üst seviyeye taşıyacağız.

Günümüzün hızla değişen dijital dünyasında, işletmelerin veri depolama ve işleme ihtiyaçları sürekli olarak artmaktadır. Bu noktada, Microsoft Azure SQL Veritabanı, yönetilen bir hizmet (PaaS) olarak sunduğu avantajlarla öne çıkmaktadır. Geleneksel şirket içi veritabanı yönetiminin getirdiği altyapı maliyetleri, bakım yükü ve ölçeklenebilirlik kısıtlamaları, Azure SQL ile ortadan kalkmaktadır. Veritabanınızın donanım, işletim sistemi yamaları, yedekleme ve yüksek erişilebilirlik gibi kritik görevleri Azure tarafından otomatik olarak yönetilirken, siz çekirdek işinize odaklanabilirsiniz. Ancak bu kolaylık, bazen Azure SQL’in kendine özgü dinamiklerini ve sunduğu özel araçları göz ardı etmemize neden olabilir. Standart SQL Server’a kıyasla farklılık gösteren yönetim görünümleri, otomatik ayarlama yetenekleri ve bulut tabanlı güvenlik özellikleri, bilinçli kullanılmadığında tam potansiyeline ulaşamayabilir.

Bu makalede ele alacağımız “gizli cevherler”, veritabanı performansınızı optimize etmekten, olası güvenlik açıklarını kapatmaya, beklenmedik maliyet artışlarını engellemeye ve günlük operasyonları kolaylaştırmaya kadar geniş bir yelpazeyi kapsar. Örneğin, bir startup düşünün. Geleneksel bir SQL Server altyapısı kurmak yerine Azure SQL’i tercih ettiler. Başlangıçta her şey yolundaydı, ancak kullanıcı sayısı arttıkça ve veri hacmi genişledikçe, uygulamada gecikmeler yaşanmaya başladı. Veritabanı sunucusunun kaynak tüketimi normal görünüyordu, fakat sorguların yavaş çalıştığı gözlemleniyordu. Geliştirme ekibi, temel SQL sorgu performans iyileştirmelerini denese de, sorunun kök nedenini bulmakta zorlandı. İşte tam bu noktada, Azure SQL’e özel Dinamik Yönetim Görünümleri (DMV’ler) ve otomatik ayarlama özellikleri devreye girdi. Bu araçlar sayesinde, en pahalı sorguların belirlenmesi, eksik indeks önerilerinin alınması ve hatta Azure’un kendi yapay zekasının performans sorunlarını otomatik olarak gidermesi mümkün oldu. Bu sayede, startup hem müşteri memnuniyetini artırdı hem de altyapı için harcayacağı zamanı ürün geliştirmeye ayırdı.

Azure SQL’in bulut doğası, sürekli izleme ve optimizasyon gerektirse de, doğru komut ve fonksiyon setine hakim olmak bu süreci büyük ölçüde basitleştirir. Bu özellikler, yalnızca sorun giderme anlarında değil, aynı zamanda proaktif olarak veritabanı sağlığını izlemek, güvenlik duruşunu güçlendirmek ve maliyetleri verimli bir şekilde yönetmek için de kritik öneme sahiptir. Bu bağlamda, Azure SQL’in sunduğu her bir aracın ne işe yaradığını ve hangi senaryolarda kullanılması gerektiğini anlamak, bulut veritabanı yönetimindeki başarınızın temelini oluşturacaktır. Unutmayın, Azure SQL bir PaaS hizmeti olsa da, optimal performans ve maliyet verimliliği için aktif yönetim ve bilgi birikimi vazgeçilmezdir. Dolayısıyla, bu “gizli cevherleri” öğrenmek, yalnızca mevcut sorunları çözmekle kalmayacak, aynı zamanda gelecekteki potansiyel problemlere karşı da sizi hazırlayacaktır.

Performans Optimizasyonu İçin Hangi Komutları Kullanmalıyız?

Veritabanı performansı, herhangi bir uygulamanın kullanıcı deneyimi için kritik öneme sahiptir. Azure SQL’de performans darboğazlarını tespit etmek ve gidermek için standart SQL Server araçlarının yanı sıra, bulut ortamına özel Dinamik Yönetim Görünümleri (DMV’ler) ve indeksleme stratejileri büyük fark yaratır. Bu bölümde, veritabanınızın derinliklerine inerek performans sorunlarının kök nedenlerini bulmanıza yardımcı olacak bazı güçlü komutları ve teknikleri inceleyeceğiz.

Dinamik Yönetim Görünümleri (DMV’ler) ile Performansı İzlemek Nasıl Yapılır?

DMV’ler, SQL Server’ın mevcut durumu hakkında sistem bilgileri sağlayan sanal tablolardır. Azure SQL’de, sunucuya ve veritabanına özel DMV’ler bulunur ve bunlar, çalışan sorgular, oturumlar, disk G/Ç, bellek kullanımı ve daha fazlası hakkında değerli bilgiler sunar. En sık kullanılan ve en faydalı DMV’lerden bazıları şunlardır:

  • sys.dm_exec_requests: Şu anda sunucuda çalışan tüm istekleri listeler. Uzun süren sorguları, blokajları (blocking) ve o anki durumu (status) belirlemek için idealdir.
  • sys.dm_exec_sessions: Tüm aktif kullanıcı oturumlarını ve her oturumun kullandığı kaynakları gösterir. Belirli bir kullanıcının veya uygulamanın veritabanı üzerindeki etkisini anlamak için faydalıdır.
  • sys.dm_exec_query_stats: Ön belleğe alınmış (cached) tüm sorguların performans istatistiklerini içerir. En çok kaynak tüketen (CPU, G/Ç) sorguları bulmak için mükemmel bir kaynaktır.
  • sys.dm_os_wait_stats: SQL Server’ın hangi kaynakları beklediğini gösterir. Bu, performans sorunlarının temel nedenini (disk G/Ç, kilitlenmeler, bellek vb.) anlamanıza yardımcı olur.

Vaka Analizi: E-ticaret Sitesinde Checkout Yavaşlaması

Bir e-ticaret sitesi, özellikle indirim dönemlerinde, ödeme (checkout) sayfasında ciddi yavaşlamalar yaşıyordu. Müşteriler sepetlerini tamamlamakta zorlanıyor, bu da satış kayıplarına yol açıyordu. Geliştirme ekibi, sorunun veritabanında olduğunu düşünüyordu ancak nereden başlayacaklarını bilemiyorlardı. İlk adım olarak, sys.dm_exec_requests ve sys.dm_exec_query_stats DMV’leri kullanılarak yoğun saatlerde veritabanı izlendi. Şu sorguyu çalıştırarak en uzun süren aktif istekler listelendi:


SELECT
    s.session_id,
    r.status,
    r.command,
    r.start_time,
    DATEDIFF(MILLISECOND, r.start_time, GETDATE()) AS elapsed_time_ms,
    r.sql_handle,
    t.text AS query_text
FROM
    sys.dm_exec_requests r
INNER JOIN
    sys.dm_exec_sessions s ON r.session_id = s.session_id
OUTER APPLY
    sys.dm_exec_sql_text(r.sql_handle) t
WHERE
    s.is_user_process = 1
ORDER BY
    elapsed_time_ms DESC;
    

Bu sorgu, ödeme sayfasından gelen bir sorgunun (UPDATE işlemi) beklenenden çok daha uzun sürdüğünü ortaya koydu. Ardından, sys.dm_exec_query_stats kullanılarak bu sorgunun detaylı performans geçmişi incelendi ve sorgunun yoğun bir tablo üzerinde uygun olmayan bir indeksle çalıştığı anlaşıldı. Bu, bizi bir sonraki konumuza, indeks yönetimine götürüyor.

İndeks Yönetimi ve Eksik İndeksleri Bulma

İndeksler, veritabanı performansının temel taşlarından biridir. Doğru indeksler sorgu hızını katlayabilirken, eksik veya yanlış indeksler ciddi yavaşlamalara neden olabilir. Azure SQL, eksik indeksleri tespit etmenize yardımcı olacak güçlü DMV'lere sahiptir:

  • sys.dm_db_missing_index_details: Sorguların fayda sağlayabileceği eksik indekslerin detaylarını (tablo adı, sütunlar) verir.
  • sys.dm_db_missing_index_groups: Eksik indeks gruplarını ve bu indeks gruplarına dahil olan indekslerin sayısını gösterir.
  • sys.dm_db_missing_index_columns: Eksik indeksin hangi sütunları içermesi gerektiğini belirtir.

Yukarıdaki e-ticaret örneğinde, ödeme sayfasındaki yavaşlamaya neden olan sorgunun, Siparisler tablosundaki Durum ve KullaniciID sütunları üzerinde indekslenmediği ortaya çıktı. Şu sorguyu kullanarak eksik indeks önerileri kolayca bulunabilir:


SELECT
    migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) AS estimated_impact,
    mid.statement AS table_name,
    mid.equality_columns,
    mid.inequality_columns,
    mid.included_columns,
    migs.unique_compiles,
    migs.last_user_seek,
    'CREATE INDEX IX_' + OBJECT_NAME(mid.object_id) + '_' + REPLACE(REPLACE(REPLACE(ISNULL(mid.equality_columns, '') + ISNULL(mid.inequality_columns, ''), '[', ''), ']', ''), ', ', '_') + ' ON ' + mid.statement + ' (' + ISNULL(mid.equality_columns, '') + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ', ' ELSE '' END + ISNULL(mid.inequality_columns, '') + ')' + CASE WHEN mid.included_columns IS NOT NULL THEN ' INCLUDE (' + mid.included_columns + ')' ELSE '' END AS create_index_statement
FROM
    sys.dm_db_missing_index_groups migs
INNER JOIN
    sys.dm_db_missing_index_details mid ON migs.index_handle = mid.index_handle
ORDER BY
    estimated_impact DESC;
    

Uzman İpucu: Eksik indeks DMV'leri, size bir CREATE INDEX ifadesi bile sağlayabilir! Ancak, her öneriyi körü körüne uygulamayın. Mevcut indekslerinizi, yazma performansını ve depolama alanını göz önünde bulundurarak dikkatlice değerlendirin. Çok fazla indeks, yazma işlemlerini yavaşlatabilir.

Bu sorgu ile üretilen CREATE INDEX ifadesi çalıştırıldıktan sonra, e-ticaret sitesinin ödeme sayfasındaki performans sorunları büyük ölçüde giderildi. Azure SQL'in sunduğu Otomatik Ayarlama (Automatic Tuning) özelliği de bazı indeks oluşturma ve sorgu planı düzeltmelerini otomatik olarak yapabilir, ancak karmaşık senaryolarda manuel müdahale hala gereklidir. Bu, Azure SQL'deki gizli cevherlerin sadece performans izleme değil, aynı zamanda proaktif iyileştirme için ne kadar önemli olduğunu göstermektedir.

Veritabanı Sağlığını İzlemek İçin Kullanışlı Fonksiyonlar Nelerdir?

Veritabanı sağlığını sürekli olarak izlemek, potansiyel sorunları proaktif bir şekilde tespit etmenin ve sistemin genel istikrarını sağlamanın anahtarıdır. T-SQL, bu amaçla kullanabileceğiniz bir dizi güçlü fonksiyon ve komut sunar. Bu bölümde, veriler üzerinde daha anlamlı işlemler yapmanızı sağlayacak, raporlama ve bakım süreçlerinizi kolaylaştıracak bazı temel ama çok işlevsel T-SQL araçlarına odaklanacağız.

Zaman Serisi Analizi ve Veri Manipülasyonu için Fonksiyonlar

Veritabanı işlemleri genellikle zaman damgaları ile ilişkilidir. Verilerin ne zaman oluşturulduğu, güncellendiği veya silindiği bilgisi, performansı, log analizi ve raporlamayı anlamak için hayati öneme sahiptir. DATEADD ve DATEDIFF gibi fonksiyonlar, zaman serisi verileriyle çalışırken vazgeçilmezdir:

  • DATEADD (datepart, number, date): Belirtilen tarihe belirli bir zaman aralığı (yıl, ay, gün, saat vb.) ekler. Örneğin, bir ay sonraki tarihi bulmak veya 15 dakika sonraki bir zamanı hesaplamak için kullanılır.
  • DATEDIFF (datepart, startdate, enddate): İki tarih arasındaki belirtilen zaman aralığının (yıl, ay, gün, saat vb.) farkını döndürür. Örneğin, iki işlem arasındaki süreyi saniye cinsinden bulmak için kullanılır.

Bu fonksiyonlar, örneğin, son 24 saatteki başarısız giriş denemelerini saymak veya belirli bir işlemi tamamlamanın ortalama ne kadar sürdüğünü hesaplamak gibi senaryolarda kritik rol oynar. Ayrıca, GETDATE() ve GETUTCDATE() gibi fonksiyonlar, mevcut zamanı almak için kullanılır ve zaman serisi analizinin temelini oluşturur.

Koşullu Mantık ve Veri Formatlama

Daha temiz ve okunabilir sorgular yazmak için IIF ve CHOOSE gibi koşullu mantık fonksiyonları oldukça faydalıdır:

  • IIF (boolean_expression, true_value, false_value): Basit bir boolean ifadeye dayalı olarak iki değerden birini döndürür. CASE ifadesinin daha kısa bir versiyonu gibidir.
  • CHOOSE (index, val1, val2, ..., valN): Bir indeks değerine göre listeden bir öğe seçer. Özellikle sabit seçenek listelerinden bir değer seçmek gerektiğinde kullanışlıdır.
  • FORMAT (value, format_string [, culture]): Sayısal, tarih/saat veya diğer türdeki değerleri belirli bir format string'ine göre biçimlendirir. Raporlamada çıktıların düzenlenmesi için idealdir. Örneğin, bir tarihi 'yyyy-MM-dd HH:mm:ss' formatında göstermek için kullanılabilir.

Vaka Analizi: Bankacılık Uygulamasında Log Temizliği ve Raporlama

Bir bankacılık uygulaması, güvenlik denetimi için çok sayıda işlem logu üretiyordu. Bu loglar hızla büyüyor, depolama maliyetlerini artırıyor ve sorgu performansını düşürüyordu. Aynı zamanda, haftalık olarak son 7 günün özet raporlarını çıkarmaları gerekiyordu.


-- Yedi günden eski logları temizle
DELETE FROM [AuditLogs]
WHERE LogDate < DATEADD(DAY, -7, GETDATE());

-- Veya, eğer tablo tamamen temizlenecek ve indeksler yeniden oluşturulacaksa, daha hızlı bir yol:
-- TRUNCATE TABLE [OldAuditLogsTable]; -- Eğer tüm tabloyu temizliyorsak ve log tablosunu rotate ediyorsak.
    

Yukarıdaki kod bloğunda DATEADD ve GETDATE() fonksiyonları kullanılarak eski loglar silinmiştir. Eğer log tablosu zaman zaman tamamen boşaltılıp yeniden dolduruluyorsa, TRUNCATE TABLE komutu DELETE komutundan çok daha performanslıdır. TRUNCATE TABLE, tablonun tüm satırlarını hızlı bir şekilde kaldırır ve işlem logu boyutunu minimumda tutar, ancak WHERE koşuluyla kullanılamaz ve geri alınamaz bir işlemdir. DELETE ise her satırı tek tek siler ve işlem logunu daha fazla kullanır, ancak belirli koşullara uyan satırları hedefleyebilir.

Raporlama tarafında ise, FORMAT fonksiyonu ile tarih ve saat bilgileri okunabilir hale getirildi ve IIF ile işlemlerin başarı durumları görsel olarak daha net bir şekilde sunuldu.


SELECT
    FORMAT(LogDate, 'yyyy-MM-dd HH:mm:ss') AS IslemZamani,
    KullaniciAdi,
    IslemTipi,
    IIF(IslemBasarili = 1, 'Başarılı', 'Başarısız') AS Durum,
    Mesaj
FROM
    [AuditLogs]
WHERE
    LogDate >= DATEADD(DAY, -7, GETDATE());
    

String İşleme ve JSON Fonksiyonları

Modern uygulamalar sıkça JSON verisiyle çalışır. Azure SQL, JSON verilerini sorgulamak ve manipüle etmek için güçlü dahili fonksiyonlar sunar:

  • STRING_SPLIT (string, separator): Bir string ifadeyi belirli bir ayırıcıya göre böler ve her bir parçayı ayrı bir satır olarak döndürür. Etiketler veya virgülle ayrılmış listeler gibi verilerle çalışırken çok kullanışlıdır.
  • JSON_VALUE (expression, path): Bir JSON string'inden belirli bir yolu kullanarak skaler bir değeri ayıklar.
  • JSON_QUERY (expression, path): Bir JSON string'inden belirli bir yolu kullanarak bir JSON nesnesi veya dizisi ayıklar.
  • FOR JSON PATH veya FOR JSON AUTO: SQL sorgu sonuçlarını doğrudan JSON formatına dönüştürür, bu da API geliştirme süreçlerini basitleştirir.

-- Virgülle ayrılmış bir listeyi parçala
SELECT value FROM STRING_SPLIT('Elma,Armut,Kiraz', ',');

-- JSON içinden değer oku
SELECT JSON_VALUE('{"isim": "Ayşe", "yas": 30}', '$.isim') AS Adi;

-- Sorgu sonucunu JSON olarak formatla
SELECT id, ad, soyad FROM Kullanicilar FOR JSON PATH;
    

Bu fonksiyonlar, veritabanı üzerindeki operasyonları basitleştirmekle kalmaz, aynı zamanda daha esnek ve güçlü veri işleme yetenekleri sağlar. Özellikle raporlama ve entegrasyon senaryolarında, doğru fonksiyonları bilmek size önemli zaman kazandıracaktır. Bu araçlar, veritabanı sağlığınızı izlemekten, verileri temizlemeye ve anlamlı hale getirmeye kadar geniş bir yelpazede size yardımcı olacaktır.

Güvenlik ve Yönetimde Azure SQL'in Gizli Silahları Nelerdir?

Veritabanı güvenliği, herhangi bir işletme için en üst düzeyde önceliklidir, özellikle de hassas verilerle çalışılıyorsa. Azure SQL, yerleşik olarak birçok gelişmiş güvenlik özelliği sunar ancak bunların tam potansiyelini kullanmak, doğru komutları ve teknikleri bilmeyi gerektirir. Yönetim tarafında ise, otomasyon ve kaynak izleme, operasyonel yükü hafifletirken verimliliği artırır. Bu bölümde, Azure SQL'in güvenlik ve yönetimdeki "gizli silahlarını" keşfedeceğiz.

Veri Güvenliğini Artıran Özellikler: Always Encrypted, DDM ve RLS

Azure SQL, verilerinizin yetkisiz erişimden korunması için üç temel mekanizma sunar:

  • Always Encrypted (Her Zaman Şifreleme): Bu özellik, verilerin hassasiyeti ne olursa olsun, istemci tarafında şifrelenmesini sağlar. Veritabanı yöneticileri (DBA'ler) veya bulut operatörleri bile şifrelenmiş verilere erişemez, bu da veri sızıntılarına karşı üst düzey bir koruma sağlar. Şifreleme anahtarları müşteri kontrolünde kalır. Bu, özellikle sağlık ve finans gibi düzenlemelere tabi sektörler için vazgeçilmezdir.
  • Dynamic Data Masking (DDM - Dinamik Veri Maskeleme): DDM, hassas verileri yetkisiz kullanıcılara ifşa etmeden maskeleyerek korur. Örneğin, bir kullanıcının e-posta adresinin yalnızca bir kısmını göstermek (örneğin, a***@example.com) veya bir kredi kartı numarasının son dört hanesini göstermek gibi senaryolarda kullanılır. Veritabanında veri gerçek haliyle saklanır, ancak yetkisiz kullanıcılar yalnızca maskelenmiş bir görünüm görür. Bu, uygulamalarda herhangi bir değişiklik yapmadan kolayca uygulanabilir.
  • Row-Level Security (RLS - Satır Düzeyinde Güvenlik): RLS, bir veritabanı kullanıcısının erişebileceği satırları (kayıtları) kontrol etmenizi sağlar. Örneğin, bir satış temsilcisi yalnızca kendi satış verilerini görebilirken, yöneticisi tüm ekibin verilerini görebilir. Bu, uygulamanızın güvenlik katmanını basitleştirir ve veri erişimini çok daha hassas bir şekilde yönetmenizi sağlar.

Vaka Analizi: Sağlık Verileri Uygulamasında KVKK Uyumluluğu

Bir sağlık hizmetleri sağlayıcısı, hasta verilerini depolayan Azure SQL veritabanı üzerinde KVKK (Kişisel Verilerin Korunması Kanunu) uyumluluğunu sağlamak zorundaydı. Bu, hasta bilgilerinin gizliliğini ve erişimini sıkı bir şekilde kontrol etmeyi gerektiriyordu. Çözüm olarak DDM ve RLS entegrasyonu yapıldı:


-- Dinamik Veri Maskeleme örneği (e-posta adreslerinin bir kısmını gizle)
ALTER TABLE Hastalar
ADD MASKED WITH (FUNCTION = 'email()') (EmailAdres);

-- Satır Düzeyinde Güvenlik örneği (Doktorlar sadece kendi hastalarını görebilir)
CREATE FUNCTION [dbo].[fn_RLS_HastaErisimi](@DoktorID AS int)
RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS fn_RLS_HastaErisimi_Result
    WHERE @DoktorID = CAST(SESSION_CONTEXT(N'current_user_id') AS int);
GO

CREATE SECURITY POLICY [RLS.HastaErisimiPolicy]
ADD FILTER PREDICATE [dbo].[fn_RLS_HastaErisimi](DoktorID)
ON dbo.Hastalar
WITH (STATE = ON, SCHEMABINDING = OFF);
GO
    

Bu entegrasyon sayesinde, sağlık verileri uygulamasında hastaların e-posta adresleri otomatik olarak maskelenirken, her doktor yalnızca kendisine atanmış hastaların kayıtlarına erişebildi. Bu, hem güvenlik ihlali riskini azalttı hem de KVKK uyumluluğunu sağladı. Always Encrypted ise, çok daha hassas veriler (örneğin, TC Kimlik Numaraları) için devreye alınarak veritabanı seviyesinde ek bir koruma katmanı oluşturdu.

Azure Logic Apps/Automation ile Yönetim ve Otomasyon

Azure SQL'i yönetmek sadece manuel komutlar çalıştırmakla sınırlı değildir. Azure'ın sunduğu otomasyon araçları, rutin görevleri otomatikleştirerek DBA'lerin ve geliştiricilerin yükünü hafifletir:

  • Azure Logic Apps: Bu sunucusuz hizmet, farklı sistemler arasında iş akışları oluşturmanızı sağlar. Azure SQL ile entegrasyonu sayesinde, veritabanında bir değişiklik olduğunda (örneğin, yeni bir kayıt eklendiğinde) otomatik olarak e-posta göndermek, bir dış API'yi tetiklemek veya başka bir Azure hizmetini çalıştırmak mümkündür. Örneğin, performans kritik bir sorgu belirli bir eşiği aştığında uyarı göndermek için kullanılabilir.
  • Azure Automation: PowerShell runbook'ları veya Python script'leri kullanarak Azure kaynakları üzerinde tekrarlayan görevleri otomatikleştirmenizi sağlar. Azure SQL veritabanları için düzenli bakım görevlerini (indeks yeniden düzenleme, istatistik güncelleme), veritabanı ölçeklendirme işlemlerini veya periyodik veri temizleme işlerini otomatikleştirmek için idealdir.

-- Azure Automation ile çalıştırılabilecek basit bir indeks yeniden düzenleme script'i
ALTER INDEX ALL ON [dbo].[TabloAdi] REORGANIZE;
-- Alternatif olarak, daha büyük parçalanma durumlarında REBUILD:
-- ALTER INDEX ALL ON [dbo].[TabloAdi] REBUILD WITH (ONLINE = ON);
    

Uzman İpucu: Azure portalında "Automatic Tuning" özelliğini etkinleştirmek, bazı indeks ve sorgu planı optimizasyonlarını sizin için otomatik olarak halleder. Ancak, karmaşık iş yükleri için manuel müdahaleler veya Azure Automation ile özel script'ler çalıştırmak hala önemlidir.

Bu otomasyon araçları, Azure SQL'in operasyonel yönetimini daha verimli hale getirir. Periyodik görevlerin manuel müdahale olmaksızın çalışmasını sağlayarak insan hatası riskini azaltır ve veritabanı yöneticilerinin daha stratejik görevlere odaklanmasına olanak tanır. Güvenlik tarafında ise, bu otomasyonlar güvenlik denetimlerini veya politika kontrollerini düzenli olarak çalıştırmak için de kullanılabilir, böylece veritabanınızın her zaman güncel güvenlik standartlarına uygun kalmasını sağlarsınız.

Maliyet Optimizasyonu İçin Hangi Yöntemleri Kullanmalıyız?

Azure SQL'in cazip özelliklerinden biri de ölçeklenebilirliği ve "kullandığın kadar öde" modelidir. Ancak bu esneklik, aynı zamanda maliyetlerin iyi yönetilmesini gerektirir. Yanlış kaynak tahsisi veya verimsiz kullanım, beklenmedik faturalara yol açabilir. Bu bölümde, Azure SQL maliyetlerinizi optimize etmenize yardımcı olacak yöntemleri ve komutları inceleyeceğiz.

Kaynak Tüketimi İzleme ve Analizi

Maliyet optimizasyonunun ilk adımı, kaynak tüketimini anlamaktır. Azure SQL, veritabanınızın ve sunucunuzun CPU, bellek, G/Ç ve işlem günlüğü kullanımını izlemek için güçlü DMV'ler sunar:

  • sys.dm_db_resource_stats: Bir Azure SQL veritabanı için son bir saat içindeki kaynak kullanım istatistiklerini (CPU, G/Ç, log G/Ç, bellek) her 15 saniyede bir kaydeder. Anlık veya kısa vadeli performans sorunlarını ve kaynak darboğazlarını belirlemek için idealdir.
  • sys.resource_stats: Master veritabanında bulunan bu görünüm, tüm Azure SQL veritabanları için son 14 gün içindeki kaynak kullanımını her 5 dakikada bir kaydeder. Uzun vadeli eğilimleri, yoğun saatleri ve kapasite planlamasını anlamak için çok önemlidir.

Bu görünümlerden elde edilen verileri analiz ederek, veritabanınızın belirli zaman dilimlerinde aşırı veya yetersiz kaynak kullanıp kullanmadığını tespit edebilirsiniz. Örneğin, gece saatlerinde CPU kullanımının %5'in altında kaldığını, ancak gün içinde %90'lara çıktığını fark edebilirsiniz. Bu bilgi, doğru performans katmanını seçmek veya sunucusuz (serverless) modeli değerlendirmek için kritik bir başlangıç noktasıdır.


-- Son bir saatteki kaynak kullanımını kontrol et
SELECT
    end_time,
    avg_cpu_percent,
    avg_data_io_percent,
    avg_log_write_percent,
    avg_memory_usage_percent
FROM
    sys.dm_db_resource_stats
ORDER BY
    end_time DESC;

-- Son 14 gündeki genel kaynak kullanımını kontrol et (master veritabanında çalıştırın)
SELECT
    start_time,
    end_time,
    avg_cpu_percent,
    avg_data_io_percent,
    avg_log_write_percent,
    dtu_consumption_percent
FROM
    sys.resource_stats
WHERE
    database_name = 'YourDatabaseName'
ORDER BY
    end_time DESC;
    

Doğru Performans Katmanını Seçme: DTU, vCore, Elastic Pools ve Serverless

Azure SQL, farklı iş yükü ihtiyaçlarına uygun çeşitli performans katmanları ve satın alma modelleri sunar. Doğru seçimi yapmak, maliyetleri önemli ölçüde etkiler:

  • DTU (Veritabanı İşlem Birimi) Modeli: Basit ve tahmin edilebilir iş yükleri için uygundur. CPU, G/Ç ve işlem günlüğü kaynaklarını tek bir ölçümde birleştirir. Küçük veya orta ölçekli veritabanları için kolay bir başlangıç noktasıdır.
  • vCore Modeli: Daha karmaşık ve yüksek performans gerektiren iş yükleri için uygundur. CPU, bellek ve G/Ç kaynaklarını ayrı ayrı yapılandırma ve ölçeklendirme esnekliği sunar. Mevcut şirket içi SQL Server lisanslarınızı Azure'a taşıyarak (Azure Hybrid Benefit) maliyet avantajı sağlayabilir.
  • Elastic Pools (Esnek Havuzlar): Birden çok veritabanının ortak bir kaynak havuzunu paylaştığı senaryolar için idealdir. Özellikle tahmin edilemeyen ve ani pikler gösteren, ancak toplamda aynı anda yüksek kaynak kullanımı gerektirmeyen veritabanları için maliyet etkilidir. Örneğin, yüzlerce müşterinin her birinin kendi veritabanına sahip olduğu SaaS uygulamaları.
  • Serverless (Sunucusuz) Modeli: Azure SQL'in en yeni ve maliyet etkin seçeneklerinden biridir. Yoğunluklu olmayan, aralıklı ve tahmin edilemeyen iş yükleri için tasarlanmıştır. Veritabanı otomatik olarak kaynaklarını ölçeklendirir ve etkinlik olmadığı zamanlarda otomatik olarak duraklatılır (pause). Sadece kaynak kullanıldığı zaman ödeme yapılır. Geliştirme/test ortamları veya seyrek kullanılan uygulamalar için mükemmeldir.

Vaka Analizi: Geliştirme Ortamında Maliyetleri Düşürmek

Bir yazılım geliştirme şirketi, her geliştirme ekibi için ayrı bir Azure SQL veritabanı kullanıyordu. Bu veritabanları gün içinde aktif olarak kullanılırken, geceleri ve hafta sonları tamamen boşta kalıyordu. Geliştirme ortamı için vCore tabanlı "Genel Amaçlı" katmanı seçimi, aylık maliyetleri oldukça yükseltmişti. sys.resource_stats ile yapılan analizler, bu veritabanlarının büyük çoğunluğunun %5'in altında CPU kullanımı sergilediğini ve uzun süreler boyunca boşta kaldığını gösterdi.

Çözüm olarak, geliştirme veritabanları Serverless modeline geçirildi. Bu geçiş sayesinde, veritabanları etkinlik olmadığı zamanlarda otomatik olarak duraklatıldı ve yalnızca aktif kullanım sırasında kaynaklar için ödeme yapıldı. Bu değişiklik, geliştirme ortamı maliyetlerinde %70'e varan bir düşüş sağladı. Benzer şekilde, birden fazla küçük veritabanına sahip ve kaynak ihtiyaçları birbirini dengeleyen bir SaaS uygulaması için Elastic Pools modeline geçiş, bireysel veritabanları için ayrı ayrı kaynak ayırmaktan çok daha uygun maliyetli olabilir.


-- Mevcut veritabanının servis amacını Serverless olarak değiştirme örneği (ALTER DATABASE komutuyla)
ALTER DATABASE [YourDatabaseName]
MODIFY (SERVICE_OBJECTIVE = 'Serverless', MAX_SIZE = 10 GB, MIN_CPU = 0.5, MAX_CPU = 4, AUTO_PAUSE_DELAY_MINUTES = 60);
    

Maliyet optimizasyonu, tek seferlik bir işlemden ziyade sürekli bir izleme ve ayarlama sürecidir. Düzenli olarak kaynak tüketimini gözden geçirmek ve iş yükünüze en uygun performans modelini seçmek, Azure SQL'den en yüksek değeri almanızı sağlarken maliyetleri kontrol altında tutmanıza yardımcı olacaktır.

Mobil Uyumlu Raporlama İçin Ne Gibi İpuçları Var?

Azure SQL'den çektiğiniz verileri sunmak genellikle bir web uygulaması veya raporlama aracı aracılığıyla yapılır. Kullanıcıların çoğu artık mobil cihazlardan verilere eriştiği için, mobil uyumlu raporlama ve veri sunumu kritik öneme sahiptir. SQL veritabanının kendisi doğrudan mobil uyumluluk sağlamasa da, verilerinizi sunan web arayüzlerinde bu uyumluluğu sağlamak için modern web geliştirme tekniklerini kullanabilirsiniz. İşte Azure SQL verilerini sunarken mobil uyumluluğu artırmak için bazı ipuçları ve bir örnek:

Azure SQL Verilerinin Sunumu ve Mobil Uyumluluk

Azure SQL verileriniz genellikle bir API (örneğin, Azure Functions veya Azure App Service üzerinde çalışan bir REST API) aracılığıyla çekilir ve bir frontend uygulamasına (React, Angular, Vue veya basit HTML/CSS/JavaScript) iletilir. Bu frontend uygulamasının mobil uyumlu olması için Responsive Web Design (Duyarlı Web Tasarımı) prensiplerini benimsemek gerekir.

Bu prensipler, CSS Media Queries (Ortam Sorguları) kullanarak ekran boyutuna, cihaz yönelimine ve çözünürlüğe göre farklı stiller uygulamayı içerir. Aşağıda, Azure SQL'den çekilen basit bir tablo verisini mobil cihazlarda daha iyi görüntülemek için kullanılabilecek temel bir HTML yapısı ve CSS Media Query örneği bulunmaktadır.



Azure SQL Veri Raporu

Ürün Adı Kategori Stok Miktarı Son Güncelleme
Dizüstü Bilgisayar Elektronik 150 2023-10-26
Akıllı Telefon Elektronik 300 2023-10-25

CSS Media Query Örneği

Yukarıdaki HTML tablosunu mobil cihazlarda daha okunabilir hale getirmek için kullanabileceğiniz bir CSS Media Query örneği:


/* Genel tablo stilleri */
.responsive-table {
    width: 100%;
    border-collapse: collapse;
    margin: 1em 0;
    box-shadow: 0 0 10px rgba(0, 0, 0, 0.15);
}

.responsive-table th,
.responsive-table td {
    padding: 10px;
    border: 1px solid #ddd;
    text-align: left;
}

.responsive-table thead {
    background-color: #f8f8f8;
}

/* Mobil cihazlar için Media Query */
@media screen and (max-width: 768px) {
    .responsive-table thead {
        display: none; /* Başlık satırını gizle */
    }

    .responsive-table, .responsive-table tbody, .responsive-table tr, .responsive-table td {
        display: block; /* Her elemanı blok seviyesinde göster */
        width: 100%; /* Tam genişlik */
    }

    .responsive-table tr {
        margin-bottom: 1em;
        border: 1px solid #ddd;
    }

    .responsive-table td {
        text-align: right; /* Veri değerini sağa hizala */
        padding-left: 50%; /* Etiket için yer bırak */
        position: relative;
    }

    .responsive-table td::before {
        content: attr(data-label); /* data-label niteliğini etiket olarak kullan */
        position: absolute;
        left: 10px;
        width: calc(50% - 20px);
        padding-right: 10px;
        white-space: nowrap;
        text-align: left;
        font-weight: bold;
    }
}
    

Uzman İpucu: Azure Data Studio'daki Jupyter Notebook'ları veya Power BI gibi araçları kullanarak da Azure SQL verilerini görselleştirebilir ve paylaşabilirsiniz. Bu araçlar genellikle kendiliğinden responsive tasarım yeteneklerine sahiptir, bu da mobil cihazlarda daha iyi bir deneyim sunar. Eğer sadece veri analizi ve raporlama yapıyorsanız, bu tür hazır araçlar geliştirme yükünüzü azaltabilir.

Bu örnekte, büyük ekranlarda standart bir tablo görünümü sağlanırken, ekran genişliği 768 pikselin altına düştüğünde (tipik tablet ve mobil ekran boyutları için), tablo başlıkları gizlenir ve her bir satır, etiketli kartlara dönüşür. data-label niteliği, her hücrenin neyi temsil ettiğini mobil görünümde açıkça belirtmek için kullanılır. Bu, Azure SQL'den gelen ham verileri kullanıcı dostu ve erişilebilir bir formatta sunmanın temel bir yoludur.

Sonuç

Azure SQL, modern bulut uygulamalarının vazgeçilmez bir parçasıdır ve sunduğu özellikler sadece temel veritabanı işlemlerinden çok daha fazlasını kapsar. Bu makalede ele aldığımız "gizli cevherler"—Dinamik Yönetim Görünümleri, gelişmiş T-SQL fonksiyonları, güvenlik özellikleri ve maliyet optimizasyon stratejileri—veritabanı yönetiminde karşılaşabileceğiniz birçok zorluğun üstesinden gelmenize yardımcı olabilir. Performans darboğazlarını tespit etmekten, hassas verileri korumaya ve operasyonel maliyetleri düşürmeye kadar, doğru araçları bilmek ve kullanmak, Azure SQL deneyiminizi kökten değiştirecektir.

Unutulmamalıdır ki, Azure SQL gibi dinamik bir bulut hizmetinde sürekli öğrenme ve keşif, en iyi uygulamaları sürdürmek için esastır. Bu komutlar ve fonksiyonlar, sadece sorunları çözmekle kalmaz, aynı zamanda proaktif bir yaklaşımla veritabanı sağlığınızı güvence altına almanıza ve uygulamalarınızın her zaman en yüksek performansta çalışmasını sağlamanıza olanak tanır. Artık bu gizli cevherlerle donatılmış olarak, Azure SQL veritabanlarınızın tam potansiyelini açığa çıkarmaya hazırsınız.

Sıkça Sorulan Sorular (SSS)

Azure SQL'de en sık karşılaşılan performans sorunları nelerdir?
Genellikle en sık karşılaşılan sorunlar yetersiz indeksleme, uzun süren sorgular, blokajlar, yüksek CPU/bellek tüketimi ve G/Ç darboğazlarıdır. Bu sorunları tespit etmek için sys.dm_exec_query_stats, sys.dm_exec_requests ve sys.dm_os_wait_stats gibi DMV'ler kritik öneme sahiptir.
DMV'leri günlük olarak kontrol etmeli miyim?
Günlük manuel kontrol yerine, Azure Monitor, Azure SQL Diagnostics veya Azure Automation ile otomatize edilmiş uyarı sistemleri kurmanız önerilir. Kritik eşikler aşıldığında size bildirim gelmesini sağlayarak proaktif bir yaklaşım sergileyebilirsiniz. Periyodik olarak, örneğin haftalık veya aylık, daha derinlemesine analizler yapmak faydalı olacaktır.
Otomatik ayarlama her zaman en iyi çözüm müdür?
Azure SQL'in otomatik ayarlama özelliği (Automatic Tuning), birçok yaygın performans sorununu otomatik olarak çözebilir ve genellikle iyi bir başlangıç noktasıdır. Ancak, çok özel veya karmaşık iş yükleri için her zaman en iyi çözümü sunmayabilir. Özellikle kritik uygulamalar için otomatik ayarlamayı dikkatlice izlemeli ve gerektiğinde manuel optimizasyonlarla desteklemelisiniz.
Azure SQL maliyetini düşürmek için en etkili yol nedir?
En etkili yol, veritabanı kaynak kullanımınızı sys.dm_db_resource_stats ve sys.resource_stats ile düzenli olarak izlemektir. Ardından, iş yükünüze en uygun servis katmanını (DTU, vCore, Elastic Pools) ve modeli (Serverless) seçerek kaynaklarınızı optimize edin. Geliştirme/test ortamları için Serverless modeli veya Azure Hybrid Benefit'i kullanmak önemli tasarruflar sağlayabilir.
Güvenlik özelliklerini (DDM, RLS, Always Encrypted) uygulamalarıma nasıl entegre ederim?
Dynamic Data Masking (DDM) ve Row-Level Security (RLS) genellikle veritabanı seviyesinde, uygulama kodunda önemli değişiklikler yapmadan uygulanabilir. Sadece DDM için maskeleme fonksiyonlarını, RLS için güvenlik politikalarını ve filtre işlevlerini tanımlamanız yeterlidir. Always Encrypted ise istemci tarafında şifreleme anahtarlarının yönetilmesini gerektirir ve uygulamanızın veritabanıyla etkileşime giren ADO.NET, JDBC veya ODBC sürücülerinin bu özelliği desteklemesi gerekir. Bu nedenle, uygulamanızda küçük kod değişiklikleri gerekebilir.

Yorumlar
İçeriği beğendiniz mi? Bir tartışma başlatın veya görüşlerinizi paylaşın.
Yorum Yaz

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

E-posta Bülteni
Yazılım Topluluğuna Katılın
En son güncellemeleri, yaratıcı ipuçlarını ve özel kaynakları doğrudan e-posta kutunuza alın. Tasarım ve inovasyonun geleceğini birlikte keşfedelim.