Coğrafi Veri Tabanı Bakımı ve Muhafazası
Saygıdeğer bir büyüğümün sarf ettiği ve benim de zamanla kendisine daha çok hak verdiğim bir sözü var: “Sana hizmet edecek şeye iyi bak”. Hayatta sahip olduğumuz çoğu şeyin aslında bakıma ihtiyacı vardır ve gereken bakımı gösterdiğimizde bunlar, bize daha uzun sürelerde hizmet edebilir ve aradan zaman geçmiş olmasına rağmen ilk günkü gibi görevlerini yerine getirmeye devam edebilirler.
Sektörümüzde hali hazırda bilinen ve kullanılan İlişkisel Veri Tabanı Yönetim Sistemleri (İVTYS) ile bütünleşik olarak çalışan Enterprise Geodatabase’ler de muhafaza edildikleri süre boyunca belli aralıklarla bakım gerektirirler. Geodatabase, Esri tarafından ortaya koyulmuş bir veri depolama modelidir. Enterprise Geodatabase’ler de ilgili İlişkisel Veri Tabanı Yönetim Sistemleri’nin sağladığı faydalardan yararlanmamızı sağlarken aynı zaman da İVTYS’lerin getirdiği yönetimsel sorumlulukları da omuzlarımıza yükler. Örneğin; verinin belli aralıklarla yedeklenmesi ya da performansın belli bir düzeyde kalmasını sağlamak amacıyla belli başlı değerlerin sürekli olarak güncel tutulması gerektiği gibi sorumluluklardır bunlar. Geodatabase’in bakımına dair bu görevler yerine getirilmediği taktirde, kullanıcılarınızdan bir süre sonra, sisteme dair olumsuz geri dönüşler almanız kaçınılmazdır. Bunların yaşanmaması için yapılması gereken, önceden düşünülmüş ve planlanmış görevlerin zaman içerisinde yerine getirildiğinden emin olmaktır. Tıpkı konunun uzmanı İş Ortaklarımızın yerine getirilmesini sağladığı bu Best Practice’ler ile Kurumsal Coğrafi Veri Tabanlarınızın bakımlarının yapıldığından emin olunduğu gibi.
Birazdan aşağıda paylaşacaklarım, bir Enterprise Geodatabase’in bakımı ve muhafazası için gerekli standart görevleri içermektedir.
- Öncelikle veri tabanı düzeyinde yedekleme işlemlerinin yapılması gerekmektedir. Günü geldiğinde verinin kaybolma ya da bozulma ihtimaline karşın, Veri Tabanından sorumlu kişi tarafından yapılan periyodik yedeklemeler yardımıyla verinin geri getirilebildiğinden emin olunmalıdır. Geodatabase, ilgili İVTYS yönetim sistemiyle bütünleşik olarak çalıştığından dolayı yedekleme işlemleri için bu İVTYS’nin yedekleme özellikleri kullanılacaktır.
- Yukarıda da bahsettiğimiz gibi sistemlerinizdeki performansın beklenen düzeylerde kalması için belli başlı değerlerin gerektiği gibi güncel kalması sağlanmalıdır. Peki nedir bu “değerler”?
Veri tabanlarını en basit anlamıyla açıklamak gerekirse birçok bileşen ile birlikte tablolar bütününden oluşan bir yapıdır. Tablolar içerisinde bazen onlarca bazen de milyonlarca kayıt bulunabilir. Hal böyle olunca, tablolar üzerinde gerçekleştirdiğimiz sorgular aracılığıyla ulaşmaya çalıştığımız bilgiye giden yol uzayabilir. Bu durum bir problem haline de gelebilir. Peki, veri tabanlarındaki böyle bir yapıda nasıl oluyor da bu problem (çoğu zaman) yaşanmıyor hiç düşündünüz mü? Sistemlerde kullanılan bilgisayarın, gelişmiş çok hızlı bilgisayarlar olması sayesinde mi? İşlemci, Ağ ve Depolama teknolojilerinin ulaştığı nokta mı? Evet, bunların etkisi yadsınamaz ancak etki eden ağırlıklı faktör bunlar değil. Böyle olsaydı neden günümüzde kullanılan sistemlere dair performansın ilk günkü gibi olmadığına dair şikâyetler gelsin ki?
SQL, bildirimsel bir dildir – yani SQL aracılığıyla oluşturulan her bir sorgu ile SQL Engine’den neyi yapmasını istediğimizi tanımlarız, nasıl yapması gerektiğini değil. Peki o zaman soru şu; Türkiye içerisindeki her bir yapı detayını içeren bir veri bütününü, ArcGIS yazılımları ve bir Enterprise Geodatabase içerisinde ilgili İVTYS aracılığıyla depoladığımızı düşünelim. Bu veri bütününden sadece tek bir yapıya ait olan kat bilgisini ArcMap aracılığıyla ilgili Enterprise Geodatabase’den sorguladığımızda, veri tabanına neyi yapmasını gerektiğini mi yoksa nasıl yapması gerektiğini mi söylemiş oluruz? Doğru cevap; neyi yapması gerektiğini söylemiş oluruz. O zaman veri tabanımıza, milyonlarca satırlık kayıtlar içerisinden bu bilgiyi olabilecek en hızlı şekilde nasıl bulup, ArcGIS kullanıcısına geri göndereceğini kim söyleyecek? Bu görevi, veri tabanları içerisinde bulunan Query Optimizer bileşeni üstlenmektedir, ArcGIS yazılımları değil. Query Optimizer’lar, veri tabanı içerisinde bulunan İstatistikler ve İndeksler yardımıyla bilgiye ulaşmak için en düşük maliyetli optimum yolu belirlemek için çalışırlar. Bunun için de birçok Execution Plan ortaya çıkarırlar ve maliyet hesabıyla birlikte en uygun yolun belirlenmesini sağlarlar.
Bu bilgilerden yola çıkarak şöyle bir benzetme yapabiliriz; veri tabanı içerisinde bulunan Query Optimizer, doğru kararların alınmasını sağlayan bir beyin niteliğindedir. Bu beyin’in doğru karar almasını sağlayan besinler ise veri tabanındaki İstatistikler ve İndekslerdir. Bu bölümün başında bahsi geçen “değerler” de işte bunlardı.
Burada bilmeniz gereken iki önemli şey var. Bunlardan birincisi, bu değerler, özellikle hatırı sayılır güncellemelerin yapıldığı Versiyonlu Geodatabaselerde eskirler ve güncelliğini kaybederek Query Optimizer’ın veri tabanında beklenen düzeyde performansta kararlar almasını engellerler. Yani en nihayetinde, siz değerli ArcGIS kullanıcılarının yazılımlarımızdaki çalışmalarınızda beklenmedik performans düşüşlerine maruz kalmasına sebep olabilir. Bilmeniz gereken ikinci konu ise optimum performansta çalışmanızı sağlayacak ortama katkıda bulunmak için Geodatabase içerisindeki Veri Sahiplerine, Geodatabase’in Yöneticisine ve Veri tabanı Yöneticisine burada önemli bir rol düşmektedir. Bu rol de, veri tabanındaki bu İstatistik ve İndekslerin güncelliğinin korunmasıdır. Bunun yerine getirilebilmesi için ArcGIS içerisinde hali hazırda kullanılabilecek geoprocessing araçları mevcuttur. Rebuild Indexes aracı yardımıyla hem öznitelik hem de mekansal indekslerin yeniden oluşturulmasını sağlayabilirsiniz. Veri tabanlarında ve Enteprise, Workgroup ve Desktop geodatabaselerde çalıştırabileceğiniz bu aracı özellikle hatırı sayılır veri yükleme, silme, güncelleme veya compress operasyonu gerçekleştirdiğiniz zamanlarda çalıştırmanız önerilmektedir. Yine aynı durumlarda, veri tabanındaki İstatistikleri güncelleyecek olan Analyze Datasets aracını Enterprise Geodatabaseleriniz için çalıştırabilirsiniz.
Bu araçların hangi sıklıklarla çalıştırılması gerektiği; iş akışınızdaki veri yükleme, silme, güncelleme ve compress operasyonlarının sıklığından doğan veri tabanındaki değerlerin ve tabloların mevcut durumuna bağlıdır. Dolayısıyla yapılabilecek en iyi uygulama, buraları gözlemlemektir. Veri tabanınızdaki, istatistikleri ve kullanılabilirlik durumunu ArcGIS Monitor DB Counter yardımıyla gözlemleyerek ve gerektiğinde uyarı mekanizmalarından faydalanarak doğru karar ve aksiyonları zamanında alabilirsiniz. Böylelikle Enterprise Geodatabase’iniz ile yürüttüğünüz operasyonu rahatlatarak ve performansı optimum düzeyde tutabilirsiniz. ArcGIS Monitor ile ilgili Türkçe dilinde yazılmış iyi bir blog yazısına ulaşmak için buraya tıklayabilirsiniz ya da Esri Türkiye Blog sayfasını takip edebilirsiniz.
- (Geleneksel) Versiyonlu bir geodatabase içerisinde bulunan verilerde güncelleme yapıldıkça stateler ve delta tablolarındaki satırlar büyür dolayısıyla da performans düşmeye başlar. Bunu engellemek için geodatabase’inizde Compress operasyonunun yapılması gereklidir. Compress sayesinde bir versiyon tarafından artık referans gösterilmeyen statelerin silinmesini ve delta tablolarındaki ilgili satırların base tabloya gönderilmesini sağlar. (Geleneksel) versiyonlu bir geodatabasede oldukça önemli olan bu operasyonun gerçekleştirilme sıklığı bir üst maddede belirttiğim gibi iş akışınızdaki veri yükleme, silme ve güncellemeye bağlıdır. Compress işleminin doğru olarak ne zaman gerçekleştirilmesi gerektiğinin kararının alınmasında ve aslında daha fazlasında fayda sağlayabilecek araç yine ArcGIS Monitor Delta, state, state lineage vb. ilgili tabloların gözlemlenerek ArcGIS Monitor içerisindeki uyarı mekanizmaları yardımıyla proaktif bir şekilde karar almanızı sağlayabilir. Böylelikle operasyonunuzda rutin olsun ya da olmasın geodatabase’inizde tutulan verinizin durumunun kontrolü ve daha fazlası elinizde bulunmuş olacaktır.
- Eğer çalışma ortamınızda saha çalışanları varsa ya da ana ofise bağlı alt ofisler bulunuyor ve replica geodatabaseler ile çalışıyorlarsa verinizi muhafaza etmek için ana veri tabanından veriyi hem içe hem de dışarı aktarmanız ve bu replikaları yönetmeniz gerekecektir. Replika geodatabaseler de nihayetinde birer geodatabase olduğundan ve ilgili İVTYS’inde tutulduğundan dolayı yukarıda paylaşmış olduğum bakım ile ilgili notlar, bunlar için de geçerli olacaktır. Lütfen, bunu dikkate alınız.
- Gel gelelim belki de en önemli konuya, geodatabaselerin yükseltilmesi konusu. Her ne kadar bu konu çoğu kimse tarafından yeterince önem görmese de aslında işin detayını bilenler tarafından durum böyle değildir. Çünkü geodatabaselerin yükseltilmesi, sadece yeni gelen fonksiyonelliklerin kullanılabilmesi için değil aynı zaman da yazılım üreticileri tarafından tespit edilen birçok hatanın da giderilmesi için gerçekleştirilmelidir. Bu işlemin gerçekleştirilmesi sırasında dikkat edilmesi gereken noktalar her bir İVTY sistemine göre değişiklik gösterebilir. Dolayısıyla geodatabaselerinizi tuttuğunuz ilgili veri tabanı üreticisine ait Esri dokümanlarındaki yönergeleri takip etmeniz önerilmektedir.
Ve son olarak, insana dayalı hatalara maruz kalmamak adına insana bağlı Enterprise Geodatabase bakım ve muhafaza görevlerinden mümkün olduğunca lütfen kaçının.
Faydalı bağlantı: