Vagrant Virtualbox, VMWare gibi sanallaştırma teknolojilerinin kullanımını kolaylaştıran bir provisioning aracıdır.

Tek bir Vagrantfile dosyası ile bir veya birden fazla sanal makinenin tüm ayarlarını ve kurulum detayları tanımlanıp  kullanılabilir.

Vagrant kendi deposundaki Box’lar ile çalışmaktadır. Bu Box’lara Kaynak: Vagrant Box Arama adresinden ulaşılabilir. Buradaki Box’ların ihtiyaçlar doğrultusunda modifiye edilerek özel olarak oluşturulabilmesi de mümkündür.

Vagrantfile Nedir?

Vagrantfile, Vagrant üzerinde yapmakistenilen konfigürasyonlar alıştırmak istenilen scriptlerin yazıldığı .file uzantılı bir dosyadır. Vagrant kurulumu tamalandıktan sonra Vagrant bu dosya üzerinden çalıştırmak istenen sanal makineleri ayağa kaldırır.

Vagrant Kurulumu

Vagrant’ı kullanabilmek için bir adet sanallaştırma yazılımı kullanılması gerekmektedir. Kendi kurulumunuzda www.virtualbox.org/wiki/Downloads sitesinden indirebileceğiniz Oracle VirtualBox ürününü tercih edebilirsiniz. Kullanacağınız işletim sistemi ile uyumlu olan VirtualBox sürümünü indirip kurabilmeniz mümkündür.

Vagrant’ı kendi web sitesi olan Kaynak: HashiCorp – Vagrant Kurulumu adresi üzerinden kurulumunu yapmak istediğiniz işletim sistemini seçerek indirebilirsiniz, örneğin devamında Windows AMD64 sürümü ile devam edilmiştir.

İndirdiğiniz vagrant_2.4.0_windows_amd64.msi dosyasını çalıştırarak kuruluma geçebilirsiniz. Lisans sözleşmesini kabul edip  ardından Vagrant’ın kurulacağı konumu seçtiğinizde kurulum başlayacaktır.

Kurulum tamamlandıktan sonra bilgisayarınızda herhangi bir konumda bir dizin oluşturabilirsiniz, örnek kullanacağımız  dosya masaüstünde Vagrant adı altında olacak.

Komut istemi üzerinden cd komutu ile Vagrant kurulumunu yapacağımız dizine gidip vagrant init komutu ile kullanacağımız Vagrantfile oluşturulur.

vagrant init komutu ile oluşturduğumuz dosyanın içinde # ile kullanılan commentlerin altında temel konfigürasyon ayarlarını görebiliriz.

Buna alternatif olarak Kaynak: Vagrantfile Generator Aracı sitesini kullanarak da belli konfigürasyonları belirtip Vagrantfile generate edebilirsiniz.

Kullanacağımız Vagrantfile konfigürasyonlarını not defteri üzerinden tamamlandıktan sonra dosyamızı kaydedip çıkıyoruz. Örnek olarak kullanacağımız Vagrantfile aşağıda yer almaktadır.

Komut istemi üzerinden Vagrant’ı çalıştıracağımız komuta gidip vagrant up komutu ile sanal makine kurulumumuza başlarız.

Kurulumumuz tamalandıktan sonra makinemiz VirtualBox üzerinde yer alacaktır.

Komut istemi üzerinden vagrant-ssh komutunu kullanarak herhangi bir terminale ihtiyaç duymadan da ssh bağlantısı sağlayabiliriz.

Vagrant ile Sanal Makine Otomasyonu

Vagrantfile kullanarak daha komplike ve otomize makineler yaratmak da mümkündür, aşağıda yer alan script üzerinden bazı  vagrant özelliklerine değineceğiz.

İlk satırda girdiğimiz config tanımlama satırı sonrasında config.vm.define ‘xxx’ do |xxx| ile tek bir makine dahilinde konfigürasyon girip makine kurulumu sağlayabiliriz, bu satırı birden fazla farklı makine için tanımlayıp tek bir Vagrantfile ile birden fazla makine kurabiliriz.

Vagrant’lar ihtiyaç doğrultusuna göre plugin de içerebilir.

Örnek olarak VirtualBox’a disk ekleme, depolama boyutu belirleme, volume group ekleme gibi özellikleri vagrant plugin install vagrant-persistent-storage komutunu kullanarak Persistent Storage plugini ile Vagrantfile içerisinde .persistent_storage tanımı ile kullanabiliriz.

Plugin’e ihtiyaç duymadan, kuracağımız makine içerisinde çalıştırmak için Bash Scriptleri de kullanabiliriz.

Bash Scriptleri;

<makine_tanımı>.vm.provision :shell, :inline => $<script_adı> ile Vagrantfile içerisinden inline bir şekilde ya da

<makine_tanımı>.vm.provision “shell”, path: “<sh_script_lokasyonu>” ile dışarıdan bir sh scriptini çağıracak şekilde çalıştırabiliriz.

Kullandığımız scriptlerde her bir makine için ayrı ayrı userlar oluşturma, /etc/hosts dosyalarını editeleme ve Persistent Storage plugini ile eklediğimiz diskleri makinelere mount etme işlemlerini gerçekleştirebiliyoruz.

Yukarıda belirtildiği gibi, Vagrant, sanallaştırma ve otomasyon süreçlerini basitleştirerek iş akışlarınızı hızlandırır. Ancak, bu süreçler karmaşık ve zaman alıcı olabilir.  Vagrant’ın kurulumu, konfigürasyonu veya otomasyon süreçleriyle ilgili daha fazla bilgi ve destek için GTech’in Sistem ve Veritabanı uzmanları ile iletişime geçebilirsiniz.

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post Vagrant Nedir? Vagrant ile Nasıl Sanal Makine Otomasyonu Yapılır? appeared first on GTech.

Pg_buffercache, shared buffers içeriğini incelemeyi sağlayan bir PostreSQL extension’udur. Bu extension’u kullanarak belirli bir objenin önbelleğe alınıp alınmadığını anlayabilirsiniz. Ayrıca önbelleğe alma ile alakalı performans sorunlarını gidermenize de yardımcı olabilir.

Pg_buffercache Kurulumu

Öncelikle PostgreSQL sunucunuzda contrib paketinin kurulu olması gerekmektedir. Contrip paketi ile birçok PostgreSQL extension’unun source dosyasını sunucunuza almış olursunuz. Daha sonra ise PostgreSQL ile veri tabanına bağlanıp pg_buffercache extension’unu create edebilirsiniz.

Pg_buffercache Kullanımı

Spesifik bir tablo için istatistikleri görüntülemeyi deneyeceğiz. Testlerimiz için PostgreSQL veri tabanında employee adında bir tablo oluşturduk ve içerisine bir milyon satırlık insert gerçekleştirdik. İlk adım olarak tablomuzun relfilenode’unu bulacağız. Tablo ve indeks gibi database objeleri OID’ler üzerinden yönetilirken içerdiği data dosyaları relfilenode değişkeni aracılığıyla yönetilir. Tablo ve indexlerin relfilenode ve OID değeri temelde aynıdır, fakat relfilenode değişkeni TRUNCATE, REINDEX, CLUSTER komutları kullanıldığında değişir. Tablomuzun relfilenode’unu aşağıdaki komutla bulabiliriz:

Relfilenode’u bulduktan sonra, OS cache istatistiklerini aşağıdaki sorgu ile görebiliriz:

Bu komut sonucunda aşağıdaki kolonları göreceğiz:

Mevcut Veritabanıyla İlişkili Objelerin Kullandığı Buffer (arabellek) Sayısını Görmek

Alttaki sorgu ile mevcut veritabanınızda önbelleğe(cache) alınmış top 10 obje için buffer istatistiklerini alabilirsiniz:

Veritabanlarının Cache’e (önbellek) Alınmış Block Sayılarını Görmek

Aşağıdaki sorgu ile mevcut veritabanınızın ve eğer varsa diğer veritabanlarınızın cache block sayılarını gözlemleyebilirsiniz:

Pg_buffercache Performance Tuning

Şimdi örnek bir senaryo ile buffer kullanımının performans üzerindeki etkisini gözlemleyeceğiz. Aşağıdaki örnekte ilk olarak veritabanımızı restart ettikten sonra (cold cache) ’employee’ tablosunun pg_buffercache kullanılarak buffer’a (önbelleğe) alınıp alınmadığını kontrol ettik. Gördüğünüz gibi pg_buffercache çıktısında sıfır kayıt var. 

Daha sonra ‘explain analyze’ çalıştırdık ve sorgu 255 ms civarında sürdü. (cold cache)

Daha sonra pg_buffercache kullanarak buffer içeriğini kontrol ettik ve bu sefer tablonun buffer’a alındığını gözlemledik. 

Daha sonra aynı sorguyu tekrar çalıştırdık ve bu sefer 156 ms’de tamamlandı. (warm cache) 

Bu sonuçlara baktığımızda önbelleğe alınan objeler üzerinde çalıştırılan sorguların çok daha hızlı sonuç döndürdüğünü görebiliriz.

Pg_buffercache gibi PostgreSQL özelliklerinin ve uzantılarının etkili bir şekilde kullanımı, veritabanı yönetiminde performansın optimize edilmesi için oldukça önemlidir. 

GTech olarak, sağlık, bankacılık, telekomünikasyon, perakende, enerji, kamu gibi birçok sektörde sistem ve veritabanı yönetimi hizmeti sunuyoruz. Siz de PostgreSQL üzerinde veri önbellekleme, performans analizi veya diğer konularda daha detaylı bilgi sahibi olmak için bizimle iletişime geçebilirsiniz.

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post PostgreSQL Buffer Cache Nedir? Nasıl Kurulur? appeared first on GTech.

 Ortam Bilgileri

192.168.1.35 – pgpool = Bu sunucuda pgpool ve boş bir postgresql veritabanı bulunmaktadır. Bu sunucudan 192.168.1.36 ve 192.168.1.37 sunucularına connection pooling yapılmaktadır. 

192.168.1.36 – node1  = Primary veritabanının kurulu olduğu node1 sunucu

192.168.1.37 – node2  = Replica veritabanının kurulu olduğu node2 sunucu

 Pgbench Kurulumu

 192.168.1.35 – pgpool sunucusunda:

 PostreSQL contrib paketi ile birlikte pgbench binary dosyaları sunucuya kurulmuş oluyor.

 Sunucuda PostreSQL servisinin ayakta olduğundan emin olup psql ile veritabanına bağlanıp pgbench testlerini yapacağımız example veritabanımızı oluşturacağız.

(3 rows)

 Example veritabanımızı oluşturduk. Şimdi pgbench ile bu veritabanını hızlıca test’e hazır hale getirelim. Bu komut ile pgbench example veritabanında örnek tabloları oluşturup bunlara data yazacak. 

Default olarak, pgbench yukarıdaki tabloları yukarıda gösterilen satır sayısıyla oluşturacaktır. Bu, basit bir 16MB veritabanı oluşturur.

 Performans değişikliklerini ölçmek için pgbench kullanacağımız için, 16 MB’lık küçük bir veritabanı testimizi kurgulamak için yeterli olmayacaktır. İşte burada -s (ölçekleme) seçeneği devreye girmektedir.

-s seçeneği, her bir tabloya girilen satır sayısını çarpmak için kullanılır. Yukarıdaki komutta 50’lik bir “ölçeklendirme ” seçeneği girdik. Bu, pgbench’e varsayılan boyutun 50 katı büyüklüğünde bir veritabanı oluşturmasını söyledi.

Bu, pgbench_accounts tablomuzun artık 5.000.000 kayda sahip olduğu anlamına geliyor. Ayrıca, veritabanı boyutumuzun yaklaşık olarak 800MB (50 x 16MB) olduğu anlamına gelir. Kontrol edelim.

Testlerimizi çeşitlendirebiliriz. Örneğin aşağıdaki komutla example veritabanına pgbench’i çağırırken, komuta epeyce seçenek ekleyebiliyoruz. İlki, bağlanılacak istemci sayısını tanımlamak için kullanılan 

 -c (client). Bu test için, pgbench’e 10 client ile test etmesi için 10 yazdık.

Böylece pgbench testleri yaparken veritabanında 10 farklı session açar.

Sonraki seçenek -j (threads) sayısıdır. Bu pgbench için çalışan thread sayısını tanımlamak için kullanılır. Aşağıdaki komutta 2 değerini belirttik. Bu, pgbench’e test sırasında iki thread başlatmasını söyleyecektir.

Üçüncü seçenek -t’dir (transactions), “çalıştırılacak transaction sayısı” olarak tanımlanır. Aşağıdaki komutta 10.000 değerini verdik. Bunun anlamı, her müşteri oturumunun 10.000 işlem yürüteceğidir.

Özetlemek gerekirse, bu komut ile 10 istemciden toplam 100.000 transaction gerçekleştirilmesini simüle etmiş olacağız.

Pgbench ile Pgpool Yük Testi 192.168.1.35 – pgpool sunucusunda:

Pgpool default olarak 9999 portunu kullanmakta. Bu port’u ve ek olarak gideceği db ve db’de kullanacağı user bilgilerini verdiğimizde testleri gerçekleştirebileceğiz. Ek olarak bu testler sonucunda pgpool’un stres altındaki dayanımını kontrol edip yüksek connection sayısı nedeniyle yaşanan pgpool hang probleminin çözümünü de gerçekleştireceğiz.

Aşağıdaki komutla pgpool üzerinden testlerimizi gerçekleştirelim. Komutta -U monitor ile kullanılacak user’ı belirttik. -p 9999 ile pgpool’a bağlantı sağlayacağı port’u, -i (initialize) ile bağlandığı veritabanında gerekli tabloları oluşturmasını, -s 100 monitor ile de ‘monitor’ veritabanına bağlanıp 100’lük bir ölçeklendirme yapmasını istedik.

 -s 100 verdik yaklaşık db boyutumuz 1.6 GB(100x16MB) olacak

 Tabloları oluşturup insert’leri yaptırdık ve bir sorun yaşamadık. Şimdi db sessionları ile bir test yapalım. Bu komutla yine monitor veritabanına pgpool üzerinden gidip 10 session ve 2 thread ile 1000 adet transaction simüle edilecek.

Aşağıdaki komutla 20 session monitor db’sine 150 saniye boyunca sürekli select atacak, her transaction için yeni connection sağlanacak. Komutu çalıştırmadan önce ve çalıştırdıktan birkaç saniye sonraki select count’lar görsellerdeki gibidir.

Bu komuttaki parametrelerin anlamları şu şekilde listelenmektedir (pgbench –help ile bu özellikler görüntülenebilir) :

-n : test öncesinde vacuum çalıştırılmasın,

-S : select-only transaction gerçekleştirilsin,

-p : port,

-c : client sayısı,

-C : her transaction için yeni connection açılsın,

-T : test’in kaç saniye boyunca devam ettirileceği.

 Aynı testi 4 saniyede tamamlanacak şekilde gerçekleştirip sonucu görelim, pgbench test tamamlandığında bize aşağıdaki gibi bir çıktı üretecek.

 Bu komutu 32 ve üzeri client olacak şekilde güncellediğimizde standart konfigürasyonda pgpool yeterince child process oluşturamıyor ve hang oluyor. Bunun için num_init_children (default değeri 32) adlı pgpool parametresini arttırmamız gerekiyor. Fakat bu parametreyi artırdığımızda aslında db’lere gidecek connection sayısını da artırıyoruz. Bu sebeple bu değeri artırırken dikkatli olunmalı, bu değer çok yükseltilirse db’ye kabul edebileceğinden daha fazla connection isteği giderek db’yi de hang edebilir. 

 Bu parametreyi artırdıktan sonra pgpool’u restart edip testi tekrar yaptığımızda hang probleminin yaşanmadığını görüyoruz.

Yazımızda bir PostgreSQL aracı olan pgbench ile ilgili bilgileri inceledik. GTech olarak sadece performans testleriyle sınırlı kalmadan, veritabanı mimarinizin tamamını değerlendiriyor, optimizasyon önerileri sunuyor ve size en iyi performansı sağlamak için gereken değişiklikleri uygulamanıza yardımcı oluyoruz. PostgreSQL veritabanınızın tam potansiyeline ulaşmasına yardımcı olmak için Sistem ve Veritabanı uzmanlarımızla iletişime geçebilirsiniz.

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post PostgreSQL – Pgbench Nedir? Nasıl Kurulur? appeared first on GTech.

PostgreSQL veri tabanlarında işlem gören tablolarda değiştirilen satırlar “dead tuple” olarak işaretlenir ve bu satırlar kullanım dışı kalır. Daha sonra “vacuum” adlı bakım işlemi ile bu “dead tuple”lar yeniden kullanılabilir olarak işaretlenir. Örneğin bir tabloda “delete” işlemi gerçekleştirildiğinde, silinen satır “dead tuple” olarak işaretlenir ve gizlenir. Bir güncelleme gerçekleştiğinde ise; PostgreSQL güncellenecek satırı kullanım dışı bırakıp gizler ve yeni halini “insert” eder. “Vacuum” kullanılmadığı taktirde bu uygulama yöntemi veri tabanı performansında ciddi düşüşlere yol açacaktır. “Vacuum” işlemi ile bu “dead tuple”lar yeniden kullanılabilir olarak işaretlenir ve disk üzerindeki “data page” temizlenir. Bu işlem diskte boş alan yaratmaz. PostgreSQL 8.1 versiyonuyla (2005) tanıtılan, 8.3 versiyonundan itibaren varsayılan olarak etkinleştirilen “autovacuum” özelliği ile “vacuum” işlemi otomatik olarak çalışabilir hale gelmiştir. Özellikle veri tabanında yoğun “transaction” gerçekleşmeye başladığında “autovacuum”un devreye girdiğini görebilirsiniz.

Wraparound Nedir?

Yoğun kullanılan bir veri tabanımız olduğunu ve “autovacuum”u devre dışı bıraktığımızı düşünelim. Nihayetinde bu veri tabanı “Transaction ID” sayacınında limit değere ulaşacaktır. Bu değere ulaşıldığında, postgre’nin mimarisi olan Multi-Version Concurrency Control (MVCC) şematiği doğru şekilde çalışamamaya başlar ve “vacuum” işlemleri “DML” işlemlerine yetişemez. “Transaction ID” sayacı “transaction”lara “unique” değerler atamak için kullanılır ve alabileceği maksimum değer 4.2 milyardır. Limit değer ise 2 milyar seviyelerindedir, sayaç limite ulaştığında yeni işlemler için atanacak “unique” bir değer bulunamadığından veri tabanı aşağıdaki hatayı vermeye başlayacaktır:

Önlem alınmadığı taktirde “force shutdown” gerçekleşecek ve veri tabanı kapanacaktır. Bu, ciddi veri kayıplarına yol açabileceği için oldukça tehlikeli bir durumdur. Eğer “force shutdown” gerçekleşmezse geçmişte işlenmiş “transaction”lar gelecekte görünmeye başlayabilir ve silinmiş satırların geri gelmesi, güncellenmiş satırların eski haline dönmesi, yetki kısıtlama ihlalleri gibi anormal durumlarla karşılaşılabilir.

Vacuum İşlemi

“Vacuum”, “dead tuple” temizliği yapan bakım işlemidir. İki modu vardır;

1. Concurrent Vacuum

   Herhangi bir erişim engeli oluşturmadan tablolardaki “dead tuple”ları temizler ve yeniden kullanılabilir olarak işaretler. “Vacuum” işlemi sonrasında diskte bir alan kazanımı olmaz.

2. Full Vacuum

   “Concurrent vacuum”dan farklı olarak “full vacuum”, “dead tuple” olarak işaretli alanların çıkarıldığı yeni bir tablo oluşturur ve daha sonra eski tabloyu siler. “Full vacuum” uygulanan tablo “exclusive lock” ile kilitlenir ve “full vacuum” tamamlanana kadar bu tablo üzerinde bir sorgu çalıştırılamaz. “Full vacuum” işlemi sonrasında diskte alan kazanımı olur. Veri tabanının durumuna da bağlı olarak, uzun süredir “vacuum” çalıştırılmamış bir veri tabanında alan kazanımı daha fazla olacaktır.

Wraparound Problemi Nasıl Önlenir?

Her şeyden önce “autovacuum” kapatılmamalıdır, tüm tabloların düzenli şekilde “vacuum” işleminden geçtiğinden emin olunmalıdır. Doğru konfigüre edildiğinde çoğu durumda “autovacuum” yeterli olacaktır ancak bazı durumlarda manuel “vacuum” yapmak da gerekebilir. Bu nedenle sistem düzenli olarak izlenmelidir. Aşağıdaki “select” ile tabloların durumu gözlenebilir ve ihtiyaç duyulan tablo önceden fark edilip manuel “vacuum”” yapılarak “wraparound” probleminin önüne geçilebilir.

PostgreSQL veri tabanlarında “wraparound” problemini açıklayarak nasıl önlem alınacağına değindik. Yeni nesil teknolojilerimizle sunduğunuz Sistem ve Veri Tabanı Yönetimi çözümlerimiz hakkında bilgi almak için bize ulaşabilirsiniz.

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post PostgreSQL Wraparound Problemi Nedir? appeared first on GTech.

1. “Sysadmin” ya da “System administrator” gibi yetkili bir kullanıcı ile uygulamaya giriş yapılır.

2. Sol taraftaki (Main Menu) bağlanılan “user”ın sorumluluklarını gösterir. Dolayısıyla her “user”da farklı sorumluluklar gelebilir. Bu alana “navigator” denilmektedir.

3. Sorumlulukların altında Oracle Application Framework (OAF) ve form ekranları bulunmaktadır. Bunlar Oracle’ın standart ekranları olabileceği gibi “custom” da olabilir. “Navigator” alanından uygulama “user”ı oluşturmak için aşağıdaki form ekranına gidilir.

System Administrator > Security > User > Define

4. Açılan form ekranında sarı renkli alanlar “input”un “entering” modda olduğunu göstermektedir. “User name” alanında iken “F11” tuşuna basıldığında alanlar “gri”ye döner ve “query” moda geçer. 2 tür mod vardır.

Sarı alan 🡪Entering mod

Gri alan 🡪 Query mod

Entering mod: Form üzerinde yeni bir “create” işlemi yapılmak istendiğinde kullanılır.

Query mod: “entering” modda iken geçiş “F11” tuşu ile olur. Bu alanda “search” yapılabilir. Örneğin “GUEST user”ını “user name” alanında “GUE%” yazdıktan sonra “CTRL+F11” tuşuna basıldığında “GUEST user”ı ile alakalı bilgiler gelmektedir.

“Entering” modda iken aşağıdaki ekran görüntüsünde gösterildiği gibi alanlar doldurulur.

a)“User” Bilgileri

“User name” girildikten sonra “password” alanında şifreyi girdikten sonra; Oracle, doğrulamak için şifreyi tekrar yazmasını isteyecektir.

Diğer alanlar opsiyoneldir.

b) Sorumluluk (Responsibility) Alanı

“User”ın hangi sorumlulukları olacağı seçilir, “query” modda iken sorumluluğun ilk kısmı yazıldıktan sonra “TAB” tuşuna basıldığında kendini tamamlar.

c) Kaydet (Save) Butonu

“Save” butonuna tıklayarak bir “user” yaratılır

5. Kontrol (Check) İşlemi

a) Yaratılan “user” ile sisteme giriş yapılır.

b) İlk girişte “password” “reset” alanı gelmektedir. Yeni “password” verilerek “submit” butonuna tıklanır.

c) Sol tarafta sadece bu “user”a ait sorumluluklar (responsibility) gözükmektedir.

Veri tabanı üzerinde uygulama “user”ları “FND_USER” tablosunda depolanmaktadır. Yaratılan “user” aşağıdaki şekilde sorgulanabilir.

SELECT CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN FROM FND_USER WHERE USER_NAME=‘GTECH_USER’;

Sistem ve Veri Tabanı Yönetimi Kıdemli Danışmanı Ahmet Karasan’ın hazırladığı yazıda; Oracle E-Business Suite (EBS) uygulamasında “user” oluşturmayı detaylı bir şekilde anlattık. GTech olarak, 22 yıllık sektör tecrübemizden yararlanarak geliştirdiğimiz son model teknolojilerimizle; Oracle veri tabanı ve EBS destek faaliyetleri ile ilgili hizmetler sunuyoruz. Siz de bu teknolojilerden faydalanmak için bize ulaşın.

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post E-Business Suite (EBS) 12.1/12.2 Application User Oluşturma appeared first on GTech.

Data Guard, Oracle tarafından geliştirilmiş olan felaket kurtarma (disaster recovery) çözümüdür. Veri tabanını felaketlerden ve veri bozulmalarından kurtarmak için kullanılan bir sistemdir. Veriler ana veri tabanından standby veri tabanına sürekli aktarıldığından dolayı; ana veri tabanında herhangi bir problem olması durumunda, hızlı bir şekilde yedek veri tabanına geçiş yapılır. Kısaca Data Guard bir veri tabanının, başka bir veri tabanına anlık olarak kopyasının alınması ve herhangi bir arıza veya felaket durumunda kopya veri tabanının “production” olarak kullanılması şeklinde tanımlanır. Oracle veri tabanı uzmanlığı ile hazırladığımız bu yazımızda Oracle Data Guard Mimarisi ve kurulum aşaması hakkında bilgi verdik.

Data Guard; canlı veri tabanı dediğimiz primary veri tabanında oluşan redo kayıtlarını, yedek veri tabanı dediğimiz standby veri tabanına taşır ve taşınan bu redo veriler, standby veri tabanına “apply” edilerek primary veri tabanının güncel yedeğini oluşturur.

Redo verisi dediğimiz veri; primary veri tabanında meydana gelen “transactionlar” bütünüdür (Insert, Update, Delete, Create, Alter vb.). Primary veri tabanına gelen transactionların standby’a taşınıp, “apply” edilmesi demek; aynı transactionların standby tarafında da çalışması demektir.

LNS (LGWR Network Server);  SGA (System Global Area) ’daki redo buffer alanındaki redo verilerini, ağ üzerinden doğrudan standby veri tabanına iletmek üzere gönderir. Gönderilen redo veriler, standby veri tabanında RFS (Remote File Service) background servisi tarafından alınır ve standby redo log dosyalarına işlenir. Bu dosyalar da redo apply işlemi ile standby veri tabanına işlenir.

Data Guard çalışma şekli, bir transaction üzerinden aşağıda belirtildiği üzere iki farklı madde halinde açıklanabilir.

Synchronous (Senkron) Data Guard

• Veri tabanında bir transaction başlatıldığı zaman; bu işlem öncellikle redo buffer alanına yazılır. Kullanıcı ilgili transaction’ı “commit” ettiği zaman; LGWR (Log Writer) process’i redo buffer alanındaki redo verilerini online redo log’lara yazar ve LNS process’i, redo verilerinin standby veri tabanına yazıldığına ilişkin doğrulama bekler.

(**Redo Log Buffer** Veri tabanı üzerideki bütün değişikliklerin saklandığı alandır ve en geç 3 saniyede bir verileri Online Redo Log dosyalarına yazar.)

(**Online redo log** Beklenmedik durumlar karşısında veri kaybını önlemek ve veri tabanını yeniden oluşturmakiçin veri tabanında olan değişikliklerin kaydını tutar. Bir veri tabanına en az 2 redo log gereklidir.)

(**LGWR (Log Writer)** Redo Log Buffer’daki bilgileri online redo log’lara yazmakla görevli background process’tir.)

• LNS (LGWR Network Server) process’i ise; aynı redo verilerini redo buffer alanından okur ve RFS (Remote File Server) üzerinden RFS (Remote File Service) process’ine bildirir. LNS process’i ilgili redo verilerine redo buffer’dan erişemezse otomatik olarak primary veri tabanının online redo log’larını okur.
• RFS Process’i ise aldığı redo verilerini standby redo log’larına yazar.
• MRP (Managed Recovery Process) process’i standby redo log’larında bulunan redo verilerini standby
• veri tabanına “apply” eder.
• Son olarak RFS process’i gönderilen redo verilerinin başarılı bir şekilde standby’a yazıldığının bilgisini LNS işlemine gönderir, LNS ise bu mesajı LGWR process’ine aktarır ve artık kullanıcıya “commit” işleminin başarılı olduğu bilgisi verilir..

Asynchronous (Asenkron) Data Guard

• Veri tabanında bir “transaction” başlatıldığı zaman bu işlem öncellikle redo buffer alanına yazılır. Bu “transaction” “commit” edildiği zaman; LGWR (Log Writer) process’i redo buffer alanındaki redo verilerini online redo log’larına yazar.
• LNS (LGWR Network Server) process’i ise; aynı redo verilerini redo buffer alanından okur ve RFS (Remote File Server) üzerinden RFS (Remote File Service) process’ine bildirir. LNS process’i, ilgili redo verilerine redo buffer’dan erişemezse otomatik olarak primary veri tabanının online redo log’larını okur.
• RFS process’i ise; aldığı redo verilerini standby redo log’larına yazar.
• Son aşamada ise MRP (Managed Recovery Process) process’i standby redo log’larında bulunan redo verilerini standby veri tabanına “apply” eder.

Asenkron Data Guard yönteminde; RFS işleminde redo verilerinin başarılı bir şekilde işlendiği bilgisi LNS’e gönderilmez. Bu yüzden Asenkron Data Guard yönteminde  “sıfır veri kaybı” durumu yoktur, ve en az veri kaybı ile verilerin kurtarılması sağlanır.

Senkron Data Guard yönteminde ise; “commit” edilen tüm verilerin standby tarafına gönderildiği ve “apply” olduğu garanti edildiği için bu yöntemde “sıfır veri kaybı” durumu vardır.

Senkron Data Guard yönteminin, Asenkron Data Guard yöntemine göre bazı dezavantajları vardır. Bunlardan bir tanesi; Senkron Data Guard yönteminin, Asenkron Data Guard yöntemine göre daha az performanslı çalışmasıdır., Çünkü Senkron Data Guard yönteminde LGWR process’i her zaman LNS process’inden doğrulama bilgisi bekler; bu da süre kaybına yol açar. Ancak çok kritik verilerin bulunduğu veri tabanlarında, “sıfır veri kaybı” çözümüyle Asenkron Data Guard yöntemine göre avantajlıdır.

Hem primary hem de standby’da ortak kullanılan parametreler ve işlevleri aşağıdaki gibidir;

DB_UNIQUE_NAME: Veri tabanının “unique” namedir. “DB_NAME” parametresi her iki taraf için aynı olacaktır, fakat “DB_UNIQUE_NAME”ler farklı olmalıdır.

CONTROL_FILES: Burada veri tabanının fiziksel yapısı ile ilgili bilgiler (veri tabanının adı, veri dosyaları ve redo log dosyalarının yerleri ve adları, vb.) tutulur. Bir veri tabanı en az bir “control files” içerir. Bu değer primary’de primary veri tabanının, standby’da standby veri tabanın “control file” lokasyonunu gösterir.

LOG_ARCHIVE_CONFIG:  Data Guard konfigürasyonu için seçilen veri tabanlarının “db_unique_name”lerinin belirtildiği parametredir. İlk olarak primary veri tabanının, ardından standby veri tabanının “db_unique_name”i yazılır.

LOG_ARCHIVE_DEST_n: Bu parametre primary veri tabanı için kullanılan önemli bir parametredir. Primary veri tabanından standby veri tabanına redo verisi göndermek için gerekli bir parametredir. “n” değeri bu parametre için 0’dan31’e kadardır. “Log_archive_dest_1” parametresi primary veri tabanının arşiv log’larının yerini gösterir, ve bundan sonraki “Log_archive_dest_2”den sonra gelen parametreler standby için konfigüre edilir.

LOG_ARCHIVE_MAX_PROCESSES: Data Guard konfigürasyonu için önemli parametrelerden birisidir. Veri tabanının bu işlem sırasında kullanabileceği maksimum ARCH process (Archiver Process)’inin sayısını belirler. Default’ta; 2 maksimum değeri 30’dur.

FAL_SERVER: Primary ile standby veri tabanı arasında redo GAP oluştuğu zaman arşiv log’larının hangi server’dan alınacağı bu parametre ile belirlenir.

Data Guard Kurulumu

Temel Data Guard Konfigürasyonu

Oracle Data Guard kurulumu yapabilmek için gereken şartlar aşağıdaki gibidir:

• Oracle veri tabanının “enterprise” sürüm olması
• İki sunucunun da işletim sistemi aynı olmalıdır.
• İki sunucunun içindeki “Oracle Software” aynı sürüm olmalıdır.

Şimdi sizlere RMAN (Recovery Manager ) backup restore yöntemiyle Oracle Data Guard kurulumunu anlatalım.

Primary tarafı; production tarafını ifade ediyorken, standby tarafı ise; kuracağımız 2.veri tabanı ortamı olan Data Guard’ı ifade ediyor. Her 2 tarafta da yaptığımız adımları ayrı ayrı aşağıda belirttik.

Öncelikle standby sunucuya “Oracle Software” kurulur. Daha sonra “netca” kullanılarak listener servisi oluşturulup başlatılır.

Primary Tarafta Yapılması Gerekenler

Primary ve Standby veri tabanlarındaki “/etc/hosts” dosyasına sunucuların bilgileri yazılır.

Primary veri tabanının arşiv log modu açık olmalıdır. Veri tabanı bütün aktiviteleri log’lamalıdır. Aşağıdaki komutla arşiv log modunun açık olup olmadığı kontrol edilir. “Disable” yani kapalı ise açılır.

SQL> select log_mode from v$database;

LOG_MODE

NOARCHIVELOG

Eğer veri tabanı arşiv mod’da değilse, veri tabanı kapatılır ve mount mod’da açılır. Veri tabanı arşiv mod’a alınır ve veri tabanı tekrar açılır.

SQL> shutdown immediate;
SQL> startup mount;

SQL> alter database archivelog;
SQL> alter database open;

Veri tabanındaki bütün işlemlerin aşağıdaki komutla log’lanması sağlanır.

SQL> alter database force logging;

Standby veri tabanımız için standby redo log’larını oluşturuyoruz. Oluşturulacak olan standby redo log’ların boyutlarının mevcut online redo log’ların boyutlarıyla aynı olması gerekmektedir. Standby redo log’lar standby veri tabanlarında çalışırlar. Primary veri tabanında oluşturulması şartı yoktur. Fakat primary ve standby veri tabanlarının yer değiştirilmesi (switchover) işlemlerinden sonra düzgün çalışılabilmesi için; aynı şekilde standby redo log’larının primary veri tabanında da oluşturulması yararlı olacaktır.

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ‘/u01/app/oracle/ORCLDG/standby01.log’ size 50m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 ‘/u01/app/oracle/ORCLDG/standby02.log’ size 50m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 ‘/u01/app/oracle/ORCLDG/standby03.log’ size 50m;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 ‘/u01/app/oracle/ORCLDG/standby04.log’ size 50m;

Data Guard için parametreleri “set” edilerek, konfigürasyon işlemlerine başlanır. “LOG_ARCHIVE_CONFIG” parametresine ayarlanır. İlk olarak Primary veri tabanı “DB_UNIQUE_NAME”i yazılır ve ardından standby veri tabanı “DB_UNIQUE_NAME”i yazılır.

ALTER SYSTEM SET LOG_ARCHIVE_CONFIG= DG_CONFIG=(ORCL,ORCLSTBY)’ scope=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=’SERVICE=ORCLSTBY LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=ORCLSTBY’ SCOPE=BOTH;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE SCOPE=BOTH;

Veri tabanında “LOG_ARCHIVE_FORMAT”, “LOG_ARCHIVE_MAX_PROCESSES”, “REMOTE_LOGIN_PASSWORDFILE” parametreleri aşağıdaki gibi ayarlanır.

ALTER SYSTEM SET LOG_ARCHIVE_FORMAT=’%T_%S_%R.ARC’ SCOPE=SPFILE;
ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30 SCOPE=BOTH;
ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

“Switchover” durumu düşünülerek veri tabanının geçişe hazır olması için aşağıdaki parametreler “set”lenir ve daha sonra veri tabanı yeniden başlatılır(Zorunlu değildir. “Switchover” yapılacaksa “set” edilir).

ALTER SYSTEM SET FAL_SERVER=ORCL_STBY SCOPE=BOTH;
ALTER SYSTEM SET FAL_CLIENT=ORCL SCOPE=BOTH;

connect target / run{

ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH3 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH4 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH5 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH6 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH7 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH8 DEVICE TYPE DISK;
BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT ‘/u01/oracle/backup/FULL_%d_%u_%s_%T.bkp’;
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL not backed up 1 times FORMAT ‘/u01/oracle/backup/Archivelogs_%d_%u_%s_%T.bkp’;

BACKUP CURRENT CONTROLFILE FORMAT ‘/u01/oracle/backup/CONTROLFILE%d_%u_%s_%T.bkp’;
RELEASE CHANNEL CH1;
RELEASE CHANNEL CH2;
RELEASE CHANNEL CH3;
RELEASE CHANNEL CH4;
RELEASE CHANNEL CH5;
RELEASE CHANNEL CH6;
RELEASE CHANNEL CH7;
RELEASE CHANNEL CH8;

Primary veri tabanından “FULL backup” alınır ve standby tarafına kopyalanr.

Standby veri tabanını nomount mod’da açmak için production veri tabanından pfile yaratılır. Yine standby veri tabanımız için control file oluşturulur. Oluşturulan control file, pfile ve file scp kullanılarak primary sunucusundan alınan; “rman backup” ve arşiv log’lar, standby sunucusuna kopyalanır.

SQL> create pfile=’/tmp/initorcl_stby.ora’ from spfile;

SQL> alter database create standby controlfile as ‘/tmp/orcl_stby.ctl’;

pfile
scp /tmp/initorcl_stby.ora oracle@192.168.56.12:/u01/app/oracle/product/19.0.0/dbhome_1/dbs/initorcl_stby.ora

#Password File
scp /u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwORCL oracle@192.168.56.12:/u01/app/oracle/product/19.0.0/dbhome_1/dbs/orapwORCLSTBY

#Rman Backup
scp -r /u01/oracle/backup/ oracle@192.168.56.12:/u01/app/oracle/backup

#Control File
scp /tmp/orclstby.ctl oracle@192.168.56.12:/u01/app/oracle/oradata/ORCL_STBY/controlfile/control01.ctl

Hem primary hem de standby sunucusunda “tnsnames.ora” dosyası düzenlenir. Primary sunucusuna standby, standby sunucusuna primary sunucu bilgileri eklenir.

$> vi $ORACLE_HOME/network/admin/tnsnames.ora

ORCL = (DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = orcl.localdomain)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)

ORCL_STBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby.localdomain)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)

“Tnsping” ile kontrol edilir sorun yoksa devam edilir.

Yaratılan “initorcl_stby.ora (pfile)” dosyasında standby veri tabanı için düzenlemeler yapılır. Data Guard kurulumu için “DB_UNIQUE_NAME” parametresi eklenir ve “db_name”e farklı bir isim verilir. Eksik directoryler “create” edilir.

$> vi /tmp/initorcl_stby.ora

*.db_name=’orclstby’
*.db_unique_name=’ORCL_STBY’
*.fal_server=’ORCL’
*.log_archive_dest_1=’SERVICE=orcl ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=ORCL’

Standby Tarafında Yapılması Gerekenler

Primary’dan alınan pfile dosyası düzenlenir. Özellikle Data Guard kurulumu için “db_unique_name”parametresi eklenir ve “db_name”e farklı bir isim verilir. Eksik olan dizinler yaratılır.

$> mkdir -p /u01/app/oracle/oradata/ORCL_STBY
$> mkdir -p /u01/app/oracle/fast_recovery_area/ORCL_STBY/
$> mkdir -p $ORACLE_BASE/admin/$ORACLE_SID/adump

Listener yeniden başlatılır.

$> lsnrctl stop
$> lsnrctl start

YA DA

$> lsnrctl reload

Bash profile düzenlenir.

Primary veri tabanından alınıp kopyalanan veri yedeklenir.

SQL> startup nomount pfile=’pfile.ora’

Primary’den alınan standby control file “restore” edilerek, Standby veri tabanı mount mod’a getirilir. Backup’lar “catalog start with” ile veri tabanına tanıtılır, ardından veri tabanı “restore” edilir.

$> rman target /
RMAN> restore standby controlfile from ‘/u01/oracle/backup/standbycontrol.ctl’;
RMAN> alter database mount;
RMAN> catalog start with ‘/u01/oracle/backup/’;

connect target /
run{
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH3 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH4 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH5 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH6 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH7 DEVICE TYPE DISK;
ALLOCATE CHANNEL CH8 DEVICE TYPE DISK;
restore database;
RELEASE CHANNEL CH1;
RELEASE CHANNEL CH2;
RELEASE CHANNEL CH3;
RELEASE CHANNEL CH4;
RELEASE CHANNEL CH5;
RELEASE CHANNEL CH6;
RELEASE CHANNEL CH7;
RELEASE CHANNEL CH8;
}

Standby veri tabanı için MRP (Managed Recovery Process) process’i başlatılır ve log’ların işlenmesi sağlanır.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

Data Guard sağlıklı çalışıyor mu kontrol edelim.

Primary Veri Tabanında;

SQL> SELECT DATABASE_ROLE, OPEN_MODE, SWITCHOVER_STATUS FROM V$DATABASE;

Standby Veri Tabanında;

SQL> SELECT DATABASE_ROLE, OPEN_MODE, SWITCHOVER_STATUS FROM V$DATABASE;

Primary tarafında;

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

PROCESS

DGRD
ARCH
DGRD
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH

PROCESS

ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH

PROCESS

ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
LNS

PROCESS

DGRD
LNS

STATUS

ALLOCATED
CLOSING
ALLOCATED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED

STATUS

CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED

STATUS

CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CLOSING
CONNECTED
CONNECTED
CONNECTED
CONNECTED
OPENING

STATUS

ALLOCATED
WRITING

Standby tarafında;

SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

PROCESS

RFS
ARCH
DGRD
DGRD
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH

PROCESS

ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH

PROCESS

ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
ARCH
LNS

PROCESS

RFS
MRP0
RFS

STATUS

IDLE
CONNECTED
ALLOCATED
ALLOCATED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED

STATUS

CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED

STATUS

CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED
CONNECTED

STATUS

IDLE
APPLYING_LOG
IDLE

Standby veri tabanına arşiv log dosyalarının “apply” edilip edilmediği, aşağıdaki Scriptle Data Guard “monitor” edilerek anlaşılır.

SQL> select sequence#, first_time, next_time, applied from v$archived_log order by sequence#;

Oracle Data Guard Mimarisi hakkında bilgi vererek, kurulumunu detaylı bir şekilde anlattık. Konu hakkında detaylı bilgi almak için Türkiye’nin en yetkin Oracle sertifikalı ekibimize ulaşabilirsiniz.

Yazar:

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post Oracle Data Guard Mimarisi ve Kurulumu appeared first on GTech.

Büyük miktarda verilerin çoklu kullanıcılı ortamlarda depolanmasını ve erişilmesini sağlayan Oracle Veritabanı gelişmiş bir ilişkisel veritabanı sistemidir. İşlem boyutunun fazla olmasına karşın işlemlerin hızlı ve güvenli bir şekilde gerçekleştirilmesi, ihtiyaca uygun farklı sürüm seçenekleri sunması, çeşitli yöntemler ile depolanan verilerin güvenliğinin sağlanması gibi özellikleri ile Oracle Veritabanı işletmelerin veritabanı yönetim sürecindeki ihtiyaçlarını karşılıyor. Bu yazımızda sizler için Oracle Veritabanı ve sürümlerini açıklayarak öne çıkmasını sağlayan özelliklerinden söz ettik.

Oracle Veritabanı Nedir?

Oracle veritabanı bir ilişkisel veritabanı yönetim sistemidir. İlişkisel bir veritabanı olarak Oracle Veritabanı verilerin yönetilmesi, tasarlanması, hazırlanması ve sorgulanması süreçlerinde de kullanılan SQL üzerine inşa edilmiştir. Oracle Veritabanı sadece verilerin saklanmaz, aynı zamanda web tabanlı bir yazılım geliştirme ortamı sunar.

Hem işletme içerisinde hem de bulut ortamında performans, ölçeklenebilirlik ve güvenlik sunan Oracle Veritabanı en zorlu analitik ve operasyon iş yükleri için yüksek performans elde edilebiliyor. Bu özelliklere ek olarak çok modelli, çoklu iş yüklü, makine öğrenimine erişimli ve çoklu kullanıcı geliştirme imkânlı olma özellikleriyle öne çıkıyor.

Oracle Veritabanı Sürümleri Nelerdir?

Oracle veritabanı farklı uygulama amaçları için her biri farklı geliştirme ve dağıtım senaryoları için uygun olan farklı sürümlere sahiptir (2015 yılından itibaren aşağıdaki ‘Standart Sürüm One’ ve ‘Standart Sürüm’, ‘Standard Edition 2’ adı altında birleştirilmiştir). Belirli uygulama amaçları için Oracle veritabanının yeteneklerini geliştiren çeşitli veritabanı seçenekleri, paketleri ve benzeri çeşitli ürünler sunar. Oracle veritabanının sahip olduğu sürümler şu şekilde özetlenebilir:

> Standart Sürüm One: Oracle veritabanının bu sürümü küçük işletmeler için tek sunuculu ortamlardan yüksek oranda dağıtılmış ortamlara kadar çalışma grubu, departman düzeyi ve web uygulamaları oluşturmak için gerekli tüm olanakları içerir.

> Standart Sürüm: Büyük makineler ve hizmetlerin kümelenmesine yönelik Oracle Real Application Clusters (Oracle RAC) desteği ile Oracle veritabanının bu sürümde veritabanı boyutu sınırsızdır. Ayrıca bu sürümde de Standart Sürüm One’ın kullanım kolaylığı, gücü ve performansı bulunuyor.

> Enterprise Sürüm: Oracle veritabanının tüm bileşenlerini içeren bu sürüm yüksek hacimli çevrimiçi işlem işleme uygulamaları, yoğun veri ambarları ve zorlu internet uygulamaları gibi uygulamalar için gereken performansı, kullanılabilirliği, ölçeklenebilirliği ve güvenliği sağlar.

