Production database in bir klonunu oluşturmak çoğu zaman test ve development işlemleri açısından işe yarayıcı olabilir.

Bu işlemler adım adım şu şekilde yapılır:

1.ADIM:
Production database e sqlplus üzerinden sysdba yetkisi olan bir kullanıcı ile bağlanıp şu komutu çalıştırıyoruz.
alter database backup controlfile to trace bu komut içinde database create syntaxini içeren bir dosya oluşturulur. Dosyanın oluşturulacağı yer trace file directory sidir. Bu directory i öğrenmek için user_dump_dest parametresine bakılmalıdır.
show parameter user_dump_dest
Trace dosyasının içinde şu kısım bizim için önemli:
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "PROD" NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 1168
LOGFILE
GROUP 1 'E:\PRODDB\REDO011.LOG' SIZE 50M,
GROUP 2 'E:\PRODDB\REDO012.LOG' SIZE 50M,
GROUP 3 'E:\PRODDB\REDO013.LOG' SIZE 50M,
GROUP 4 'E:\PRODDB\REDO021.LOG' SIZE 50M,
GROUP 5 'E:\PRODDB\REDO022.LOG' SIZE 50M,
GROUP 6 'E:\PRODDB\REDO023.LOG' SIZE 50M,
GROUP 7 'E:\PRODDB\REDO031.LOG' SIZE 50M,
GROUP 8 'E:\PRODDB\REDO032.LOG' SIZE 50M,
GROUP 9 'E:\PRODDB\REDO033.LOG' SIZE 50M
-- STANDBY LOGFILE
DATAFILE
'E:\PRODDB\SYSTEM01.DBF',
'E:\PRODDB\UNDOTBS01.DBF',
'E:\PRODDB\SYSAUX01.DBF',
'E:\PRODDB\USERS01.DBF',
'E:\PRODDB\APP01_DATA.DBF',
'E:\PRODDB\APP01_INDEX.DBF',
'E:\PRODDB\APP01_LOB.DBF',
'E:\PRODDB\APP01_REPORT_DATA.DBF',
'E:\PRODDB\APP01_REPORT_INDEX.DBF',
'E:\PRODDB\APP01_ARCHIVE_DATA.DBF',
'E:\PRODDB\APP01_ARCHIVE_INDEX.DBF',
'E:\PRODDB\APP01_DATA2.DBF',
'E:\PRODDB\APP01_INDEX2.DBF'
CHARACTER SET WE8ISO8859P9
;
# Recovery is required if any of the datafiles are restored
# backups, or if the last shutdown was not normal or immediate.
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;
2.ADIM

Production database i kapatıyoruz.

3.ADIM

Tüm datafile ları TEST veritabanının bulunduğu yere kopyalıyoruz.Eğer datafile ların adını değiştirmek istersek control file da ilgili yerlerde bu değişikleri yapmak zorundayız.

4.ADIM
Kritik bir adım: 1. adımda oluşturduğumuz create database scriptinin içindeki control file ın oluşturulduğu kısımda TEST database imize göre aşağıdaki değişikliği yapmak zorundayız.
CREATE CONTROLFILE REUSE DATABASE "PROD" NORESETLOGS
Şöyle değiştiriyoruz:
CREATE CONTROLFILE SET DATABASE "TEST" RESETLOGS ARCHIVELOG

5.ADIM:
Scriptten aşağıdaki satırları kaldıralım
# Recovery is required if any of the datafiles are restored
# backups, or if the last shutdown was not normal or immediate.
RECOVER DATABASE
# Database can now be opened normally.
ALTER DATABASE OPEN;
6.ADIM
Scripti db_create_controlfile.sql
olarak kaydedelim, bu arada değişen datafileların yerini değiştirmeyi unutmuyoruz.
Prod :
'E:\PRODDB\APP01_REPORT_DATA.DBF',
'E:\PRODDB\APP01_REPORT_INDEX.DBF',
Test :
'E:\TESTDB\APP01_REPORT_DATA.DBF',
'E:\TESTDB\APP01_REPORT_INDEX.DBF',
8.ADIM
bdump, udump, cdump directory lerini oluşturuyoruz.
9. ADIM
init.orayı test veritabanı dizinine kopyalıyoruz.
Copy E:\production_veritabanı\*.ora E:\test_veritabanı\
10. ADIM
Test veritabanını başlatıyoruz.
@ db_create_controlfile.sql

Untuk menanggulangi hal-hal yang tidak dikehendaki dalam dunia perdataan seperti hilangnya data maka sebisa mungkin kita harus melakukan backup. Ada dua jenis backup data pada Oracle yakni backup fisik dan lojik. Backup fisik berati melakukan backup pada file-file yang diperlukan oleh oracle ( file-file yang berekestensi .ctl, .dbf, .log ) sedangkan backup lojik berarti melakukan backup pada level tabel misalnya.

Ok, backup fisik nantinya akan dibagi lagi menjadi dua bagian yakni hot backup dan cold backup. Offline backup dengan kata lain merupakan cold backup. Secara umum bebeapa step untuk cold backup/offline backup adalah

1. Shutdown immediate  database
2. Copy semua file berkaitan ( file-file yang berekestensi .ctl, .dbf, .log )
3. Startup kembali

Dah segitu aja sangat sederhana ko..Capture-annya menyusul ya..Saya belum bisa upload karena technical error.

О терминах доступности:

«24x7» – аббревиатура обозначающая «двадцать четыре часа в сутки, семь дней в

24x7

неделю», обычно обозначающая, что бизнес функции компании или информационные системы (сервисы) доступны потребителям круглосуточно и никогда не останавливаются.

Расширенный формат термина «24х7х365», добавляет к фразе «триста шестьдесят пять дней в году», подчеркивая, что сервисы компании не прерываются в течение всего года.

«24/5» означает то же самое, но подразумевает выходные дни (субботу и воскресенье), когда сервисы могут быть недоступны.

«Девятки» (999, 9999, 99999) относятся к понятию «Доступность».

Доступность (Availability) в данном смысле слова  подразумевает под собой наличие возможности для пользователей компьютерной системы (людей или приложений) получить доступ к компьютерной системе в целях сбора, обработки, хранения или передачи информации.

Доступность измеряется в процентах из соотношения времени, когда система была доступна пользователям в течение заданного интервала времени, ко всему времени измерений. Иногда доступность измеряется с использованием «девяток», что округленно соответствует количеству девяток после запятой. Т.е. «доступность пять девяток» означает доступность 0.99999 или 99.999%. Применительно к году работы систем это означает допустимый простой всего в 5 минут в год. Это практически соответствует 24х7х365.

О сервере холодного резерва (пустующий сервер без кластерного программного обеспечения, выступающий в качестве резервного в случае выхода из строя основного сервера):

Использование холодного резерва вполне приемлемо в случаях, когда допустима остановка банковских систем на несколько часов.

Это самый дешевый вариант, но в наше время редко кто позволяет себе такой длительный простой.

При использовании сервера холодного резерва, в случае выхода из строя основного сервера, потребуется некоторый период времени для переключения производственной нагрузки на сервер холодного резерва.

Даже если не потребуется восстановление с ленточных носителей и есть возможность передать логические диски основного сервера с системы хранения данных серверу холодного резерва, все равно такое восстановление займет достаточно продолжительное время.

Standard versus rapid data recovery

У одного из наших заказчиков был случай, когда использование резервного сервера в качестве тестового (а это, как правило, все и делают с простаивающим сервером) привело к тому, что администраторы, к сожалению, не смогли оперативно переключиться на резервный сервер по причине изменения конфигурации сервера и нехватки дискового пространства. В довершение ко всему, в виду некорректных попыток восстановления работы сервера они испортили файловую систему и были вынуждены долго ждать ее восстановления. В результате был простой в несколько часов. В итоге руководство банка поставило задачу перед департаментом информационных технологий в кратчайшие сроки внедрить катастрофоустойчивую кластерную систему, что и было успешно реализовано нашей компанией на серверах IBM POWER 570 (процессоры POWER6) с использованием синхронной аппаратной репликации между площадками (EMC CLARiiON CX3-40), кластерным программным обеспечением SFHA/DR компании Symantec (VERITAS) и технологией мгновенного восстановления данных из моментальных копий (Snapshot Rollback).

Veritas Cluster Server (Symantec)

What is HOT / COLD backup?

Ada 2 tipe backup yang bisa kita lakukan di Oracle Database.

1. COLD/OFFLINE/CONSISTENT backup

Apa itu “Cold Backup” dan kenapa kita sebut “Cold” backup ?

Saat database DOWN, tidak ada aktifitas yang berjalan dalam database, tak ada seorangpun yang mengakses database. Saat itulah waktu kita lakukan backup dengan “COLD BACKUP”. Kita juga bisa menyebutnya dengan “OFFLINE” database backup.

Secara Singkatnya:

COLD sama dengan OFFLINE backup

COLD sama dengan CONSISTENT backup

Untuk COLD/OFFLINE/CONSISTENT database backup kita harus mematikan/SHUTDOWN Oracle Database dengan opsi sebagai berikut

1. SQL>shutdown normal

2. SQL>shutdown immediate

3. SQL>shutdown transactional;

4. SQL>shutdown abort;

5. CMD>net stop OracleService

Sebagai contoh dari cold backup di berbagai OS platforms.

1. conn with sysdba user

2. shutdown oracle database

3. copy init.ora, all datafiles, all redologs files, all controlfile to backup location

4. startup oracle database

NOTE: Database tidak memerlukan ARCHIVELOG mode untuk COLD backup.

2. What is HOT/ONLINE/INCONSISTENT backup?

Saat database dalam status Open, user mengakses database dan saat itu kita melakukan backup yang disebut “HOT,ONLINE, inconsistent” backup.

NOTE: Database harus dalam mode ARCHIVELOG untuk HOT backup.

Untuk HOT backup kita memiliki 2 opsi

1. RMAN Recovery Manager (Server Managed Backup)

2. User Managed Backup (User Managed backup)

“Cold backup” ı alınan ve archive log dosyaları yedeklenen bir sistemin
çökmesi ve erişilemez hale gelmesi durumunda veritabanı kurtarması nasıl
yapılır? Bu durumda elimizde çalışan sisteme ait controlfile dosyası ve Online
Redo Log dosyaları bulunmayacaktır. Elimizdeki Cold Backup ve archive log
dosyalarını kullanarak da kurtarma işlemi yapılabilir. Bunun için izlenmesi
gereken yol şudur:

1) “Cold Backup” ile alınan dosyalar (Datafile , controlfile, online redo log
dosyaları) ve Archive Log dosyaları yeni sistemde ait oldukları klasörlere
kopyalanır.

2) “oracle # sqlplus / as sysdba”  komutuyla sqlplus programı
çalıştırılır.

3) SQL> startup mount;      ile veritabanı “mount”
modunda başlatılır.

4) RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
komutuyla kurtarma işlemi başlatılır. Bu komutta normal kurtarma işleminden
farklı olarak “USING BACKUP CONTROLFILE” parametleri kullanılır. Çünkü elimizde
çöken sisteme ait son controlfile dosyaları yoktur. Hangi datafile dosyasına
hangi Archive Log dosyasının işleneceği bilinememektedir. Bu komut sayesinde
hangi archive log dosyalarının kullanılacağının kararı datafile dosyalarının
“header” bölümünde bulunan bilgiler kullanılarak karar verilir.

Komut çalışıtırıldığında aşağıdaki gibi bir sonuç verir.

ORA-00279: 347898987 değişikliği (03/20/2008 14:01:18
içinde oluşturulan) thread 1 için gerekli

