PvPSunucusu Silkroad Web Panel’de Database Yönetimi menüsü, web panelin oyun veritabanlarıyla kurduğu bağlantıları, sistem tablolarını, bakım işlemlerini, SQL kontrollerini, yedekleme süreçlerini ve teknik veritabanı araçlarını yönetmek için kullanılan en hassas admin alanlarından biridir.

Bu menü, sıradan bir içerik veya destek menüsü değildir. Database Yönetimi menüsünde yapılan işlem doğrudan oyuncu hesaplarını, karakterleri, itemleri, silk bakiyelerini, market kayıtlarını, ödeme geçmişini, logları, guildleri, event sistemlerini ve panelin çalışma düzenini etkileyebilir. Bu yüzden bu menü sadece teknik bilgiye sahip yetkililer tarafından kullanılmalıdır.

1. Database Yönetimi Menüsü Ne İşe Yarar?

Database Yönetimi menüsü, Silkroad Web Panel’in bağlı olduğu veritabanlarını kontrol etmek ve panelin ihtiyaç duyduğu database işlemlerini yönetmek için kullanılır. Bu menü üzerinden bağlantı durumu kontrol edilebilir, eksik tablolar kurulabilir, sistem prosedürleri güncellenebilir, yedekleme işlemleri takip edilebilir ve bazı teknik bakım işlemleri yapılabilir.

Bu menü altında genellikle şu işlemler bulunur:

• Account DB bağlantı kontrolü
• Shard DB bağlantı kontrolü
• Log DB bağlantı kontrolü
• Guard / Panel DB bağlantı kontrolü
• Database bağlantı bilgilerini görüntüleme veya test etme
• Eksik tablo kurulumu
• Eksik kolon kontrolü
• Stored procedure kurulum ve güncelleme işlemleri
• View kontrolü ve yenileme
• Database installer çalıştırma
• Yedek alma ve yedek durumunu kontrol etme
• Restore işlemlerini yönetme veya yönlendirme
• SQL sorgu çalıştırma alanı
• Tablo bakım ve optimizasyon kontrolleri
• Log temizleme veya arşivleme
• Database sağlık kontrolü
• Panel modüllerinin ihtiyaç duyduğu tabloları doğrulama

2. Silkroad Veritabanı Mantığı Basitçe Nedir?

Silkroad sistemlerinde veriler genellikle birden fazla veritabanına dağılmıştır. Oyuncu hesabı başka yerde, karakter başka yerde, loglar başka yerde, panelin kendi özel tabloları başka yerde tutulabilir. Bu ayrımı bilmeden database işlemi yapmak tehlikelidir.

Genel mantık şu şekildedir:

• Account DB: Oyuncu hesapları, giriş bilgileri, kullanıcı ID değerleri ve hesapla ilişkili temel kayıtlar burada bulunur.
• Shard DB: Karakterler, itemler, guildler, inventory, storage, oyun dünyası verileri ve karaktere bağlı kayıtlar burada bulunur.
• Log DB: Oyun içi loglar, işlem kayıtları, bazı sistem geçmişleri ve hareket verileri burada tutulabilir.
• Panel / Guard DB: Web panelin kendi tabloları, market sistemi, ödeme kayıtları, event sistemleri, güvenlik kayıtları, modül ayarları veya özel PvPSunucusu tabloları burada bulunabilir.

3. Database Bağlantı Kontrolü

Database Yönetimi menüsünün en temel işlevlerinden biri bağlantı kontrolüdür. Panelin ilgili veritabanlarına bağlanıp bağlanamadığını görmek için kullanılır.

Bağlantı kontrolünde incelenebilecek alanlar:

• SQL Server adresi
• SQL port bilgisi
• Database adı
• Kullanıcı adı
• Bağlantı durumu
• Son başarılı bağlantı zamanı
• Son hata mesajı
• Yetki seviyesi
• Okuma/yazma izni
• Timeout süresi

Bağlantı hatası varsa panel bazı sayfaları açamayabilir. Örneğin Shard DB bağlantısı yoksa karakter listesi, item finder, guild yönetimi veya inventory kontrolleri çalışmayabilir. Account DB bağlantısı yoksa kullanıcı arama ve hesap işlemleri bozulabilir.