> Express Sürüm: İndirmesi hızlı, kurulum ve yönetimi basit, geliştirmesi ve dağıtması ücretsiz olan Oracle veritabanının bu sürümü bir giriş seviyesi sürümüdür. Maliyetli ve karmaşık geçişler olmadan Oracle’ın diğer sürümlerine yükseltmeyi kolaylaştırır. Bu sürüm, herhangi bir sayıda işlemciye sahip herhangi bir boyuttaki makineye kurulabilir. 4 GB’a kadar kullanıcı verisi depolarken, 1 GB’a kadar bellek kullanır.

> Personal Sürüm: Diğer Oracle sürümleri ile tam uyumluluk gerektiren tek kullanıcılı geliştirme ve dağıtım ortamlarını destekleyen bu Oracle veritabanı sürümü Oracle Real Application Clusters (Oracle RAC) desteği dışında Enterprise sürümünde yer alan tüm seçenek ve bileşenleri içerir.

Neden Oracle Veritabanı?

Oracle veritabanının işletmeler tarafından tercih edilmesinin çeşitli nedenleri bulunuyor. Bu nedenlerden birkaçını şu şekilde sıralayabiliriz:

• İşletme giderlerini azaltır: Makine öğrenimi otomasyonu sayesinde veritabanı provizyonlama, ayarlama, onarma, yamalama, koruma, ölçeklendirme gibi işlemlerin tamamını kullanıcı müdahalesi olmadan, otomatik olarak gerçekleştirir. Böylece ürünlerin yönetme, koruma ve bakım maliyetleri azaltılmış olur.
• Veri ihlallerine karşı koruma sağlar: Veri maskeleme, etkinlik izleme, anahtar yönetimi, şifreleme, ayrıcalıklı kullanıcı erişim kontrolleri gibi veritabanı güvenliği çözümleri sayesinde veri güvenliği ihlalleri tespit edilerek önlenir.
• Tüm veri türleri için tek bir veritabanı kullanır: Bütünleşik veritabanı çözümü sayesinde kullanıcılar karmaşık dönüşümler ve veri fazlalığı gibi sorunlarla uğraşmazlar.
• İhtiyaç duyulan yerlerde konuşlandırılır: Oracle Veritabanı veri merkezinde, genel bulut ortamında, özel bulut ortamında, gereken her yerde konuşlandırılabilir. Bu sayede, yerleşim veya gecikme gibi kritik durumlarda veri merkezinde veya bulut ortamında konuşlandırma arasında esneklik sağlanır.

Oracle Veritabanı Hizmetlerimiz

Türkiye’nin en yetkin Oracle iş ortağı olan GTech olarak sağlıktan hizmete, bankacılıktan enerjiye pek çok sektörde Veritabanı ve Sistem Yönetimi faaliyetleriyle ilgili uzman ekibimizle Oracle Danışmanlık Hizmeti sunuyoruz. En güncel teknolojileri kullanarak yüksek performans ve yüksek kaliteli sistem yönetimi sağlanması için eşsiz ve özel bir destek sunan GTech, danışmanlık ve bakım hizmetleri dahil işletmenize en uygun çözümleri sağlar. Siz de GTech olarak sunduğumuz Oracle Danışmanlık Hizmeti hakkında daha ayrıntılı bilgi almak istiyorsanız bizimle iletişime geçebilirsiniz.

Kaynakça

Kaynak: Oracle Resmi Dokümantasyonu

Kaynak: Oracle Veritabanı Ürün Sayfası

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post Oracle Veritabanı Nedir? appeared first on GTech.

Verilerin oluşturduğu istatistiksel raporlar, geriye dönük analizler geleneksel sistemler ile de gerçekleştirilebiliyor olsa da bu işlemler yeni nesil sistemler sayesinde daha etkin, güvenli ve hızlı bir şekilde yerine getirebiliyor. Oracle Exadata ise bu kolaylığı ve zaman verimliliğini sağlayan teknolojiler arasında en yaygın olarak tercih edilen sistemdir. Bu yazımızda sizler için Exadata sistemini açıklayarak sahip olduğu özelliklere ve bu özellikler sayesinde elde edilen avantajlara yer verdik.

Exadata Nedir?

Exadata, Oracle tarafından tasarlanmış, kullanıcılara kurumsal sınıf veritabanlarına ve bunlarla ilişkili iş yüklerine yönelik optimize edilmiş işlevsellik sağlayan bir veritabanı sunucu makinesidir. Exadata sistemi, Oracle veritabanı yazılımı ve Sun Microsystems tarafından oluşturulan donanım sunucu ekipmalarını kullanıyor. Oracle Veritabanı Makinesi ve Exadata Depolama Makinesi olmak üzere iki temel bileşenden oluşan Exadata akıllı tarama (smart scan) temel mantığını kullanarak çalışıyor. Akıllı tarama özelliği sayesinde depolama indeksleri sayesinde verinin depolandığı alanı bulunduğunu belirlenmesini ve hızla ulaşılmasını sağlıyor. Ayrıca, Exadata özel bir algoritma sayesinde yüksek boyutlarda veriyi sıkıştırabiliyor ve sıkıştırılmış veriyi okuma imkânı tanıyor.

Exadata sistemi farklı büyüklük ve konfigürasyona göre 1/8, 1/4, 1/2 ve tam (full) olmak üzere dört farklı kategoride oluşturulabiliyor. 1/8 ve 1/4 sistemlerinin kabinet içi görünümleri fiziksel olarak aynı olup 2 veritabanı sunucusu ve 3 depolama sunucusu bulunuyor. 1/4 Exadata sisteminin CPU ve disklerinin yarısı aktif edilmediğinde 1/8 konfigürasyonunda Exadata ortaya çıkıyor. Exadata sisteminin 1/2 konfigürasyonun 4 veritabanı sunucusu, 7 adet depolama sunucusu yer alıyorken; tam bir Exadata sisteminde ise 8 veritabanı sunucusu, 14 depolama sunucusu bulunuyor.

Exadata’nın Tarihçesi

Eylül 2008 tarihinde Oracle tarafından Exadata ilk olarak HP Oracle Database Machine olarak da bilinen v1 ismiyle duyuruldu. Mevcut veri depolarını 10 kata kadar daha performansla çalıştıran bir yazılım ve donanımın uyumlu olduğu bir sistem olarak ortaya çıkan Exadata v1 sahip olduğu akıllı tarama, I/O kaynak yöneticisi (I/O resource manager), birleştirme filtreleri (bloom filters), artımlı yedekleme filtreleme, akıllı dosya oluşturma yazılımlarını; ölçeklenebilir 4 yuvalı bilgi işlem ve depolama sunucuları, 1 terabayt disk, 20 Gbit/sn dahili yapı ve 1 Gbit/s veri merkez ağı donanımlarıyla birleştirilmesiyle üretilmiştir.

Eylül 2009 tarihinde de v2 ismiyle çıkış yapan Exadata sonraki dönemlerde X versiyonuna geçerek X2 adı ile başlayan serinin Eylül 2021 tarihinde çıkarılan X9M ile devam eden seri, sonrasında X10M ve X11M sürümleriyle güncellenmeye devam etmiştir. Oracle Exadata bu süreçte hem yazılımsal hem de donanımsal açıdan pek çok gelişme ortaya koymuştur. X9M nesli ürünleri arasında Oracle Exadata Database Machine X9M ve Oracle Kendi Kendini Yöneten Veritabanı’nı kullanıcı veri merkezlerinde çalıştıran tek platform olan Exadata Cloud@Customer X9M de bulunuyor.

Exadata sisteminde son gelinen noktada %70 daha yüksek IOPS hızı ve 19 mikrosaniyenin altında IO gecikmesi sayesinde çevrimiçi işlem süreçlerini (OLTP) daha da hızlandırıyor. Bununla birlikte, makine öğrenimi iş yüklerinde ve analitik SQL kapasitesinde %87’ye varan bir artış sunuyor. Son sürüm sayesinde kullanıcılar işlemsel iş yüklerini çalıştırma maliyetlerini %42, analitik iş yüklerini çalıştırma maliyetlerini ise %47’ye varan oranlarda azaltabiliyor.

Exadata’nın Avantajları ve Özellikleri Nelerdir?

Oracle tarafından sunulan Exadata sisteminin sahip olduğu özellikler geleneksel sistemlere göre Exadata sisteminin daha avantajlı olduğu gösteriyor. Exadata’yı diğer sistemlerden ayırarak öne çıkaran ve kullanıcılarına pek çok avantaj sağlayan özellikler şu şekilde listelenebilir:

> Tümleşik Sistem: Exadata sistemi alındığında veritabanı sunucusu, hücre sunucusu ve infiniband ile birlikte, Oracle veritabanının en optimum şekilde çalışması için gerekli olan donanım ve yazılım kurulu olarak gelir. Bununla birlikte, yazılım ve donanım uyumlu çalışan bu sistemde bir sorun veya arıza ile karşılaşan kullanıcıların tek bir sağlayıcıyı muhatap olarak görmesi Exadata’nın tercih edilme nedenlerinden birisi olarak gösteriliyor.

> Ölçeklendirme ve Kullanılabilirlik: Exadata sisteminin orta ve büyük ölçekli tüm kurumlar tarafından tercih edilmesinin bir diğer nedeni ise ölçeklendirilebilir olmasıdır. Bu özelliği sayesinde kurumlar ihtiyaçlarına uygun Exadata sistemini tercih edebiliyor. Exadata sisteminin bu özelliği tasarımın temelini oluşturuyor. Düşük ihtiyaçlar doğrultusunda 1/8 sistemi ile başlayabilir, ilerleyen süreçte 1/2 veya tam Exadata sistemine geçebilir hatta 1 kabinetin yetmediği durumlarda 8 kabinete kadar yükseltme yapılabiliyor.

> Konsolidasyon: Exadata birden fazla dağıtık sunucuda çalışan veritabanlarını birleştirerek lisans ve yönetim maliyetlerini azaltabiliyor. Exadata sisteminde bulunan I/O Kaynak Yöneticisi (I/O Resource Manager) yazılımı sayesinde birden fazla veritabanını Exadata sistemine taşıyarak beraber çalışmaları sağlanabiliyor. Böylece, lisans ve yönetime ek olarak donanım ve yedekleme maliyetleri de en aza indirilebiliyor.

> Erişilebilirlik: Exadata sistemi en az iki node veritabanı sunucuyla oluşturulduğu ve RAC yapısında olduğu için herhangi bir node üzerinde yaşanacak istenmeyen bir durum karşısında diğer node ile kesintisiz bir şekilde çalışmaya devam edebilirsiniz. Storage ile yedeklilik sağlandığı için de bir veya birden fazla diske zarar gelmesi durumunda da verileri kaybetmenin önüne geçilebiliyor.

> Bant Genişliği: Veritabanı ve depolama sunucusu arasında bulunan infiniband switch özelliği sayesinde Exadata sistemi 40 Gb/s ve üzeri veri alışverişi yapılabiliyor. Bu durum, geleneksel sistemler ile karşılaştırıldığında Exadata’nın yüksek miktarda veri transferi imkânı sunarak daha avantajlı olduğunu ortaya koyuyor.

> Akıllı Veri Bulma: Diğer sunuculardan farklı olarak Exadata sisteminde bir sorgulama gerçekleştirildiğinde Storage Index ve Smart Scan özellikleri sayesinde yalnızca aranan veri bloğunu bulur ve ortaya çıkarması açısından geleneksel sistemlerden çok daha hızlı çalışır.

> SQL Offload: Exadata sisteminin ilk çıkışıyla ortaya koyduğu bir yenilik olan SQL Offload özelliği ile Exadata sahip olduğu bütünleşik mimari ve Cell olarak adlandırılan depolama yapısı ile geleneksel sorgulardaki işleyişin ötesine geçilebiliyor. Standart sorgularda veritabanından istenen veriler sunucu üzerinde işlenirken Exadata sistemi üzerinden çağrılan veriler Cell üzerinden döner ve bu durum performans açısından ciddi kazanımlar sağlar.

> Bulut Sistemi: Exadata sahip olduğu tüm bu özelliklere ek olarak son modelinde self servis ve yüksek performans Database Cloud sayesinde kullanıcıların altyapı yöntemi olmadan daha verimli bir şekilde çalışmaları sağlanabiliyor.

Kurumların iş süreçlerinin birçoğunda önemli bir rolü bulunan veri yönetimi ve kullanımında etkinlik sağlamak için yeni nesil çözümlerden faydalanılması önemlidir. Uzman kadrosu ile GTech, şirketinizin sistem ve veritabanı yönetimi sürecindeki verimliliği artırmayı sağlayan yeni nesil çözümler sunuyor. GTech hizmet ve çözümleri hakkında daha ayrıntılı bilgi almak için sistem ve veritabanı yönetimi uzmanlarımıza ulaşabilirsiniz.

Kaynakça

Kaynak: Oracle Exadata

Kaynak: Grid Group – Neden Oracle Exadata

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post Oracle Veritabanlarında Neden Exadata Kullanılmalı? appeared first on GTech.

MySQL’den PostgreSQL’e Veri Aktarma

• MySQL ile PostgreSQL arasında birçok benzerlik olsa da radikal farklılıklar da bulunmaktadır. Şu anda Oracle’a ait olan MySQL açık kaynaklı bir veritabanıdır ama tescilli kullanım için çeşitli sürümler de sunmaktadır. Ancak, PostgreSQL ise tamamen ücretsiz ve açık kaynaklı bir veritabanıdır ve açık kaynak lisansı olan PostgreSQL lisansı altında yayınlanır. SQL uyumluluğu açısından ise MySQL bazı sürümlerle uyumlu iken PostgreSQL büyük ölçüde uyumluluk sağlar.
• MySQL asıl temel tablodan gerektiğinde güncellenebilen bir sorgunun sonuçlarını içeren veritabanı nesnesi olan gerçekleşmiş görünümleri desteklememekte, yalnızca kendisini oluşturan oturumun süresinin ardından sürmesi gerekmeyen verileri depolayan geçici tabloları desteklemektedir. Ancak, PostgreSQL her iki tablo türünü de desteklemektedir.
• Kullanıcı tarafından yeni veri türleri, işlevler, operatörler, dizin yöntemleri ve yöntemsel diller gibi birçok yolla genişletilebilir olan model sistemleri MySQL tarafından desteklenmemektedir. PostgreSQL ise genişletilebilirliğe özel çeşitli özelliklere sahiptir. Bu sayede yeni modelleri, fonksiyonları, indeks türleri eklemek mümkündür. Hem MySQL hem de PostgreSQL istemci ve sunucu iletişimi arasında SSL şifreli bağlantılar sunmaktadır. Buna ek olarak, PostgreSQL SELinux güvenlik politikasına dayalı ek erişim kontrolleri sağlayan SE-PostgreSQL olarak adlandırılan dahili bir geliştirme sunmaktadır.
• MySQL, JSON veri türü desteğine sahiptir ancak başka NoSQL özelliği bulunmamaktadır. Ayrıca, JSON için dizinlemeyi de desteklemez. PostgreSQL ise JSON’u ve yerel XML desteği ve HSTORE ile diğer NoSQL özelliklerini destekler. Ayrıca, daha hızlı erişim için JSON verilerinin dizinlenmesini destekler.

Oracle’den PostgreSQL’e Veri Aktarma

• Hem Oracle hem de PostgreSQL veritabanı ile iletişim kurmak için bir uygulama API’si sağlasa da PostgreSQL açık kaynak kodludur. Bu da geliştiricilerin herhangi bir PostgreSQL bileşenine, projelerine başlık dosyasını dahil etmeleriyle doğrudan erişebilme imkanı sağlar.
• Oracle, yerleşik bir kimlik doğrulama sistemine sahiptir. Postgre ise ana bilgisayar tabanlı kimlik doğrulamaya dayanır ve bu nedenle çok çeşitli kimlik doğrulama yöntemlerini destekleyebilir. Bu da kimlik doğrulama için daha fazla esneklik ve işlemi yetkilendirme seçeneği sağlar.
• Oracle, çoğunlukla tescilli bir eklenti sistemine sahiptir. Ancak, PostgreSQL’in genişletme sistemi genel topluluk tarafından desteklenir. Bu nedenle, binlerce eklentiye erişim mevcuttur.
• Oracle, PL / SQL adlı yerleşik bir programlama diline sahipken, PostgreSQL yalnızca PL / pgSQL değil bir çoğunu barındırır. Ayrıca, PostgreSQL kullanıcıların eklenti olarak ek yöntemsel diller ve daha fazla programlama için bağlamlar oluşturmasına olanak tanıyan bir uzantı sistemine sahiptir.
• Performans açısından PostgreSQL bir okuma kümesinde sınırsız sayıda düğüm oluşturabilmekte ve farklı iş yüklerine yönelik bir özel okuma işlemini sıfır maliyet ile sunmaktadır. Oracle ise yüksek ölçeklendirilmiş iş yükleri için önerilse de maliyeti oldukça yüksektir.

Microsoft SQL Server’dan PostgreSQL’e Veri Aktarma

• PostgreSQL, verilerin hızlı işlenmesine yardımcı olan ‘COPY TO’ ve ‘COPY FROM’ gibi farklı komutlar sunar. Ayrıca, yararlı hata mesajları da sağlar. İçe aktarma ile ilgili küçük bir sorun bile varsa, hata vererek içe aktarmayı o anda durdurur. Öte yandan Microsoft SQL Server, verilerin içe aktarılmasını veya dışa aktarılmasını desteklemez.
• Her iki veritabanı da çapraz platform destekli de olsa PostgreSQL Windows, Linux, Unix, OS X ve bunun gibi birçok işletim sistemini destekler. Ancak, Microsoft SQL Server yalnızca Windows ve Linux’u destekler.
• PostgreSQL yöntemsel dil desteği sağlamaktadır. Bununla birlikte, JSON veri türünü desteklemektedir. Tek başına üst düzey güç ve çok fazla çeşitlilik sunmaktadır. Bir kullanıcı, PostgreSQL’de yöntemsel diller desteğine sahip olduğu için SQL ile Python, Pear, R, Java, PHP’yi kolayca kullanabilir. Microsoft SQL Server ayrı bir özellik olarak yöntemsel dil desteği sağlar. Bu özellik PostgreSQL’e göre biraz daha dağınık, yavaş ve zayıf özelliklere sahiptir.
• PostgreSQL, analitik çalışma için çok sayıda kurallı ifade sağlamaktadır. Öte yandan, Microsoft SQL Server, PostgreSQL tarafından sağlanan bu kurallı ifadeler karşılaştırıldığında benzer ancak daha zayıf alt dizge ve desen indeksine sahiptir.
• Harici dil bağlantıları açısından PostgreSQL’in programlama ortamlarına bağlanması ve bu ortamlarda kullanılması Microsoft SQL Server’a göre daha kolaydır. Microsoft SQL Server harici dil bağlantıları farklılık gösterir ve fazladan sürücülerin yüklenmesi gerekir.
• PostgreSQL bir açık kaynak projesi olduğu için tamamen ücretsizdir. Microsoft SQL Server ise bir Microsoft ürünüdür ve kullanmak için şirket veya kullanıcının belirli bir ödeme yapması gerekir.