ORA-00289: öneri: /opt/oracle/product/10gR2/dbs/arch/1_2_649864014.dbf

ORA-00280: 347898987 numaralı değişiklik (1 thread’i için), 2 numaralı sırasında

Günlüğü belirtin: {<RET>=önerilen | dosya adı | AUTO | CANCEL}

Bu aşamada sistem bize 4 farklı seçenek sunar.

a) ENTER tuşuna basarak önerdiği
archive log dosyasını işler.

b) Hangi archive log dosyasının
işleneceğini yazabiliriz.

c) AUTO yazıp enter a basarak
sormadan sırasıyla bütün archive log dosyalarının işlenmesini sağlar.

d) CANCEL yazıp enter a basarak
kurtarma işlemini bitirilmesini sağlar.

Bu komutlardan 3.sünü uygulayalım yani AUTO yazıp enter tuşuna basarak
archive log dosyalarının işlenmesini başlatalım. Sistemde mevcut en son archive
log dosyasına kadar bütün archive log dosyaları sisteme işlenir. En son dosyayı
işledikten sonra aşağıdaki gibi bir hata verir.

ORA-00308: arşivlenmiş
‘/opt/oracle/product/10gR2/dbs/arch/1_2_649864014.dbf’

günlüğü açılamaz

ORA-27037: dosya staüsü elde edilemiyor

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

Artık bütün archive log dosyaları işlenmiştir ve sıradaki archive log
dosyasını bulamadığı için hata vermiştir.

5) Archive log dosyalarını işledikten sonra veritbanını “ALTER DATABASE OPEN
RESETLOGS” komutuyla başlatırsak aşağıdaki gibi bir hata verir.

ALTER DATABASE OPEN RESETLOGS

*ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: 'system01.dbf'

Bu hatanın sebebi “RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; “
komutunun archive log dosyalarını işleme işleminin CANCEL komutuyla bitirilmesi
gerekliliğidir. Bu yüzden “ALTER DATABASE OPEN RESETLOGS” komutunu çalıştırmadan
önce tekrar “RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL; ” komutunu
çalıştırarak kurtarma işlemini başlatmamız ve komut olarak ta “CANCEL” komutunu
vermemiz gerekir.

SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

ORA-00279: 347898987 değişikliği (03/20/2008 14:01:18
içinde oluşturulan) thread 1 için gerekli

ORA-00289: öneri: /opt/oracle/product/10gR2/dbs/arch/1_2_649864014.dbf

ORA-00280: 347898987 numaralı değişiklik (1 thread’i için), 2 numaralı sırasında

Günlüğü belirtin: {<RET>=önerilen | dosya adı | AUTO | CANCEL}

CANCEL

6) Kurtarma işlemi tamalanmıştır. veritabanının RESETLOG parametresi ile
açılması gerekmektedir. Çünkü çöken sisteme ait son Online Redo Log dosyaları
elimizde yoktur. “Cold Backup” tan gelen Online Redo Log dosyaları kurtarılmış
veritabanıyla uyumsuzdur.

SQL> ALTER DATABASE OPEN RESETLOGS;

Artık veritbanı kutarılmıştır. Burada dikkat edilmesi gereken bir husus da,
çöken sistemden Online Redo Log dosyaları alınamadığından ve bu Online Redo Log
dosyalarının içinde bulunan ve arşivlenmemiş işlemler olduğundan, bu
arşivlenmemiş işlemler kaybedilmiş olacaktır. Online Redo Log dosyalarının
boyutları bu yüzden önem kazanmaktadır. Büyük boyutlu olması “Log switch”
işleminin ve Arşivleme işleminin daha az olmasını sağlarayarak performans artışı
getirirken, Kurtarma durumlarında daha fazla bilginin kaybolmasına sebep
olmaktadır. Bu yüzden Online Redo Log dosyalarının boyutlarının ayarlarken bu
konuya da dikkat edilmesi gerekir.