Yönetilen sunucu Logo ve Mikro için: SQL Server bakım planı, indeks, yedek ve güncellemede kim neyi yapar?

Logo ya da Mikro kullanan bir şirket için yönetilen sunucu, "sunucuyla biz uğraşmayalım" demektir. Ama program yavaşladığında, yedek eksik çıktığında ya da güncelleme sonrası bir rapor açılmadığında ilk soru hep aynıdır: bu kimin işi? Bu yazı KOBİ sahibi, muhasebe sorumlusu ve bilgi işlem işini yarı zamanlı yürüten kişi için hazırlandı. SQL Server bakımı, yedek, güncelleme ve uzak masaüstünde sağlayıcı, bayi ve şirket arasındaki iş bölümünü netleştirir. Ayrıca sağlayıcının işini gerçekten yaptığını kendiniz doğrulayabileceğiniz kontrol noktalarını verir.

Yönetilen sunucu iş yazılımında ne demek?

Bir Logo veya Mikro sunucusu dört katmandan oluşur:

1. Altyapı: donanım, sanallaştırma, disk, ağ, veri merkezi.
2. İşletim sistemi: Windows Server, güvenlik duvarı, Windows güncellemeleri, uzak masaüstü (RDS) rolü.
3. Veritabanı motoru: SQL Server kurulumu, bellek ayarı, bakım işleri, yedekler.
4. Uygulama: Logo Tiger, GO, Mikro Jump, Fly gibi programın kendisi, sürüm yükseltmesi, firma ve dönem tanımları, e-fatura bağlantıları.

Yönetilmeyen bir VPS'te sağlayıcı yalnız ilk katmandan sorumludur. Yönetilen sunucuda sağlayıcı genellikle ilk üç katmanı üstlenir. Uygulama katmanı ise çoğu durumda Logo ya da Mikro bayisinde kalır. Programın iç mantığını, veritabanı dönüşümlerini ve lisansını bilen taraf odur. Genel kavram ve sözleşme tarafı için yönetilen sunucu nedir ve sorumluluk paylaşımı yazısına bakabilirsiniz. Burada iş yazılımına özgü ayrıntılara odaklanıyoruz.

Sorumluluk tablosu: sağlayıcı, bayi ve şirket

Aşağıdaki tablo tipik bir dağılımdır. Sözleşmenizde her satırın karşılığını yazılı görmeden imza atmayın.

Gri alanlar genellikle şunlardır: antivirüsün SQL veri dosyalarını taramaması için hariç tutma, program klasörünün paylaşım izinleri, SQL uyumluluk düzeyi (compatibility level) değişikliği ve program tarafındaki rapor şablonları. Bunları açıkça yazdırın. "Gerekirse bakarız" ifadesi arıza anında üç tarafın birbirine yönlendirdiği bir döngü üretir.

SQL Server bakım planı: CHECKDB, indeks ve istatistik

Logo ve Mikro veritabanları sürekli yazılan, çok tablolu yapılardır. Bakım yapılmazsa sorgular zamanla yavaşlar ve fark edilmemiş bir bozulma, yedeklerle birlikte geriye doğru taşınır. Yönetilen sunucuda beklenen bakım planı üç parçadan oluşur.

DBCC CHECKDB

Veritabanının fiziksel ve mantıksal tutarlılığını denetler. Haftada en az bir kez, iş saati dışında çalışmalıdır. Büyük veritabanlarında disk ve CPU yükü yaratır, bu yüzden yedekle aynı saate konmamalıdır. Hata çıkarsa sağlayıcının sizi aynı gün bilgilendirmesi gerekir. CHECKDB'nin REPAIR_ALLOW_DATA_LOSS seçeneği veri kaybettirebilir. Bu seçenek bayi ve şirket onayı olmadan kesinlikle çalıştırılmamalı, önce temiz yedekten geri dönüş değerlendirilmelidir.

İndeks bakımı