MariaDB’den PostgreSQL’e Veri Aktarma

• MariaDB ve PostgreSQL sistemleri arasındaki en büyük farklardan biri performanstır. PostgreSQL’deki okuma ve yazma işlemleri ve yanıt dönüş süresi, MariaDB’ye kıyasla çok daha hızlıdır.
• PostgreSQL sistemi, veritabanının performansını artırmaya yardımcı olan kısmi dizinler, gerçekleşmiş görünümler sunarken MariaDB sisteminde böyle bir özellik desteklenmemektedir.
• Sunucu işletim sistemleri açısından PostgreSQL, MariaDB’nın desteklediği Solaris, Windows, FreeBSD ve Linux sistemlerine ek olarak NetBSD, Unix, OpenBSD ve daha birçoğunu desteklemektedir.

SQLite’dan PostgreSQL’e Veri Aktarma

• PostgreSQL sistemi ile SQLite arasındaki farklardan ilki bölütleme yöntemidir. SQLite sistemi herhangi bir bölütleme yöntemini desteklemez. Bunun yanı sıra, PostgreSQL sistemi liste, aralık ve karma gibi çeşitli bölütleme yöntemlerini destekler.
• SQLite ve PostgreSQL sistemleri kimlik doğrulama ve güvenlik açısından farklılık göstermektedir. PostgreSQL, çeşitli gelişmiş güvenlik özellikleri sağlar ve birçok yerleşik yapılandırma sunar. Öte yandan SQLite, bir veritabanının dosyalarına herkes tarafından erişebildiği için kullanılan bir kimlik doğrulama sistemi içermez.
• Kullanıcı yönetimi açısından PostgreSQL sisteminde, birden çok kullanıcı uygun yetkilendirme ile sisteme erişebilir. Ancak, SQLite, kullanıcı yönetimi işlevine sahip olmadığı için birden çok kullanıcıya erişimi desteklemez.
• PostgreSQL, karmaşık veritabanını herhangi bir kısıtlama olmaksızın yönetme işlevselliğine sahiptir. Öte yandan SQLite, küçük bir uygulama olduğu için basit bir veritabanı sistemini yönetmek için kullanılır.

Yukarıda farklı sistemler ile PostgreSQL arasındaki farklılıklara yer verilmektedir. Bu farklılıklar diğer sistemlerden PostgreSQL’e veri aktarmanın başlıca nedenleri karşılaştırmalı olarak göstermektedir. Veri aktarmada hedef kaynağın PostgreSQL sistemi olmasındaki nedenler 4 başlıkta özetlenebilir:

• PostgreSQL kurumsal kullanıma hazır bir sistemdir.

Görev açısından kritik iş uygulamaları için uygun olan PostgreSQL, kullanıma hazır, güvenli ve iş sürekliliğini sağlamak için oldukça çeşitli ortamlar için yapılandırılabilir. Unix, Linux, macOS ve Windows dahil tüm büyük işletim sistemlerinde çalışır ve çeşitli programlama dilleri sunar.

• PostgreSQL ücretsiz bir sistemdir.

PostgreSQL’in kullanımı tamamen ücretsizdir. Kendine ait lisans sayesinde diğer açık kaynaklı veri tabanlarının aksine hiçbir kısıtlama olmadan kullanabilmektedir.

• PostgreSQL güçlü bir sistemdir.

PostgreSQL bir veritabanından beklenilen tüm profesyonel düzeydeki özelliklere sahiptir. Birden çok kullanıcıya, birden çok veritabanına, saklı yordamlara, güçlü ve çeşitli türlere, görünümlere, yedeklemelere ve daha birçok işleme erişim imkanı sağlamaktadır.

• PostgreSQL güvenli bir sistemdir.

Güvenli bağlantılar için SSL, veritabanı şifreleme ve ihtiyaca göre kullanıcıları, rollerini yönetme olanağı sağlar.

20 yıllık bilgi ve tecrübeye sahip GTech uzman kadrosu, sağlık, bankacılık, telekomünikasyon, perakende, enerji, kamu gibi birçok sektörde sistem ve veritabanı yönetimi hizmeti sunmaktadır. Siz de PostgreSQL sistemine veri taşıma konusunda daha detaylı bilgi sahibi olmak için bizimle iletişime geçebilirsiniz.

Kaynakça

Kaynak: PostgreSQL Wiki – Veritabanı Dönüşümü

Kaynak: Medium – MS SQL Server vs PostgreSQL vs MongoDB

Kaynak: EnterpriseDB Blog

Kaynak: 2ndQuadrant – PostgreSQL vs MySQL

Kaynak: ScaleGrid – PostgreSQL vs Oracle

Kaynak: EDUCBA – PostgreSQL vs SQLite

Kaynak: EDUCBA – PostgreSQL vs MariaDB

Hazırlayan: GTech Veritabanı ve Büyük Veri Platformu Ekibi

The post PostgreSQL’e Veri Aktarımında Önemli Noktalar appeared first on GTech.

Veritabanı Sağlık Taraması Ne İşe Yarar?

Bakımsız ve sağlıksız bir veritabanı beraberinde birçok sorunu getirir. Yavaş çalışma, hatalı işlemler yapma, güvenlik açıklarına neden olma, verilerin yanlış analiz edilmesi ve bu sorunların işe ya da müşterilere yansımasından dolayı yaşanacak para ve itibar kaybı gibi birçok sorun, veritabanının bakımsızlığından kaynaklanabilir. Veritabanı sağlık taraması ile, mevcut veritabanında yaşanan yavaşlama ve hatalar ortadan kaldırılarak, daha sağlıklı bir çalışma ortamı sağlanır. Bu sayede, veritabanından kaynaklanan ve işletmelerin zaman, para, müşteri kayıplarının önüne geçilir.

Veritabanı Sağlık Taramasının Yararları Nelerdir?

Performans artışı sağlar: Uygulama ve depolama sunucuları, veritabanları ve işletim sistemlerinin mimari gereksinimleri ve önemli metrikleri dikkate alınarak gerçekleştirilen performans analizleri sonrasında ortaya çıkan bulgulara bağlı olarak yapısal ve süreçsel iyileştirmeler gerçekleştirilir. Bu sayede, bağlantılı ya da bağımsız sorunlar giderilerek performans artışı sağlanır.

Güvenlik artışı sağlar: Mevcut sistem ya da veritabanındaki güvenlik durumu kontrol edilip riskli alanlar belirlenerek gerekli güvenlik önlemleri alınır.

Verim artışı sağlar: İlgili sistem ve ürünlerin en doğru ve verimli şekilde ayarlanıp, lisanslarla uyumlu bir şekilde kullanımını sağlayacak konfigürasyon optimizasyonu gerçekleştirilip, mevcut teknoloji ve kabiliyetlerin en verimli şekilde kullanımı sağlanır.

Mevcut ve gelecekteki sorunlara çözümler sunar: Sistemlerdeki hata ve problem kayıtları, sürüm güncellemeleri ve yama seviyesi, performans metrikleri, yük ve kapasite durumu gibi konular incelenerek, yaşanan ve olası problemler tespit edilir ve bu problemler ortadan kaldırılır.

Neden GTech?

Oracle ürünlerinde de diğer IT çözümlerinde olduğu gibi, zaman içerisinde farklı sebeplerden kaynaklanan performans kayıpları, hatalar ve sorunlar oluşabilmektedir. Sistem bakımının aksatılması, yama yönetiminin yanlış yapılması, sistem üzerinde meydana gelen yük artışına paralel bir şekilde geliştirme yapılmaması gibi birçok nedenden dolayı veritabanında yavaşlamalar, hatalar ya da beklenmeyen sorunlar ortaya çıkmasına neden olabilmektedir.

GTech; 20 yıllık veri uzmanlığı, çözüm odaklı yaklaşımı, Oracle sertifikalı uzman kadrosu ve Türkiye’nin önde gelen kuruluşlarında kanıtlanmış projeleri ile veritabanı sağlık taraması konusunda öne çıkmaktadır. GTech, Oracle’ın belirlediği best practise uygulamaları ile sisteminizin en doğru, hızlı ve sağlıklı şekilde çalışması için gerekli olan uçtan uca veritabanı sağlık taramasını yapar ve sorunları tespit edip, bu tespitlerle birlikte çözüm önerilerini detaylı olarak açıklar.

GTech’in Veritabanı Sağlık Taraması Hizmeti ile daha performanslı, daha güvenli ve daha erişilebilir bir sisteme sahip olmak için bizimle iletişime geçin!

Hazırlayan: GTech Sistem ve Veritabanı Yönetimi Ekibi

The post Veritabanı Sağlık Taraması Neden Gerekli? appeared first on GTech.