Veri tabanı sunucularındaki yetersiz disk alanı, Toyota otomobil üretiminin Ağustos ayı sonlarında Japonya’daki 14 fabrikada 36 saat süreyle durmasına neden oldu.
Peki böyle bir durum nasıl ortaya çıkıyor? Burada oldukça muhtemel olan şey, veritabanı kapasitesi planlamasında ve yeterli depolamanın sağlanmasında bir başarısızlıktır.
Bu genellikle üst düzey yöneticilerin radarına girebilecek bir faaliyettir, ancak işler ters giderse sonuç net bir şekilde hissedilecektir. 14 Toyota fabrikasında bir buçuk gün boyunca üretim kaybının ne kadar olacağı konusunda herhangi bir tahmin oldukça büyük olmalı.
Peki ne oldu? Toyota, suçun siber saldırı olmadığını belirten bir basın açıklaması yayınladı. Bunun yerine şöyle deniyordu: “Sistem arızası, parça siparişlerini işleyen birden fazla sunucunun kullanılamamasından kaynaklandı.” Bu, Toyota’nın ünlü yalın/tam zamanında üretim sisteminin kritik bir parçası. “[R]arızanın meydana gelmesinden bir gün önce yani 27 Ağustos’ta rutin bakım çalışması yapıldı. Bakım işlemi sırasında veri tabanında biriken veriler silinip düzenlendi ve yetersiz disk alanı nedeniyle hata oluştu ve sistemin durmasına neden oldu.”
Basın bülteninde şöyle devam edildi: “Bu sunucular aynı sistem üzerinde çalıştığı için yedekleme fonksiyonunda da benzer bir arıza meydana geldi.”
Buradaki anahtar, veritabanı kapasitesi planlamasındaki başarısızlığa benzeyen şeydir. Bir veritabanındaki veriler “silinmiş ve organize edilmişse” (muhtemelen “yeniden organize edilmiş” anlamına gelir) bu muhtemel sorun olacaktır çünkü verilerin silinmesi, daha küçük bir veritabanı dosyasıyla sonuçlanmaz ve hatta büyüyebileceğini bile görebilir.
Ayrıca, üretim ve yedek depolamayı ayırmaya ilişkin temel risk azaltma önlemi de gözden kaçırılmış gibi görünüyor, ancak bunu şimdilik bir kenara bırakacağız.
Veritabanı boyutlandırma – veritabanı depolama ihtiyaçlarının tahmini – ve gerekli depolama kapasitesinin sürekli olarak sağlanması uygulaması olan kapasite planlaması, veritabanı yöneticileri için temel becerilerdir.
Kapasite planlaması sıradan bir kişinin hayal edebileceğinden daha karmaşıktır çünkü veritabanı dosyalarının boyutu başka bir etki yaratmadan ihtiyaca göre büyüyüp küçülmez.
Öncelikle (ilişkisel) bir veritabanı yalnızca bir veritabanı değildir. “Veritabanı”, tahsis edilmiş satır ve sütunların ve birden fazla ve bağlantılı tablonun tanımlandığı bir veritabanı dosyasından oluşur. Ancak SQL Server’ın TempDB dosyaları gibi geçici dosyalar da vardır. Ayrıca, sık kullanılan belirli satırlara, tüm veritabanı etkinliğini kaydeden günlük dosyalarına ve veritabanı ve ilgili uygulamalar tarafından oluşturulan yedeklemelere hızlı erişime olanak tanıyan dizinler de vardır.
Ayrıca, farklı tedarikçilerin veritabanı sistemleri bu temel öğelerin farklı uygulamalarına sahiptir ve aynı nominal veritabanı boyutu için farklı depolama kapasitesi hacimlerini işgal edebilir.
Örneğin SQL Server’da 20.000 node (host, sunucu vb.), 20 GB veritabanı dosya boyutu, log dosyaları, TempDB dosyaları ve yedeklemeler dikkate alındığında 46 GB gerektirir. Oracle ve PostgreSQL’deki eşdeğer veritabanı dosyası boyutu sırasıyla 90 GB ve 26 GB yer kaplayacaktır.
Toyota’nın kendi sorunlarının nedeni olarak tanımladığı veritabanındaki silme işlemleriyle ilgili sorun, veritabanı silme işleminin dosya boyutunu küçültmemesidir. Bir satır kaldırılırsa, ona ayrılan alan kaldırılmaz. Sadece kullanılmamış olarak işaretlendi. Veritabanı boyutu, başlangıçta yapılandırıldığında ayarlanır ve kullanım ömrü boyunca periyodik olarak sıfırlanır, ancak önemli olan, alanın tahsis edilmesi ve bu şekilde kalmasıdır; öncelikle depolama ihtiyaçlarının aniden büyük küçülme ve büyüme dönemleri nedeniyle bunaltılmamasını sağlamak için. Veritabanlarının asla küçülmemesi DBA dünyasının değişmez bir emridir.
Günlük ve geçici dosyalar
Ayrıca, Toyota’nın ima ettiği silme ve yeniden düzenleme sırasında ve genel olarak bakım sırasında olduğu gibi, işlemlerde ani bir artışla aniden hacim kazanabilen günlük ve geçici dosyalar var. Toyota’nın başına gerçekten böyle bir şey gelip gelmediğini bilmemiz mümkün değil, ancak bu teorik bir olasılık.
Buna ek olarak, depolama kapasitesi gereksinimlerine eklenecek çoğaltma ve anlık görüntüler potansiyeli de vardır. Bu arada, artan disk kullanımı erişim sürelerinin uzamasına neden olabilir ve RAID yapılandırmaları depolama hacminin büyümesine katkıda bulunabilir.
Toyota’nın (sınırlı) açıklamasının bir başka anlamı da diğer bazı olası temel kusurlara işaret etmektedir. Bunlar arasında geçici dosyaların ayrı sürücülerde bulunmayabileceği, önerilen en iyi uygulama olan, yedeklemelerin üretim verileriyle aynı sürücülerde olduğu (önerilmez) ve hatta üretim sistemi veritabanı depolamasının doğrudan bağlanan sunucu depolamasında olduğu yer alır. Durumun ikincisi olup olmadığını bilmiyoruz; teoride tamamen yeterli sunucuda veya hiper bütünleşik altyapıda olabilir – ancak yüksek performanslı paylaşımlı SAN depolama, kritik veritabanı dağıtımları için çok uygundur.
Genel olarak, burada biraz spekülasyon yapmak zorunda kaldık. Toyota’nın iletişimi oldukça samimiydi ancak bilmediğimiz çok şey var. Sonuç olarak, şirket bazı kritik sistemler için veritabanı boyutunda büyümeyi bir şekilde düzgün bir şekilde planlayamadı ve bu, birçok kuruluşun alabileceği bir ders.