Yoğun kayıt girilen tablolarda indeksler parçalanır. Yaygın yaklaşım, parçalanması orta düzeyde olan indeksleri yeniden düzenlemek (REORGANIZE), yüksek olanları yeniden oluşturmaktır (REBUILD). Microsoft'un güncel belgesi sabit eşikler yerine iş yüküne göre ölçmeyi önerir. Yine de küçük indeksleri (birkaç yüz sayfanın altı) atlamak ve yalnız gerçekten parçalanmış olanlara dokunmak mantıklıdır. Ayrıntı için Microsoft'un indeks bakımı belgesine bakabilirsiniz.

Dikkat: Standard sürümde çevrimiçi (ONLINE) yeniden oluşturma yoktur. REBUILD sırasında tablo kilitlenir. Bu iş gece penceresinde yapılmalıdır.

İstatistik güncelleme

Sorgu iyileştiricisi hangi yolu seçeceğine istatistiklere bakarak karar verir. Toplu fatura aktarımı ya da dönem devri gibi büyük veri değişimlerinden sonra istatistikler eskir ve raporlar aniden yavaşlar. REBUILD edilen indekslerin istatistikleri zaten yenilenir. Geri kalanlar için haftalık güncelleme yeterlidir.

SQL Express kullananlar için not

SQL Server Express'te SQL Server Agent yoktur. Bu yüzden bakım planı sihirbazı da yoktur. Bakım ve yedek işleri Windows Görev Zamanlayıcı ile sqlcmd üzerinden çalıştırılmalıdır. Sağlayıcıya bunu nasıl yaptığını sorun. Express'in veritabanı boyutu sınırı da ayrı bir izleme konusudur.

Sağlayıcının işini kendiniz doğrulayın

Rapor istemek iyidir, ama doğrudan bakmak daha iyidir. Aşağıdaki sorgu her kullanıcı veritabanı için son tam, fark ve günlük yedeğinin tarihini, kurtarma modelini ve son başarılı CHECKDB zamanını listeler. Yalnız okuma yapar, hiçbir şeyi değiştirmez, geri alınacak bir işlem yoktur. SQL Server 2016 SP2 ve sonrası için hazırlandı. SQL Server Management Studio'da master üzerinde, en az VIEW SERVER STATE ve msdb okuma yetkisi olan bir hesapla çalıştırın.

-- Her kullanıcı veritabanı için son yedekler ve son başarılı CHECKDB
-- Yalnız okur; SQL Server 2016 SP2 ve sonrası için hazırlandı
SELECT
    d.name                                   AS veritabani,
    d.recovery_model_desc                    AS kurtarma_modeli,
    MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS son_tam_yedek,
    MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS son_fark_yedek,
    MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS son_gunluk_yedek,
    DATABASEPROPERTYEX(d.name, 'LastGoodCheckDbTime')        AS son_basarili_checkdb
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
       ON b.database_name = d.name
WHERE d.database_id > 4          -- sistem veritabanlarını atla
GROUP BY d.name, d.recovery_model_desc
ORDER BY d.name;

Beklenen çıktıda her satırda son tam yedek son 24 saat içinde olmalı. Kurtarma modeli FULL ise son günlük yedeği birkaç saatten eski olmamalı. son_basarili_checkdb sütunu son bir hafta içinde olmalı. 1900-01-01 görüyorsanız CHECKDB hiç başarıyla çalışmamış demektir.

İndeks parçalanmasını görmek için aşağıdaki sorguyu ilgili Logo ya da Mikro veritabanında çalıştırın. LIMITED kipi hafiftir, yine de çok büyük veritabanlarında iş saati dışında tercih edin. Bu da yalnız okur.

-- En parçalı 20 indeks (1.000 sayfanın üstündekiler)
SELECT TOP (20)
    OBJECT_NAME(s.object_id)          AS tablo,
    i.name                            AS indeks,
    s.avg_fragmentation_in_percent    AS parcalanma_yuzde,
    s.page_count                      AS sayfa