Bağlantı sorunu kontrol sırası:
1. SQL Server çalışıyor mu?
2. Server IP/host doğru mu?
3. Port açık mı?
4. Database adı doğru mu?
5. Kullanıcı adı ve şifre doğru mu?
6. Kullanıcının ilgili DB üzerinde yetkisi var mı?
7. Firewall bağlantıya izin veriyor mu?
8. Panel hata logunda detay var mı?

4. Account DB Kontrolü

Account DB, oyuncu hesaplarının temel merkezidir. Kullanıcı girişleri, hesap ID değerleri, bazı güvenlik bilgileri ve hesapla ilişkili kayıtlar burada tutulabilir.

Account DB bağlantısı bozuksa şu sorunlar yaşanabilir:

• Oyuncu hesabı aranamayabilir.
• Yeni kayıt sistemi çalışmayabilir.
• Şifre sıfırlama işlemleri bozulabilir.
• Hesap ban/kilit durumu kontrol edilemeyebilir.
• Hesap ile karakter eşleştirme yapılamayabilir.
• Silk veya ödeme hesabı doğru kullanıcıyla eşleşmeyebilir.

Account DB üzerinde işlem yaparken çok dikkatli olunmalıdır. Yanlış kullanıcı ID eşleşmesi, yanlış hesaba silk veya market ürünü gitmesine neden olabilir.

5. Shard DB Kontrolü

Shard DB, oyun dünyasının ana veritabanıdır. Karakterler, itemler, guildler, inventory, storage, pet, skill, görev ve birçok oyun içi kayıt burada bulunabilir.

Shard DB bağlantısı bozuksa şu bölümler etkilenebilir:

• Karakter arama
• Karakter detay görüntüleme
• Item Finder
• Inventory ve storage kontrolü
• Guild / union yönetimi
• Event ödül teslimi
• Market item teslimi
• Teleport veya konum düzeltme işlemleri
• Gold/SP/level düzenleme işlemleri

Shard DB üzerinde yapılan hatalı işlem doğrudan oyun içi veriye zarar verebilir. Bu nedenle canlı sunucuda Shard DB’ye yönelik yazma işlemleri çok dikkatli yapılmalıdır.

6. Log DB Kontrolü

Log DB, oyun ve panel hareketlerini anlamak için kullanılır. Bazı sunucularda ödeme, market, kill, trade, stall, login, item hareketleri veya sistem kayıtları farklı log tablolarında bulunabilir.

Log DB şu durumlarda önemlidir:

• Oyuncu item kaybı iddiasında bulunuyorsa
• Trade veya stall hareketleri incelenecekse
• Ödeme ve market geçmişi kontrol edilecekse
• Ban veya güvenlik incelemesi yapılacaksa
• Unique kill, event veya job hareketleri doğrulanacaksa
• Teknik hata zamanı araştırılacaksa

Log DB çok büyüyebilir. Bu yüzden Log DB sorgularında tarih filtresi kullanmak önemlidir. Tüm log tablosunu filtresiz okumak paneli ve SQL sunucusunu yavaşlatabilir.

7. Panel / Guard DB Kontrolü

Panel veya Guard DB, PvPSunucusu Web Panel’in kendi sistemleri için kullandığı özel veritabanı olabilir. Market kayıtları, ödeme kayıtları, modül ayarları, event tabloları, ticket kayıtları, admin logları, cache kayıtları ve güvenlik tabloları burada tutulabilir.

Bu DB üzerinde bulunabilecek sistemler:

• Market ürün tabloları
• Market satın alma logları
• Ödeme kayıtları
• Silk hareket kayıtları
• Ticket kayıtları
• Admin işlem logları
• Event kayıt ve ödül tabloları
• Modül ayarları
• Cache ve panel ayarları
• Güvenlik ve IP/HWID tabloları

Panel DB bağlantısı bozuksa web panelin özel sistemleri çalışmayabilir. Oyuncu siteye girebilir ama ödeme, market veya ticket alanları hata verebilir.

8. Database Installer Nedir?

Database Installer, panelin ihtiyaç duyduğu tabloları, kolonları, indexleri, viewleri ve stored procedure kayıtlarını kurmak veya eksik olanları tamamlamak için kullanılan araçtır.

Installer şu işlemleri yapabilir:

• Eksik tabloları oluşturma
• Eksik kolonları ekleme
• Eksik indexleri oluşturma
• Stored procedure kurma veya güncelleme
• View oluşturma veya yenileme
• Varsayılan ayar kayıtlarını ekleme
• Panel modülleri için gerekli başlangıç verilerini oluşturma
• Database sürüm kontrolü yapma

Installer kullanılırken hangi tablo gruplarının kurulacağı açık görünmelidir. Örneğin market tabloları, ödeme tabloları, event tabloları, ticket tabloları, admin log tabloları gibi gruplar ayrı ayrı listelenmelidir.

9. Eksik Tabloları Tamamlama

Panel güncellendiğinde yeni modüller yeni tablolar isteyebilir. Eksik tablolar kurulmazsa ilgili modül hata verebilir veya boş çalışabilir.

Eksik tablo belirtileri:

• Modül sayfası açılırken SQL hatası veriyor
• Market sayfası boş geliyor
• Ödeme kayıtları oluşmuyor
• Event kaydı alınamıyor
• Ticket oluşturulamıyor
• Admin işlem logu yazılmıyor
• Panel “invalid object name” benzeri hata gösteriyor
• Kurulum sonrası bazı menüler çalışmıyor

Eksik tablo kurulumunda dikkat edilecekler:

1. Doğru database seçildi mi?
2. Kurulacak tablo grubu doğru mu?
3. Tablo daha önce var mı?
4. Var olan tabloya zarar verilecek mi?
5. Varsayılan kayıtlar tekrar eklenirse duplicate olur mu?
6. Kurulum işlemi loglanıyor mu?
7. Kurulumdan sonra modül test edilecek mi?

10. Stored Procedure ve View Yönetimi

Stored procedure ve view yapıları, panelin karmaşık SQL işlemlerini daha düzenli ve hızlı yapmasına yardımcı olabilir. Örneğin market teslimi, event ödülü, karakter sorguları, ranking listeleri veya log raporları procedure/view üzerinden çalışabilir.

Bu bölümde yapılabilecek işlemler:

• Eksik procedure kontrolü
• Procedure güncelleme
• View yenileme
• Procedure sürüm kontrolü
• Hatalı procedure tespiti
• Performans sorunu olan viewleri inceleme
• Modülün kullandığı SQL nesnelerini doğrulama

Procedure güncellerken eski sürüm, yeni sürüm ve değişiklik nedeni bilinmelidir. Yanlış procedure güncellemesi market teslimi, ödeme, event veya karakter işlemlerini bozabilir.

Procedure güncelleme güvenli akışı:
1. Mevcut procedure yedeği alınır
2. Yeni procedure doğru DB üzerinde çalıştırılır
3. Syntax hatası kontrol edilir
4. Test hesabıyla işlem denenir
5. Hata logları kontrol edilir
6. Değişiklik admin loguna yazılır

11. SQL Sorgu Çalıştırma Alanı

Bazı panellerde teknik yöneticiler için SQL sorgu çalıştırma alanı bulunabilir. Bu alan çok güçlüdür ve aynı ölçüde tehlikelidir.

SQL sorgu alanı şu amaçlarla kullanılabilir:

• Teknik kontrol yapmak
• Hatalı kayıt incelemek
• Belirli bir karakter veya hesabı doğrulamak
• Eksik veri tespiti yapmak
• Bakım sorgusu çalıştırmak
• Procedure veya view güncellemek
• Rapor amaçlı SELECT sorguları çalıştırmak

Ancak SQL alanında özellikle UPDATE, DELETE, INSERT, TRUNCATE, DROP, ALTER gibi komutlar çok dikkatli kullanılmalıdır. Yanlış WHERE şartı veya yanlış database seçimi büyük veri kaybına neden olabilir.

SQL çalıştırmadan önce sorulacak sorular

1. Doğru database seçili mi?
2. Bu sorgu sadece okuma mı yapıyor, veri mi değiştiriyor?
3. WHERE şartı doğru mu?
4. Kaç kayıt etkilenecek?
5. İşlem geri alınabilir mi?
6. Yedek alındı mı?
7. Bu işlem yoğun oyuncu saatinde yapılmalı mı?
8. İşlem admin loguna düşecek mi?

