• Performans optimizasyonu yaparken,
• Geliştirme veya test ortamlarında disk alanı kullanımını azaltmak amacıyla,
• Yedekleme stratejisinde değişiklik yapılırken.

Bu yazıda, Oracle’da archive logging’i devre dışı bırakmanın adımlarını ve neden bu işlemi dikkatle yapmanız gerektiğini ele alacağız. SQLPlus kullanarak bu işlemi nasıl gerçekleştireceğinizi adım adım öğrenebilirsiniz.

Archive Logging Nedir ve Neden Durdurulmak İstenebilir?

Oracle Archive Logging, bir veritabanının ARCHIVELOG modunda çalışıp çalışmadığını ifade eder. Bu mod, redo log dosyalarının (yeniden yapım günlükleri) bir kopyasını saklar ve yedekleme ile kurtarma işlemlerini destekler.

Avantajları:

• Veri kaybını önler.
• Kurtarma işlemleri için kritik önem taşır.

Dezavantajları:

• Disk alanı kullanımı artar.
• Performansı olumsuz etkileyebilir, özellikle yoğun işlem yüküne sahip sistemlerde.

Eğer sisteminiz bir geliştirme veya test ortamıysa ya da arşiv günlüklerine ihtiyacınız yoksa bu özelliği devre dışı bırakabilirsiniz.

Archive Logging Nasıl Devre Dışı Bırakılır?

1. SQLPlus’a Bağlanın

Oracle veritabanınıza bağlanmak için sysdba yetkisiyle giriş yapmanız gerekir. Bu yetki, veritabanı üzerindeki tüm yönetimsel işlemleri yapmanıza olanak tanır.

SQL> conn sys as sysdba

2. Archive Logging’i Durdurun

Aşağıdaki komut, archive logging’i geçici olarak durdurur. Bu işlem, sistemin log dosyalarını arşivlemeyi bırakmasını sağlar.

SQL> alter system archive log stop;

3. Veritabanını Kapatın

Veritabanını güvenli bir şekilde kapatmak için aşağıdaki komutu kullanın:

SQL> shutdown immediate

4. Veritabanını Özel Mount Modunda Başlatın

Bu adımda veritabanını mount restrict (özel mount modu) ile başlatmanız gerekiyor. Böylece veritabanı yalnızca yönetim işlemleri için erişilebilir hale gelir.

SQL> startup mount restrict

5. Archive Logging’i Devre Dışı Bırakın ve Veritabanını Açın

Arşiv modunu devre dışı bırakmak için aşağıdaki komutları kullanın:

SQL> alter database noarchivelog;
SQL> alter database open;

6. Archive Logging Durumunu Kontrol Edin

Arşiv modunun başarıyla devre dışı bırakıldığından emin olmak için durumu kontrol edin:

SQL> archive log list

Beklediğiniz çıktı şu şekilde olmalıdır:

Database log mode            NOARCHIVELOG
Automatic archival           DISABLED
Archive destination          /mount_point/oradata/SID/ARCHIVE/arch
Oldest online log sequence   2
Current log sequence         3

Bu çıktıda “NOARCHIVELOG” ve “DISABLED” ifadelerini görüyorsanız, işlem başarılı olmuştur.

7. Veritabanını Normal Şekilde Yeniden Başlatın

Son olarak, veritabanını normal modda başlatın:

SQL> shutdown immediate
SQL> startup

Dikkat Edilmesi Gereken Noktalar

1. Yedekleme Stratejisi: Archive logging’i devre dışı bırakmadan önce mevcut yedekleme stratejinizi gözden geçirin. NOARCHIVELOG modunda çalışan veritabanlarında yalnızca soğuk yedekleme yapılabilir. Bu, sistemin kapalı olduğu bir anda tam bir yedek almayı gerektirir.
2. Performans Kazançları: Archive logging’i devre dışı bırakmak, disk I/O yükünü azaltabilir. Ancak, bu avantaj yalnızca belirli durumlarda geçerlidir. Örneğin, test ortamlarında veya geçici veriyle çalışan sistemlerde.
3. Kurtarma Yeteneği: Archive logging devre dışı bırakıldığında, yalnızca son tam yedekten itibaren kurtarma yapılabilir. Bu, özellikle kritik sistemlerde büyük veri kaybına neden olabilir.

Archive Logging’in Devre Dışı Bırakılmasının Alternatifleri

Eğer archive logging’i devre dışı bırakmak istemiyorsanız ancak performansı optimize etmek istiyorsanız şu seçenekleri düşünebilirsiniz:

1. Redo Log Boyutunu Artırma: Daha büyük log dosyaları, daha az sık yazma işlemi gerektirir.
2. Disk Yapılandırmasını İyileştirme: Arşiv loglarını hızlı bir depolama alanında saklamak performansı artırabilir.
3. Flashback Özelliklerini Kullanma: Archive logging olmadan veri kurtarma seçeneklerini artırmak için kullanılabilir.

Sonuç

Oracle Archive Logging’i devre dışı bırakmak, özellikle test ve geliştirme ortamlarında disk kullanımını azaltmak ve performansı artırmak için etkili bir yöntemdir. Ancak, bu işlem dikkatli planlama ve yedekleme stratejisi gerektirir. Yukarıdaki adımları izleyerek archive logging’i kolayca devre dışı bırakabilir ve veritabanınızı ihtiyaçlarınıza göre optimize edebilirsiniz.

Neden Veri Yedekleme?

Veri yedeklemenin birkaç önemli nedeni vardır:

• Donanım Arızaları: Fiziksel cihazlar zamanla arızalanabilir. Yedekleme, bu tür durumlarda verilerinizi kurtarmanızı sağlar.
• İnsan Hataları: Yanlışlıkla veri silme veya değiştirme durumları, yedekleme sayesinde telafi edilebilir.
• Siber Saldırılar: Ransomware gibi siber saldırılar sonucunda verilerinizi kaybetme riskiniz vardır. Düzenli yedekleme, bu tür tehditlere karşı bir koruma sağlar.

PostgreSQL Yedekleme Yöntemleri

1. SQL Dump ile Yedekleme
   PostgreSQL, veritabanı içeriğini bir SQL dosyası olarak dışa aktarmanızı sağlar. Aşağıdaki komut, cpynet veritabanının yedeğini alır:

pg_dump cpynet > cpynet_backup.sql

Bu komut, cpynet_backup.sql adında bir dosya oluşturur. İçerik, veritabanınızın yapısını ve verilerini içerir. Yedekleme işlemi tamamlandığında, dosya herhangi bir metin düzenleyici ile açılarak incelenebilir.
2. Kopyalama Yöntemi ile Yedekleme
pg_basebackup, tüm veritabanı kümesinin fiziksel bir yedeğini almak için kullanılır. Aşağıdaki komut ile yedekleme yapılabilir:

pg_basebackup -D /path/to/backup/dir -F tar -z -P

Burada, -D parametresi yedeklemenin kaydedileceği dizini belirtir. -F tar ise yedeği tar formatında alır. -z sıkıştırma ve -P ise ilerleme çubuğunu gösterir.
3. WAL Yedekleme
PostgreSQL, Write-Ahead Logging (WAL) sistemi sayesinde veri güvenliğini artırır. WAL dosyaları, veritabanındaki değişikliklerin kaydedilmesi için kullanılır. Bu dosyalar, yedekleme sürecinin bir parçası olarak saklanabilir. WAL dosyaları ile birlikte yedekleme yaparak, herhangi bir veri kaybı durumunda son durumu geri yükleyebilirsiniz.

PostgreSQL Geri Yükleme Yöntemleri

Yedekleme sonrası, veri kaybı yaşandığında geri yükleme işlemi de aynı derecede önemlidir. PostgreSQL’de geri yükleme için birkaç yöntem bulunmaktadır:

1. SQL Dump ile Geri Yükleme
   Yedekleme sırasında oluşturulan SQL dump dosyası ile geri yükleme işlemi şu şekilde yapılır:

psql cpynet < cpynet_backup.sql

Bu komut, cpynet_backup.sql dosyasındaki verileri cpynet veritabanına geri yükler.
2. Kopyalama Yöntemi ile Geri Yükleme
pg_basebackup ile alınan yedekleri geri yüklemek için öncelikle mevcut veritabanını durdurmanız gerekir. Ardından, yedek dizinine geçerek geri yükleme işlemini gerçekleştirebilirsiniz.

pg_ctl stop -D /path/to/your/data/directory
tar -xvf /path/to/backup/dir/cpynet_backup.tar -C /path/to/your/data/directory
pg_ctl start -D /path/to/your/data/directory

1. WAL ile Geri Yükleme
   WAL dosyaları ile geri yükleme işlemi, belirli bir zaman dilimindeki verileri geri almanıza olanak tanır. Bunun için, yedekleme ve WAL dosyalarını kullanarak PostgreSQL’in restore komutunu kullanmanız gerekir.

Sonuç

PostgreSQL’de veri yedekleme ve geri yükleme yöntemleri, veri kaybını önlemek ve verilerinizi güvenli bir şekilde yönetmek için hayati öneme sahiptir. Cpynet veritabanı örneği üzerinden incelediğimiz bu yöntemler, işletmelerin veri güvenliği stratejilerinin bir parçası olmalıdır. Yedekleme ve geri yükleme işlemlerini düzenli olarak gerçekleştirerek, veri kaybı riskinizi en aza indirebilirsiniz.