FROM sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'LIMITED') AS s
JOIN sys.indexes AS i
  ON i.object_id = s.object_id AND i.index_id = s.index_id
WHERE s.page_count > 1000 AND i.name IS NOT NULL
ORDER BY s.avg_fragmentation_in_percent DESC;

Bakım düzenli yapılıyorsa büyük indekslerin çoğunda parçalanma düşük kalır. Haftalarca yüksek görüyorsanız sağlayıcıya bakım işinin geçmişini sorun.

Yedek ve geri yükleme testi: tam, fark ve günlük yedeği

SQL Server'da üç yedek türü vardır:

• Tam yedek: veritabanının tamamı. Genellikle her gece.
• Fark yedeği: son tam yedekten bu yana değişenler. Gün içinde birkaç kez ya da tam yedeğin seyrek alındığı günlerde.
• İşlem günlüğü yedeği: yalnız FULL kurtarma modelinde. Saatlik ya da daha sık alınabilir, belli bir ana dönmeyi sağlar.

Karar ölçütü, ne kadar veri kaybını kabul edebileceğinizdir. Gün içinde yüzlerce fatura kesen bir şirket için yalnız gece yedeği, bir günlük işi yeniden girmek demektir. Bu kabul edilemiyorsa FULL model ve günlük yedeği gerekir. Sık yapılan hata, FULL modele geçip günlük yedeğini almamaktır. Bu durumda günlük dosyası (LDF) durmadan büyür ve diski doldurur.

Yedeğin sunucuyla aynı diskte durması yedek sayılmaz. En az bir kopya sunucudan ayrı, tercihen değiştirilemez bir depoda olmalıdır. Yedeğin işe yaradığı ise yalnız geri yükleme testiyle kanıtlanır. Sağlayıcıdan ayda en az bir kez, test veritabanı adıyla ayrı bir ortama geri yükleme yapmasını ve sonucu (süre, hata, kayıt sayısı kontrolü) yazılı bildirmesini isteyin. Geri yüklenen veritabanını bayinize ya da muhasebe sorumlusuna açtırıp son kesilen faturanın orada olduğunu görmek en basit doğrulamadır. Konunun ayrıntısı Logo ve Mikro için SQL yedeği ve geri yükleme testi yazısında var.

Windows ve SQL Server güncellemeleri: bakım penceresi ve dönem sonu

Microsoft güvenlik güncellemelerini her ayın ikinci salı günü yayımlar. SQL Server için düzenli toplu güncellemeler (Cumulative Update) çıkar. Yönetilen sunucuda bunların uygulanması sağlayıcının işidir. Ama ne zaman uygulanacağına birlikte karar verilmelidir.

Uygulanabilir bir düzen şöyledir:

1. Sabit bakım penceresi: örneğin her ayın üçüncü haftası, gece yarısından sonra. Yeniden başlatma bu pencerede yapılır.
2. Dondurma dönemleri: ay sonu kapanışı, beyanname ve e-defter gönderim günleri, yıl sonu devri. Bu günlerde acil güvenlik yaması dışında güncelleme yapılmaz. Tarihleri yılın başında sağlayıcıya yazılı verin.
3. Önce yedek: her güncelleme öncesi tam veritabanı yedeği ve mümkünse sunucu snapshot'ı alınır. Sorun çıkarsa geri dönüş yolu budur.
4. Bayi teyidi: SQL Server'ın ana sürüm yükseltmesi (örneğin 2019'dan 2022'ye) ya da uyumluluk düzeyi değişikliği, programın desteklediği sürümler listesine bakılmadan yapılmaz. Bu teyit bayiden gelir.
5. Sonrası kontrol: güncellemeden sonra programa bir kullanıcıyla girilip bir fiş ve bir rapor açılır. Sabah ilk kullanıcı gelmeden bu kontrolün yapılmış olması gerekir.