12. Yedek Alma Yönetimi

Database yedeği, canlı sunucunun sigortasıdır. Yanlış işlem, SQL hatası, disk arızası, saldırı, veri bozulması veya yanlış güncelleme durumunda geri dönüş için yedek gerekir.

Yedek alınması gereken durumlar:

• Panel güncellemesi öncesi
• Database installer çalıştırmadan önce
• Yeni tablo veya procedure kurulmadan önce
• Toplu SQL işlemi öncesi
• Market/ödeme sisteminde büyük değişiklik öncesi
• Sezon başlangıcı öncesi
• Sezon sıfırlama işlemleri öncesi
• Restore veya veri taşıma öncesi
• Günlük/haftalık rutin bakım sırasında

Yedeklerde dikkat edilmesi gerekenler:

• Yedek dosyası gerçekten oluştu mu?
• Dosya boyutu mantıklı mı?
• Yedek doğru DB’den mi alındı?
• Yedek güvenli yerde saklanıyor mu?
• Yedek dosyasına yetkisiz kişiler erişebiliyor mu?
• Yedek geri yükleme testi daha önce yapıldı mı?
• Yedek şifreli veya erişim kontrollü mü?

13. Restore İşlemi ve Büyük Riskleri

Restore, bir database yedeğini geri yükleme işlemidir. Bu işlem çok dikkatli yapılmalıdır. Yanlış restore, mevcut canlı veriyi eski veriyle değiştirebilir ve oyuncuların son kayıtları kaybolabilir.

Restore işlemi şu durumlarda gerekebilir:

• Database bozulduysa
• Yanlış toplu SQL işlemi yapıldıysa
• Sunucu taşındıysa
• Test ortamı hazırlanacaksa
• Sezon geri alma veya özel kurtarma gerekiyorsa

Restore öncesi mutlaka kontrol edilmesi gerekenler:

1. Restore yapılacak DB doğru mu?
2. Yedek dosyası doğru tarihe mi ait?
3. Canlı DB üzerine mi yazılacak?
4. Restore öncesi mevcut canlı DB yedeği alındı mı?
5. Oyuncular oyundan çıkarıldı mı?
6. Panel ve oyun servisleri durdurulmalı mı?
7. Restore sonrası hangi kontroller yapılacak?
8. İşlem yönetim onaylı mı?

14. Tablo Bakım ve Optimizasyon İşlemleri

Zamanla log tabloları, market kayıtları, ödeme kayıtları, ticket kayıtları ve oyun logları büyür. Büyük tablolar doğru indexlenmezse panel yavaşlar.

Bakım işlemleri şunları içerebilir:

• Index kontrolü
• Fragmentation kontrolü
• İstatistik güncelleme
• Eski logları arşivleme
• Gereksiz geçici kayıtları temizleme
• Tablo boyutlarını kontrol etme
• Yavaş sorguları tespit etme
• Ranking veya rapor tablolarını optimize etme

Bakım işlemleri yoğun oyuncu saatinde yapılmamalıdır. Büyük tablolarda yapılan bakım SQL Server üzerinde yük oluşturabilir.

Database bakım için uygun zaman:
- Oyuncu yoğunluğunun düşük olduğu saatler
- Bakım duyurusu sonrası
- Yedek alındıktan sonra
- Teknik yetkili gözetiminde
- Hata durumunda geri dönüş planıyla

15. Log Temizleme ve Arşivleme

Log tabloları büyüdükçe panel ve SQL performansı etkilenebilir. Ancak logları rastgele silmek doğru değildir. Özellikle ödeme, market, silk, admin işlem ve ban logları uzun süre saklanmalıdır.

Arşivlenebilecek log türleri:

• Eski hata logları
• Eski debug kayıtları
• Eski geçici panel logları
• Çok eski giriş denemeleri
• Eski cache logları

Uzun süre saklanması gereken log türleri:

• Ödeme logları
• Silk hareket logları
• Market satın alma logları
• Market teslim logları
• Admin işlem logları
• Ban ve ceza logları
• Ticket geçmişleri
• Database işlem logları

16. Database Sağlık Kontrolü

Database sağlık kontrolü, veritabanlarının düzgün çalışıp çalışmadığını anlamak için yapılır. Bu kontrol düzenli yapılırsa büyük sorunlar oluşmadan önce riskler fark edilebilir.

Sağlık kontrolünde bakılabilecek noktalar:

• Bağlantı süreleri normal mi?
• SQL timeout hataları var mı?
• Disk alanı yeterli mi?
• Log dosyaları aşırı büyümüş mü?
• Yedekler düzenli alınıyor mu?
• Son yedek tarihi nedir?
• Market/ödeme tabloları yazılabiliyor mu?
• Shard DB sorguları yavaş mı?
• Ranking sorguları ağır mı?
• Hata loglarında tekrar eden SQL hatası var mı?

Sağlık kontrolü sadece hata çıktığında yapılmamalıdır. Haftalık veya aylık rutin kontrol, panel stabilitesi için önemlidir.

17. Database ve Panel Modülleri Arasındaki İlişki

Web paneldeki birçok modül kendi tablolarına ihtiyaç duyar. Bir modül çalışmıyorsa sorun her zaman PHP veya panel dosyasında olmayabilir; database tarafında eksik tablo, eksik kolon veya hatalı procedure olabilir.

Örnek modül-database ilişkileri:

• Market: Ürün, kategori, sipariş ve teslim log tablolarına ihtiyaç duyar.
• Ödeme: Ödeme logu, paket, callback ve silk hareket tablolarına ihtiyaç duyar.
• Ticket: Ticket, mesaj, kategori ve ek dosya tablolarına ihtiyaç duyar.
• Event: Event, kayıt, katılımcı, kazanan ve ödül tablolarına ihtiyaç duyar.
• Admin Log: Yönetici işlem kayıtları için log tablosuna ihtiyaç duyar.
• Cache: Ayar veya sayfa cache kayıtları için özel tablolar kullanabilir.
• Güvenlik: IP, HWID, başarısız giriş veya ban tablolarına ihtiyaç duyabilir.

Bir modül hata veriyorsa önce ilgili database nesnelerinin kurulu olup olmadığı kontrol edilmelidir.

18. Canlı Sunucuda Database İşlemi Yaparken Dikkat Edilecekler

Canlı sunucu üzerinde database işlemi yapmak test ortamından farklıdır. Oyuncular oyundayken bazı veriler oyun serverının RAM tarafında olabilir. Database değişikliği hemen yansımayabilir veya oyun serverı eski veriyi tekrar yazabilir.

Canlı ortamda dikkat edilmesi gerekenler:

• Oyuncu online iken karakter verisi değiştirmek risklidir.
• Inventory veya gold düzenlemeleri online karakterde çakışabilir.
• Market tesliminde envanter doluluğu kontrol edilmelidir.
• Yüksek hacimli sorgular oyuncu saatinde çalıştırılmamalıdır.
• Backup almadan toplu işlem yapılmamalıdır.
• Restore işlemi canlıda çok dikkatli planlanmalıdır.
• Procedure güncellemesi sonrası ilgili modül test edilmelidir.
• Yanlış DB seçimi kontrol edilmelidir.

19. Database Yetki Yönetimi

Database Yönetimi menüsü en yüksek riskli menülerden biridir. Bu menüye her admin erişmemelidir.

Önerilen yetki dağılımı:

• Destek yetkilisi: Database menüsünü görmemelidir.
• Market yetkilisi: Sadece market loglarını panel üzerinden görmeli, SQL çalıştırmamalıdır.
• Ödeme yetkilisi: Ödeme loglarını görebilir, DB ayarı değiştirmemelidir.
• Oyun yöneticisi: Karakter/guild bilgilerini panelden görebilir, doğrudan SQL yetkisi olmamalıdır.
• Teknik yönetici: Database bağlantı, installer, yedek ve teknik kontrolleri yapabilir.
• SuperAdmin: Tüm database işlemlerini onaylayabilir.

SQL sorgu çalıştırma, restore, tablo silme, procedure güncelleme ve log temizleme gibi işlemler teknik yönetici veya SuperAdmin seviyesinde olmalıdır.

20. Database İşlem Logları

Database menüsünde yapılan her kritik işlem loglanmalıdır. Kim, ne zaman, hangi database üzerinde, hangi işlemi yaptı bilinmelidir.