Düzenli yedekleme uygulamaları ve geri yükleme planları oluşturarak, veri güvenliğinizi artırabilir ve olası kayıpların önüne geçebilirsiniz. Unutmayın, her zaman verilerinizi güvende tutmak için bir yedekleme planınız olmalı!

• Log Dosyasının Boyutu: Listener log dosyası (listener.log) çok büyükse, listener yeni bağlantıları işleyemeyebilir. Bu durum genellikle disk alanı yetersizliğine yol açar.
• Disk Alanı Yetersizliği: Sunucuda yeterli disk alanı olmaması, listener’ın çalışmasını engelleyebilir.
• Yetki Sorunları: Oracle kullanıcı hesabının log dosyalarına erişim yetkisi olmaması.
• Sistem Kaynakları: Sunucuda aşırı yüklenme veya bellek sorunları da bu hatayı tetikleyebilir.

Problem Log

Aşağıdaki komutu çalıştırdığınızda:

[oracle@cpynet-oracle19c bin]$ lsnrctl start

Aşağıdaki hatayı alıyorsanız:

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 21-JUN-2024 15:00:49
Copyright (c) 1991, 2019, Oracle.  All rights reserved.
Starting /u01/app/oracle/product/19.3.0/dbhome_1/bin/tnslsnr: please wait...
TNS-12547: TNS:lost contact
TNS-12560: TNS:protocol adapter error
TNS-00517: Lost contact
Linux Error: 32: Broken pipe

Çözüm

1. Dizin Kontrolü
   İlk olarak, listener log dosyasının bulunduğu dizine gidin:

[oracle@cpynet-oracle19c ~]$ cd /u01/app/oracle/diag/tnslsnr/oracle19c/listener/trace/

1. Log Dosyasının Boyutunu Kontrol Edin
   Log dosyasının boyutunu kontrol edin. listener.log dosyasının 2GB altında olması gerektiğini unutmayın:

[oracle@cpynet-oracle19c trace]$ ll

1. Log Dosyasını Silin
   Eğer dosya boyutu 2GB’dan büyükse, aşağıdaki komutu kullanarak log dosyasını silin:

[oracle@cpynet-oracle19c trace]$ rm -f listener.log

1. Listener’ı Yeniden Başlatın
   Log dosyasını sildikten sonra listener’ı yeniden başlatmayı deneyin:

[oracle@cpynet-oracle19c trace]$ lsnrctl start

Sonuç

Yukarıdaki adımları takip ederek TNS-12547 hatasını gidermeyi deneyebilirsiniz. Eğer sorun devam ederse, aşağıdaki ek kontrolleri yapabilirsiniz:

• Disk Alanı Kontrolü: Sunucuda yeterli disk alanı olduğundan emin olun.
• Yetki Kontrolü: Oracle kullanıcısının yeterli yetkilere sahip olduğundan emin olun.
• Sistem Kaynakları: Sunucu üzerindeki yükü kontrol edin ve gerekirse sistem kaynaklarını artırın.

Gerekirse Oracle destek hizmetleri ile iletişime geçerek daha fazla yardım alabilirsiniz.

sqlplus / as sysdba

Ardından startup veya startup nomount komutunu verdiğinizde, aşağıdaki hatayı alıyorsanız:

ORA-03113: end-of-file on communication channel

Bu hata, veritabanı sunucusuyla iletişim kurarken bir kesinti olduğunu gösterir. Genellikle aşağıdaki durumlarda ortaya çıkar:

• Veritabanının düzgün başlatılmadığı veya kapatıldığı durumlar.
• Veritabanı dosyalarının bozulması veya eksikliği.
• Sunucu üzerinde kaynak yetersizliği veya bellek sorunları.
• Ağ bağlantısı sorunları.

Çözüm

Bu problemi çözmek için aşağıdaki adımları izleyebilirsiniz:

1. Trace Dosyalarını Temizleyin
   Aşağıdaki dizindeki .trc ve .trm uzantılı dosyaları temizleyin:

/u01/app/oracle/diag/rdbms/oracle19c/cdb1/trace

1. Gerekli Dosyaları Silin
   Aşağıdaki dosyaları silmekten çekinmeyin:

• *.trc uzantılı dosyaları silebilirsiniz; bu işlemi yaparken endişe etmenize gerek yoktur. Bu dosyalar, hata ayıklama için kullanılır ve silinmeleri, sistemin işleyişine zarar vermez.
• *.aud uzantılı dosyaları da silebilirsiniz; bu dosyalar, oturum kayıtlarıdır ve veritabanınızı etkilemeyecektir.
• alertlog_sid.log dosyasını silmeniz durumunda, veritabanı bu dosyayı yeniden oluşturacaktır. Bu dosya, veritabanı olaylarını ve uyarılarını kaydeder.