Program sürüm yükseltmesi ayrı bir iştir. Logo ya da Mikro yeni sürüm yayımladığında veritabanı dönüşümünü bayi yapar. Sağlayıcının görevi, öncesinde yedek almak, gerekirse disk ve bellek ayırmak ve iş bitene kadar erişimi açık tutmaktır.

Uzak masaüstü, RDS CAL ve kullanıcı ekleme çıkarma

Logo ve Mikro bulut sunucuda çoğunlukla uzak masaüstüyle kullanılır. Windows Server'da RD Session Host rolü olmadan aynı anda yalnız iki yönetim oturumu açılabilir. Çok kullanıcılı kullanım için RDS CAL lisansı gerekir: kullanıcı başına (User CAL) ya da cihaz başına (Device CAL). Lisans sağlayıcıdan kiralanıyorsa sayı faturada görünmelidir.

Kullanıcı yönetiminde iş bölümü şöyle olmalıdır:

• Yeni çalışan: şirket talep eder, sağlayıcı Windows hesabını açar ve RDS grubuna ekler, bayi ya da şirket içi yetkili program içi kullanıcıyı tanımlar.
• Ayrılan çalışan: aynı gün Windows hesabı devre dışı bırakılır, program kullanıcısı pasife alınır. Hesabı silmek yerine devre dışı bırakmak, geçmiş kayıtlardaki kullanıcı izini korur.
• Dönemsel kontrol: üç ayda bir, sağlayıcıdan aktif Windows hesaplarının listesini isteyin ve personel listesiyle karşılaştırın.

Güvenlik tarafında 3389 portunun internete açık olmaması, NLA ve mümkünse çok faktörlü doğrulama ya da VPN üzerinden erişim yönetilen hizmetin parçası olmalıdır.

İzleme: disk, bellek, kopan oturum ve yavaşlık uyarıları

Yönetilen hizmetin değeri, sorunu siz fark etmeden görmesindedir. Sözleşmede şu uyarıların karşılığını arayın:

• Disk doluluğu: veri, günlük ve yedek disklerinde ayrı eşik. Günlük dosyasının ani büyümesi ayrıca izlenmeli.
• Bellek: SQL Server ve uzak masaüstü oturumları aynı sunucudaysa SQL'in max server memory değeri sınırlanmalıdır. Sınırsız bırakılırsa SQL belleği doldurur, kullanıcı oturumları yavaşlar.
• CPU ve disk gecikmesi: sürekli yüksek disk gecikmesi, "program dondu" şikâyetlerinin sık nedenidir.
• Kopuk ve boşta oturumlar: kapatılmamış oturumlar bellek tutar ve programda kayıt kilitlerine yol açabilir. Belirli süre sonra otomatik kapatma politikası uygulanmalıdır.
• Başarısız yedek ve bakım işi: her başarısız iş için aynı gün bildirim.
• SQL servisinin durması ve sertifika ya da lisans süresi uyarıları.

İzleme verisinden aylık kısa bir rapor istemek, kapasite artırma kararını tahminle değil ölçümle vermenizi sağlar.

Yönetilmeyen VPS ile karşılaştırma: ne zaman yönetilen sunucu seçilmeli?

Yönetilmeyen VPS şu durumda mantıklıdır: şirket içinde SQL Server yedeğini, bakımını ve Windows güncellemesini düzenli yapabilen ve izinde de yerine bakacak biri olan bir kişi varsa. Bu kişi yoksa ya da tek kişiye bağlıysanız, ucuz VPS'in görünmeyen maliyeti alınmamış yedek ve çalışmayan bakım işidir. Bunun bedeli de bir günlük veri kaybı ya da dönem sonunda duran muhasebedir.

Yönetilen hizmetin eksileri de var. Her değişikliği talep açarak yaptırmanız gerekebilir. Bazı sağlayıcılar yönetici yetkisini sınırlar. Bayi ile sağlayıcı arasında koordinasyon gerekir. Seçmeden önce sağlayıcının bayinize doğrudan erişim verip vermediğini ve acil durumda kimi aradığınızı netleştirin. Logo için Logo sunucu sayfasında hangi sürümlerin desteklendiğini görebilirsiniz.