Loglanması gereken işlemler:

• Bağlantı ayarı değiştirme
• Database installer çalıştırma
• Eksik tablo kurma
• Procedure güncelleme
• View yenileme
• SQL sorgusu çalıştırma
• Yedek alma
• Restore işlemi
• Log temizleme
• Tablo bakım işlemi

İyi bir database işlem logunda bulunması gerekenler:

• İşlemi yapan admin
• İşlem tarihi
• Hedef database
• İşlem türü
• Etkilenen tablo veya procedure
• Etkilenen kayıt sayısı
• Başarılı/başarısız sonucu
• Hata mesajı varsa detay
• İşlem açıklaması

21. Database Destek Senaryoları

A) “Market sayfası açılıyor ama ürünler görünmüyor”

1. Panel DB bağlantısı kontrol edilir.
2. Market ürün tablosu var mı bakılır.
3. Market kategori tablosu kontrol edilir.
4. Ürünler aktif mi bakılır.
5. Market cache temizlenir.
6. Hata logu incelenir.

B) “Karakter arama çalışmıyor”

1. Shard DB bağlantısı kontrol edilir.
2. Karakter tablosuna erişim var mı bakılır.
3. SQL yetkisi kontrol edilir.
4. Arama sorgusu hata veriyor mu incelenir.
5. Panel hata logu kontrol edilir.

C) “Ödeme başarılı ama silk yüklenmiyor”

1. Ödeme log tablosu kontrol edilir.
2. Callback logu var mı bakılır.
3. Silk hareket tablosu kontrol edilir.
4. Account DB eşleşmesi doğru mu bakılır.
5. Procedure veya ödeme fonksiyonu hata veriyor mu incelenir.

D) “Yeni modül kuruldu ama menü hata veriyor”

1. Modülün ihtiyaç duyduğu tablo grubu kontrol edilir.
2. Database Installer üzerinden eksik tablolar tamamlanır.
3. Eksik kolon veya procedure var mı bakılır.
4. Panel cache temizlenir.
5. Modül test hesabıyla denenir.

22. Database İşlemi Öncesi Genel Kontrol Listesi

1. İşlem hangi database üzerinde yapılacak?
2. Doğru database seçildi mi?
3. İşlem okuma mı, yazma mı?
4. Yedek alındı mı?
5. İşlem kaç kaydı etkileyecek?
6. Önce SELECT ile kontrol edildi mi?
7. WHERE şartı doğru mu?
8. İşlem yoğun saatte mi yapılacak?
9. Geri dönüş planı var mı?
10. İşlem yönetim onaylı mı?
11. İşlem loglanacak mı?
12. İşlem sonrası hangi modüller test edilecek?

23. Database İşlemi Sonrası Kontrol Listesi

1. İşlem başarılı tamamlandı mı?
2. Hata logu oluştu mu?
3. Etkilenen kayıt sayısı beklenenle aynı mı?
4. Panel ilgili sayfayı açıyor mu?
5. Market/ödeme/karakter gibi ilgili modül test edildi mi?
6. Cache temizliği gerekiyor mu?
7. Oyuncu tarafında hata var mı?
8. Admin işlem logu oluştu mu?
9. İşlem notu veya teknik açıklama yazıldı mı?
10. Gerekirse yedek güvenli yerde saklandı mı?

24. Sık Yapılan Hatalar

• Yanlış database üzerinde işlem yapmak
• Yedek almadan SQL çalıştırmak
• WHERE şartı olmadan UPDATE veya DELETE yapmak
• Canlı sunucuda test edilmemiş procedure çalıştırmak
• Installer’ın hangi tabloyu kurduğunu kontrol etmemek
• Eksik tabloyu yanlış DB’ye kurmak
• Ödeme, market ve admin loglarını erken silmek
• Restore işlemi öncesi mevcut DB yedeği almamak
• Online karakter varken inventory/gold değişikliği yapmak
• SQL sorgu alanını fazla yetkiliye açmak
• Hata loglarını okumadan dosya tarafında sorun aramak
• Procedure güncellemesi sonrası test yapmamak
• Database bağlantı bilgilerini yetkisiz kişilerle paylaşmak

25. FAQ - Sık Sorulan Sorular