Sonuç

Yukarıdaki adımları takip ederek ORA-03113 hatasını gidermeyi deneyebilirsiniz. Eğer sorun devam ederse, veritabanı yapılandırmanızı ve sunucu kaynaklarınızı kontrol etmeniz faydalı olabilir. Gerekirse Oracle destek hizmetleri ile iletişime geçebilirsiniz.

1. Oracle Session Ayarlarını Yapın

Tablespace oluşturma işlemlerine başlamadan önce, aşağıdaki komutla Oracle session’ınızı uygun bir moda geçirin.

ALTER SESSION SET "_ORACLE_SCRIPT"=true;

2. Tablespace Oluşturma

Yeni bir tablespace oluşturmak için aşağıdaki komutu kullanabilirsiniz. Bu komut, tablespace adı, dosya adı, dosya boyutu, otomatik uzama boyutu gibi parametreler içerir.

CREATE TABLESPACE UNIQUE_TBS_NAME
LOGGING
DATAFILE 'UNIQUE_TBS_NAME.dbf' SIZE 1G REUSE
AUTOEXTEND ON NEXT 64M MAXSIZE 6G
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

Değiştirmeniz Gerekenler:

• UNIQUE_TBS_NAME: Oluşturulacak tablespace için benzersiz bir isim girin.
• UNIQUE_TBS_NAME.dbf: Tablespace için kullanılacak veri dosyasının adı. Tablespace adıyla aynı olabilir.

3. Kullanıcı Oluşturma ve Varsayılan Tablespace Atama

Yeni bir kullanıcı oluşturmak ve varsayılan olarak yeni oluşturulan tablespace’i atamak için aşağıdaki komutları kullanabilirsiniz.

CREATE USER UNIQUE_USER_NAME IDENTIFIED BY YOUR_PASSWORD DEFAULT TABLESPACE UNIQUE_TBS_NAME;

Değiştirmeniz Gerekenler:

• UNIQUE_USER_NAME: Kullanıcı adı benzersiz olmalıdır.
• YOUR_PASSWORD: Kullanıcı için belirleyeceğiniz parola.
• UNIQUE_TBS_NAME: Yukarıda oluşturduğunuz tablespace ismini kullanın.

4. Kullanıcıya Yetkiler Verme

Yeni oluşturduğunuz kullanıcıya gerekli yetkileri vermek için aşağıdaki komutları kullanabilirsiniz.

GRANT CREATE SESSION TO UNIQUE_USER_NAME;
GRANT CREATE VIEW TO UNIQUE_USER_NAME;
GRANT CREATE TABLE TO UNIQUE_USER_NAME;
GRANT EXECUTE ON DBMS_LOCK TO UNIQUE_USER_NAME;
GRANT SELECT ON PENDING_TRANS$ TO UNIQUE_USER_NAME;
GRANT SELECT ON DBA_2PC_PENDING TO UNIQUE_USER_NAME;
GRANT SELECT ON DBA_PENDING_TRANSACTIONS TO UNIQUE_USER_NAME;
GRANT EXECUTE ON DBMS_SYSTEM TO UNIQUE_USER_NAME;
GRANT EXECUTE ON DBMS_XA TO UNIQUE_USER_NAME;
GRANT RESOURCE TO UNIQUE_USER_NAME;
GRANT UNLIMITED TABLESPACE TO UNIQUE_USER_NAME;

Değiştirmeniz Gerekenler:

• UNIQUE_USER_NAME: Oluşturduğunuz yeni kullanıcı adını yazın.

5. Tablespace ve Kullanıcı Kontrolü

Oluşturduğunuz tablespace ve kullanıcının doğru şekilde oluşturulduğunu ve yetkilerin verildiğini doğrulamak için aşağıdaki sorguları kullanabilirsiniz.

• Tablespace Bilgisi Kontrolü:

SELECT TABLESPACE_NAME, STATUS, CONTENTS, AUTOEXTENSIBLE FROM DBA_TABLESPACES WHERE TABLESPACE_NAME = 'UNIQUE_TBS_NAME';

• Kullanıcı Yetkileri Kontrolü:

SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'UNIQUE_USER_NAME';

Sonuç

Bu adımları izleyerek Oracle üzerinde benzersiz bir tablespace oluşturabilir ve bu tablespace’i varsayılan olarak kullanacak yeni bir kullanıcı atayabilirsiniz. Yetki işlemlerini tamamladıktan sonra, kullanıcı belirlenen tablespace üzerinde işlemler yapabilecek yetkilere sahip olacaktır.