Sık yapılan hatalar

• FULL kurtarma modeline geçip günlük yedeği almamak, LDF dosyasının diski doldurması.
• Yedeği yalnız aynı sunucuda tutmak ve hiç geri yükleme testi yapmamak.
• Ay sonu kapanış gecesinde Windows güncellemesinin sunucuyu yeniden başlatması.
• Bayiye sormadan SQL ana sürüm yükseltmesi ya da uyumluluk düzeyi değişikliği yapmak.
• SQL max server memory değerini varsayılan bırakıp uzak masaüstü kullanıcılarını yavaşlatmak.
• Ayrılan çalışanın Windows hesabını aylarca açık bırakmak.
• Sorumluluk tablosunu sözleşmeye yazdırmamak.

Sık sorulan sorular

Yönetilen sunucuda Logo ya da Mikro sürüm yükseltmesini sağlayıcı mı yapar?

Genellikle hayır. Program sürümü ve veritabanı dönüşümü bayinin işidir, çünkü üretici yetkisi ve programa özgü bilgi gerektirir. Sağlayıcı öncesinde yedek alır, kaynak ayırır ve erişimi hazırlar. Sözleşmede bu ayrımı açıkça yazdırın.

SQL bakım planı ne sıklıkla çalışmalı?

Yaygın düzen her gece tam yedek, FULL modeldeyse saatlik günlük yedeği, haftada bir CHECKDB, haftalık indeks ve istatistik bakımıdır. Veri hacminiz büyükse ve gece pencereniz kısaysa işler günlere bölünebilir. Doğru sıklık, kabul ettiğiniz veri kaybı süresine ve bakım penceresine göre belirlenir.

Yedeğin çalıştığını nasıl anlarım?

Yedek dosyasının varlığı yeterli değildir. Ayrı bir ortama geri yükleme yapılmalı ve programdan son kayıtların göründüğü kontrol edilmelidir. Yukarıdaki sorguyla son yedek tarihlerini de kendiniz görebilirsiniz.

Mikro için de aynı sorumluluk dağılımı geçerli mi?

Evet, mantık aynıdır. Altyapı, Windows ve SQL katmanı sağlayıcıda, program ve lisans bayide, kullanıcı ve veri doğruluğu şirkette kalır. Mikro'ya özgü dönem ve şirket yapısı ayrıntılarını bayinizle birlikte sorumluluk tablosuna ekleyin.

Yönetilen sunucuda yönetici (administrator) yetkim olur mu?

Sağlayıcıya göre değişir. Bazıları tam yetki verip yapılan değişikliklerden doğan sorunu kapsam dışı sayar, bazıları yetkiyi sınırlar. Hangisinin sizin için uygun olduğuna, şirket içinde sunucuya dokunacak biri olup olmadığına bakarak karar verin.

Bu işi hazır yapmak isterseniz

SQL bakımı, yedek, güncelleme penceresi ve uzak masaüstü kullanıcı yönetimini kendiniz kurmak yerine hazır almak isterseniz muhasebe ve ERP sunucusu sayfasında kapsamı ve taşıma seçeneklerini inceleyebilir, bayinizle birlikte sorumluluk tablosunu netleştirmek için teklif isteyebilirsiniz.

Sonuç

Yönetilen sunucu, Logo ve Mikro tarafında işin tamamını değil, altyapı, Windows ve SQL Server katmanını devretmek demektir. Program, lisans ve dönüşüm bayide, kullanıcı ve veri doğruluğu sizde kalır. Sözleşmeye sorumluluk tablosunu yazdırın, dondurma dönemlerini baştan bildirin ve sağlayıcının raporlarını yukarıdaki sorgularla ayda bir kendiniz doğrulayın. Böylece arıza anında kimi arayacağınızı ve yedeğin gerçekten çalıştığını önceden bilirsiniz.