Database Yönetimi menüsü her admine açık olmalı mı?
Hayır. Bu menü sadece teknik yönetici ve SuperAdmin seviyesinde olmalıdır. Destek, market veya event yetkililerinin doğrudan SQL/database yetkisine ihtiyacı yoktur.

Eksik tablo kurulumu veri siler mi?
Güvenli tasarlanmış installer normalde eksik nesneleri tamamlar. Ancak yine de yanlış database seçimi veya hatalı kurulum riskine karşı önce yedek alınmalıdır.

SQL sorgu çalıştırmadan önce en önemli kontrol nedir?
Doğru database seçimi, WHERE şartı, etkilenecek kayıt sayısı ve yedek kontrolü en önemli noktalardır.

Restore işlemi ne zaman yapılmalı?
Sadece ciddi veri bozulması, yanlış toplu işlem veya sunucu taşıma gibi zorunlu durumlarda yapılmalıdır. Restore öncesi mevcut canlı DB yedeği alınmalıdır.

Market çalışmıyorsa ilk database tarafında ne kontrol edilir?
Panel/Guard DB bağlantısı, market ürün tabloları, kategori tabloları, sipariş tabloları, teslim logları ve hata logları kontrol edilmelidir.

Karakter arama çalışmıyorsa sorun nerede olabilir?
Shard DB bağlantısı, SQL kullanıcı yetkisi, karakter tablosu erişimi, arama sorgusu ve panel hata logları kontrol edilmelidir.

Log tabloları büyüdüyse direkt silmek doğru mu?
Hayır. Önce arşivleme düşünülmelidir. Ödeme, market, silk, admin ve ban logları uzun süre saklanmalıdır.

Database yedeği alındıysa yeterli mi?
Hayır. Yedeğin doğru DB’den alındığı, dosyanın sağlam olduğu ve gerektiğinde geri yüklenebilir olduğu da kontrol edilmelidir.

26. Performans ve Güvenlik Notları

• Database bağlantı bilgileri gizli tutulmalıdır.
• SQL kullanıcılarına gereğinden fazla yetki verilmemelidir.
• Panelin kullandığı SQL hesabı mümkünse sadece ihtiyaç duyduğu yetkilere sahip olmalıdır.
• Yedekler düzenli alınmalı ve güvenli yerde saklanmalıdır.
• Yedek dosyaları herkese açık web dizinlerinde tutulmamalıdır.
• Büyük log tablolarında tarih filtresi kullanılmalıdır.
• Ranking ve rapor sorguları cache veya optimize indexlerle desteklenmelidir.
• SQL sorgu alanı sadece teknik yöneticilere açık olmalıdır.
• Database işlem logları uzun süre saklanmalıdır.
• Restore işlemleri sadece yönetim onayıyla yapılmalıdır.
• Procedure ve view güncellemeleri test edilmeden canlıya alınmamalıdır.
• Canlı oyuncu saatlerinde ağır bakım sorguları çalıştırılmamalıdır.

27. Sonuç

Database Yönetimi menüsü, Silkroad Web Panel’in en güçlü ve en riskli yönetim alanlarından biridir. Account, Shard, Log ve Panel/Guard veritabanlarının sağlıklı çalışması; kullanıcı işlemleri, karakter yönetimi, market, ödeme, event, ticket, guild ve log sistemlerinin doğru çalışması için gereklidir.

Bu menü doğru kullanıldığında eksik tablolar güvenli şekilde tamamlanır, bağlantı sorunları hızlı bulunur, yedekler düzenli takip edilir, SQL hataları analiz edilir ve panel modülleri daha stabil çalışır. Yanlış kullanıldığında ise oyuncu verisi bozulabilir, market/ödeme sistemi aksayabilir, karakter/item kayıtları zarar görebilir veya tüm sunucu geri dönüşü zor bir duruma düşebilir.

En sağlıklı kullanım için Database Yönetimi menüsü sadece teknik yetkililere açılmalı, her işlem öncesi yedek alınmalı, doğru database seçimi kontrol edilmeli, SQL işlemleri loglanmalı, installer işlemleri dikkatle yapılmalı ve canlı sunucuda her değişiklikten sonra ilgili modüller test edilmelidir.

Bu makale PvPSunucusu için özel olarak hazırlanmıştır.