#HY000Host 'XXX' is not allowed to connect to this MySQL server

mysql> grant all privileges on *.* to logger@192.168.10.14 identified by 'logger';

Glassfish Performans Iyilestirme (Tuning)

      Bu makalemizde Glassfish`in performans iyilestirmelerini inceleyecegiz. Neden buna ihtiyac duyuyoruz, cunku benimde basima geldigi gibi, proje gelistirim asamasinda hersey normal olarak gorunuyor ama, bir production sisteme yuklemeye, yani gercek calisma ortamina gecmeye basladigimizda iste o zaman  sorunlarla karsilasmaya basliyoruz.

    Peki neden bu sekilde oluyor derseniz, cok basit olarak sunu dusunebiliriz, Mesala siz bilgisayariniz uzerinde uygulama gelistiriyorsunuz ve yaptiklarinizi test etmek icin, belkide gunde en az 4-5 defa yeniden deploy ediyorsunuz, ve iste bu sekilde yaptiginiz icin, her yeni redeploy yapiliminda server yeniden restart oluyor diyebiliriz, restart oluyordan kastim, butun degerler sifirlanip yeniden basliyor, buna JVM yani RAM deki objelerin silinmesi vs. gibi diger butun degerler ilk haline donuyor. Ama gercek bir uygulama sunucusa attigimizda, belkide burada aylarca hic restart ve redeploy olmadan sistemin calismasi gerekiyor ve bizde performans problemlerini burada yasiyoruz.

   Sizinde tahmin edebileceginiz gibi, Application Server icindeki butun parametreler default olarak ayarlanmis gelmektedir. Ve bizimde makalemizin konusu bu, buradaki parametreleri optimum hale getirmeye calisacagiz.

Sozu cok fazla uzatmadan ise koyulalim..

• Using the glassfish performance tuner
• Deployment Settings
• Logger Settings
• Web Container Settings
• EJB Container Settings
• Java Message Service Settings
• Transaction Service Settings
• HTTP Service Settings
• Network Listener Settings
• Transport Settings
• Thread Pool Settings
• ORB Settings
• Resource Settings
• Load Balancer Settings

Makalemizde yukaridakileri adim adim inceleyecegiz.

Oncelikle sunu belirteyim, performance tuner glassfish`in sitesinde indirdigimiz surumde mevcut degil, oracle kendi sitesinde indirmemiz gerekecek, simdi diyeceksiniz glassfish oracle`in degilmi diye, bunu detayli bir sekilde ben bilmiyorum ama en yakin zamanda ogrenip, paylasacam.

Download icin..

http://www.oracle.com/technetwork/middleware/glassfish/downloads/ogs-3-1-1-downloads-439803.html

(ogs-3.1.1-unix-ml.sh linux icin)
(ogs-3.1.1-windows-ml.exe windows icin)

Using the glassfish performance tuner

    Performance tuner glassfish`in bize server deployment icin gerekli tavsiyelerde bulunur ve optimum ayarlari yapmamizda yardimci olur.

Ben kendi bilgisayarim icin asagidaki ayarlamalari yaptim.

Yukaridaki 1.adim da yapilacaklar, ikinci adimda ayarlanmis degerler goreceksiniz ve gelen JVM ile ilgili onlarinda detaylarini JVM tuning makalemizde gorecegiz.

Deployment Settings

Deployment Settings performance icin onemli ayarlari icermektedir.

1- Disable auto-deployment

Burada bahsedilen otomatik deploy, yani .war file`ini yada .ear file`nizi glassfish`in (glassfish-3.0.1/glassfish/domains/domain1/autodeploy/) directorisine attiginiz zaman glassfish onu otomatik olarak deploy edecektir. ve edebilmesi icin auto-deployment parametresinin enable olmasi gerekiyor.

Ama biz production sistemimizde bu parametreyi disable yapmaliyiz, cunku glassfish surekli autodeploy klasorunu kullanmaya calismasin, bu parametreyi production server`imizde disable yaptigimizda performansi artiracaktir.

Ayarlamak icin (http://127.0.0.1:4848/common/index.jsf)

 domain -> Application Cofiguration altinda 

                   Auto Deploy : disable.

2-Use Pre-compiled JavaServer Pages

JSP sayfalarinin derlenmesi cok yogun kaynak ve zaman alici islemlerden biridir. JSP sayfalarinin deploydan once derlenmesi ciddi performance artisi saglayacaktir. Ve bu ozelligi kullandigimiz zaman sadece servlet file`lari deploy olacaktir.

Ayarlamak icin (http://127.0.0.1:4848/common/index.jsf)

 domain -> Application Cofiguration altinda 

                   Precompile: enable.

 3- Disable Dynamic Application Reloading

 Eger bu parametre enable ise, o zaman server ve uygulamadaki degisiklikleri periodik olarak incelecektir ve buda performance kayiplarina neden olacaktir. Production serverimizde bu parameteriyi disable yapacagiz.

Ayarlamak icin (http://127.0.0.1:4848/common/index.jsf)

 domain -> Application Cofiguration altinda 

                   Reload: disable.

Son hali goruntulu olarak

Logger Settings

 

JPQL`de SUM fonksiyonunda aritmetik islemler

Bilindigi gibi jpqlde sum fonksiyonunda aritmetiksel ismler yapmamiza izin vermiyor. Ama biz bunun gecici bir cozumunu asagidaki yontemle bulabiliriz.

Mesala ben asagidaki bir sql yazdigimda syntax error verecektir.

String sql = "SELECT SUM(p.price*l.quantity) FROM purchaseorders o JOIN orderlineitems l ON o.pono=l.pono JOIN products p ON l.prod_id=p.prod_id JOIN suppliers s ON p.sup_id=s.sup_id"

Ama biz asagidaki gibi bir class yaratip onu kullandigimizda sorunumuz cozulmus olacaktir.

    package jpqlexample.servlets;

    ...

    class LineItemSum {

           private Double price;

           private Integer quantity;

           private Double rslt;

           public LineItemSum (Double price, Integer quantity){

                 this.rslt = quantity*price;

           }

           public Double getRslt () {

                return this.rslt;

           }

           public void setRslt (Double rslt) {

                this.rslt = rslt;

           }

        }

Kullanimi :

String sql = "SELECT NEW jpqlexample.servlets.LineItemSum(p.price, l.quantity)

                       FROM PurchaseOrder o

                        JOIN o.orderLineItems l JOIN l.product p JOIN p.supplier"

Oracle faydali sql`ler

-> scheman'in indexlerinin cikartilmasi ve toplu olarak acilmasi(schemaadi yerine sizin schema adini girmelisiniz)

select 'alter index schemaadi.'||index_name||' monitoring usage;' from dba_indexes where owner=schemaadi order by table_name;


-> monitor'Un acilmasi tek bir index icin (index.adi yerine istediginiz indexin adini giriniz)

alter index "index.adi" monitoring usage;




-> izlenmesi ((schemaadi yerine sizin schema adini girmelisiniz)

select * from v$object_usage where owner=schemaadi;




->monitor'un kapatilmasi (index.adi yerine istediginiz indexin adini giriniz) 

alter index "index.name" nomonitoring usage;

sys as sysdba – insufficient privileges

sys as sysdba – insufficient privileges

Working on the Solaris server i always use ” / as sysdba” to login to the database.While creating a backup scripts, i used

sqlplus -s "sys@iddb as sysdba" 

Before testing the script, did a tnsping

bash-3.00$ tnsping iddb

TNS Ping Utility for Solaris: Version 10.2.0.3.0 - Production on 28-MAY-2010 17:00:44
Copyright (c) 1997, 2006, Oracle.  All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION= (ADDRESS_LIST= (ADDRESS =(PROTOCOL=TCP)

(HOST=XXX.XXX.XXX.XX)(PORT=XXXX))) (CONNECT_DATA= (SERVICE_NAME=iddb)))
OK (10 msec)

A log file is generated whenever the backup script is run.While checking the log file i saw the below error

ERROR:
ORA-01031: insufficient privileges

Hmmm…time for check -

bash-3.00$ sqlplus sys as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Fri May 28 17:29:51 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Enter password:

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning and Data Mining options

SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning and Data Mining options
bash-3.00$
bash-3.00$ sqlplus sys@iddb as sysdba

SQL*Plus: Release 10.2.0.3.0 - Production on Fri May 28 17:30:28 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Enter password:
ERROR:
ORA-01031: insufficient privileges

Check whether passwordfile exists or not??

bash-3.00$ cd $ORACLE_HOME/dbs
bash-3.00$ ls -lrt
total 21198
-rw-r-----   1 oracle1  dba         8385 Sep 11  1998 init.ora
-rwxr-xr-x   1 oracle1  dba         3854 Jul 24  2008 initiddb.ora
-rw-r-----   1 oracle1  other       2048 Sep 10  2009 orapwiddb.ora
-rw-r-----   1 oracle1  dba         7680 May 17 14:11 spfileiddb.ora
bash-3.00$

“orapwiddb.ora” file is present in ORACLE_HOME/dbs.Next was to check v$pwfile_users view

SQL> select * from v$pwfile_users;

no rows selected
SQL>; show parameter remote_login

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
remote_login_passwordfile            string      EXCLUSIVE

SQL>

Opppssss, “no rows selected”.Created a new password file

bash-3.00$ orapwd file=$ORACLE_HOME/dbs/orapwiddb.ora password=xyzyzx#123 entries=2
bash-3.00$ ls -lrt
total 24202
-rw-r-----   1 oracle1  dba         8385 Sep 11  1998 init.ora
-rwxr-xr-x   1 oracle1  dba         3854 Jul 24  2008 initiddb.ora
-rw-r-----   1 oracle1  other       2048 Sep 10  2009 orapwiddb.bkp
-rw-r-----   1 oracle1  dba         7680 May 17 14:11 spfileiddb.ora
-rw-r-----   1 oracle1  dba         1536 May 28 17:52 orapwiddb.ora
bash-3.00$
bash-3.00$

Granting sysdba privilege to SYS

SQL> grant sysdba to sys;
 grant sysdba to sys
*
ERROR at line 1:
ORA-01994: GRANT failed: password file missing or disabled

Something wrong!!!!! It say “password file missing or disabled”, even after creating the password file.Seems like, oracle is not able to read “orapwiddb.ora” file.Created a new password file with name “orapwiddb”

bash-3.00$ orapwd file=$ORACLE_HOME/dbs/orapwiddb password=xyzyzx#123 entries=2
bash-3.00$ ls -lrt
total 24202
-rw-r-----   1 oracle1  dba         8385 Sep 11  1998 init.ora
-rwxr-xr-x   1 oracle1  dba         3854 Jul 24  2008 initiddb.ora
-rw-r-----   1 oracle1  other       2048 Sep 10  2009 orapwiddb.bkp
-rw-r-----   1 oracle1  dba         7680 May 17 14:11 spfileiddb.ora
-rw-r-----   1 oracle1  dba         1536 May 28 17:58 orapwiddb

Lets try grant sysdba privilege to SYS now,

SQL> grant sysdba to sys;

Grant succeeded.

SQL> select * from v$pwfile_users;

USERNAME                       SYSDB SYSOP
------------------------------ ----- -----
SYS                            TRUE  TRUE

bash-3.00$ sqlplus 

SQL*Plus: Release 10.2.0.3.0 - Production on Fri May 28 18:05:01 2010

Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.

Enter user-name: sys@iddb as sysdba
Enter password:

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning and Data Mining options

SQL> exit

Oracle Hatalar

Error:
TNS-12537: TNS:connecton closed
TNS-12560: TNS:Protocol Adapter Error
Linux Error: 29 Illegal Seek ....when trying to start lisnr

Cozum:

Include in /etc/hosts file
127.0.0.1 localhost.localdomain localhost
 

DATAGUARD

Oracle Data Guard Kavramları, Kurulum ve Yönetimi

Oracle Data Guard , Oracle’da yüksek erişilebilirlik ve beklenmeyen sistem hataları neticesinde oluşabilecek veri kayıplarını en aza hatta sıfıra indiren oracle veritabanı ile bütünleşik bir veri koruma eklentisidir. Oracle enterprise sürümü gerektirir.Bütünleşiktir, ek kurulum gerektirmez. Veri tabanı hizmeti veren birincil sisteme (Primary) ek olarak bir veya daha fazla yedek (Secondary) sistem veya sistemlerin eş zamanlı veya eş zamanlı olmayan şekilde eşleştirilmesi prensibiyle çalışır. Çalışma prensibi , birincil veritabanında oluşan arşivlenmiş geridönüş loglarının (Archived Redo Logs) ikincil veritabanına aktarılması ve bu logların iki farklı yöntemle ikincil veritabına işlenmesine dayanır. Logların ikincil veritabanına işlenmesi yöntemi eşitlemenin fiziksel(Physical) mi mantıksal(Logical) mı olduğunu belirler. bu iki farklı işletim temel farklılıklar getirir. Sistemler birbirleriyle “Oracle Net” ile haberleşirler. Sistemler aynı ortamda veya uzak mesefalerde olabilirler. Sistemlerin yerleşimleri ile ilgili bir kısıtlama yoktur.

Fiziksel Bekleme Veritabanı (Physical Standby Database) : Birincil veritabanın birebir kopyasının ikincil veritabanında tutulmasıdır. İkincil veritabanı birincil veritabanın birebir kopyası olarak hazırlanır, birincil veritabanında oluşan arşiv geridönüşüm loglarının ikincil veritabanına uygulanması ile eşitlik sağlanmış olur. Fiziksel Bekleme Veritabanları açık veritabanları değillerdir. Startup Mount komutu ile açılırlar. birincil veritabanından gelen loglar Veritabanı Kurtarma(Database Recover) mantığıyla ikincil veritabanına işlenir. İstenirse ikincil vertabanı salt-okunur olarak açılabilir, fakat bu süre zarfında loglar işlenmez, biriktirilir. Tekrar işleme moduna alınarak logların işlenmesine devam edilebilir. Fiziksel Bekleme Veritabanları çoğunlukla felaket durumda kurtarma(disaster recovery) amaçlı olarak kullanılırlar. Felaket durumunda birincil veritabanının yerine geçecek olan veritabanı budur. böylece veri kaybı olmadan ve süre kaybetmeden kurtarım yapılmış olur.

Mantıksal Bekleme Veritabanı (Logical Standby Database) : Birincil veritabanının mantıksal olarak bir kopyasıdır, yani tablolar ve indexler gibi nesneler aynıdır fakat datafile dosyalarının düzeni farklılık gösterebilir. Birincil veritabanından gelen loglar SQL cümleciklerine çevrilerek işlenirler. Veritabanı açıktır, yani veritabanı üzerinde raporlama işlemleri yapılabilmektedir.Mantıksal veritabanına ait birtakım kısıtlamalar vardır. Bazı veri tipleri desteklenmemetedir. Ayrıca sistemdeki eşleşecek tabloların birincil anahtar indeksinin olması gerekmektedir. Oluşturulan SQL cümlecikler bu birincil anahtarlar kullanılarak işlenmektedir. Mantıksal veritabanları hem yedekleme için kullanılırlar hem de açık veritabanı oldukları için raporlama gibi işlemlerde de kullanılırlar. Böylece birincil veritabanının üzerinden yük alınarak performans artışı sağlanmış olur.

Oracle Data Guard 3 farklı koruma seviyesi sunar. Bunlar :

• Maksimum Koruma : Bu seviyede hiçbir veri kaybı olmaması sağlanır. Birincil veritabanında oluşan redo log dosyası eş zamanlı olarak en ez bir ikincil veritabanına kopyalanıp işlenemelidir. Eğer bir sorun olur da ikincil veritabanına işlenemez ise birincil veritabanı kapatılır.
• Maksimum Kullanılabilirlik : Bu seviye de maksimum korumada olduğu gibi sıfır veri kaybı hedeflenir, fakat hata durumunda veritabanı kapatılmaz, commit işlemi yapılmaz. hata düzelene kadar maksimum performans seviyesine geçilir. böylece veritabanının devamlılığı sağlanır. Hata düzeldikten sonra tekrar maksimum kullanılabilir seviye geçilir.
• Maksimum Performans : Bu seviye varsayılan seviyedir ve birincil veritabanın performansında azalma olmadan koruma sağlar. Birincil veritabanında işlem commit edilir ve online redo log dosyasına yazılır. Bu redo loglar eşzamansız olarak ikincil veritabanına aktarılır ve işlenir. Log dosyalarının aktarılmasında sorun olursa sorun düzeldikten sonra kalınan yerden işleme devam edilir.

Donanımsal ve Yazılımsal gereksinimler : Sistemler aynı platformlara sahip olmalıdırlar. Örneğin 32-bit intel Linux sisteme sahip olabilirler. Donanımsal olarak bir kısıt yoktur. Farklı sayıda işlemci , ram disk birimlerinden oluşabilirler. Oracle veritabının enterprise sürüm olması ve sürümlerinin aynı olması gerekmektedir. Standart sürümde çalıştıralamamaktadır. Birincil Veritbanının ARCHIVELOG modunda çalışması gerekmektedir. Bütün sistemlerde COMPATIBLE parametrelerinin aynı olması gerekmektedir.

Fiziksel Bekleme Veritabanının Oluşturulması :Fiziksel bekleme vertabanı oluşturulmadan önce birincil veritabanında birtakım ayarlar ve kontrollerin yapılması gerekir. Bunlar :

• Force Logging ayarının açılması : Aşağıdaki komutla birlikte veritabanın geçici Tablespace’lerin haricindeki tüm aktivitelerin loglanması sağlanır. Bu komuttan sonra NOLOGGING olarak ayarlanmış nesnelerde loglanmaya başlanır. Böylelikle bütün aktivitelerin log dosyalarına yazılması ve ikincil veritabanlarına uygulanması sağlanmış olur. SQL > Alter Database force logging;
  
• Standby Redo Log oluşturulması : Maksimum Koruma ve Maksimum Kullanılabilirlik seviyelerinin kullanılabilmesi için Standby Redo Logların oluşturulması gerekmektedir. Maksimum performans seviyesinde zorunlu değil fakat kullanılması performans ve koruma açısından fayda sağlar. Standby Redo Log dosyaları bekleme modundanki veritabanlarında çalışırlar. Bekleme modunda çalışma için dizayn edildiklerinden online redo loglara veya arşivlenmiş loglara göre daha fazla koruma sağlarlar. Oluşturulacak olan Standby Redo Logların boyutlarının mevcut Online Redo Logların boyutlarıyla aynı olması gerekmektedir. Aşağıda bir Standby Redo Log dosylarının oluştrulması gösterilmiştir.

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10

                        ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M;

Standy Redo Loglar ikincil veritabanlarında çalışırlar. Birincil veritabınında oluşturulması şartı yoktur. Fakat birincil ve ikincil veritabanlarının yer değiştirilmesi (switchover) işlemlerinden sonra düzgün çalışılabilmesi için birincil vertabanında da aynı şekilde Standby Redo Logların oluşturulması yararlı olacaktır. Aşağıdaki sorgu sistemdeki Standby Redo Logların durumu gösterir.  




SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;

         GROUP# THREAD#  SEQUENCE #ARC  STATUS

          -------  --------   ---------   --- ----------

                  3         1         16         NO  ACTIVE

                  4         0          0         YES UNASSIGNED

                  5         0          0         YES UNASSIGNED

Birincil Veritabanında Başlangıç Parametrelerinin Oluşturulması : Birincil veritabanında oluşan log dosyalarının ikincil veritabanlarına aktaramıyla ilgili parametreler oluşturulacaktır. Bunun yan
ında zorunlu olmasa da , daha sonra veritabanlarının rol değiştirmesi (switchover,failover işlemleriyle) gerekli olan , birincil veritabanının ikincil veritabanı olarak çalışması ile ilgili ayarlar da yapılacaktır. Aşağıdaki hem birincil hem de ikincil veritabanlarına ait ayırıcı bilgiler bulunmaktadır. Bu bilgiler parametrelerde kullanılacatır.

Veritabani	DB_UNIQUE_NAME*	Oracle Net Service Name
Birincil(Primary)	istanbul	istanbul
İkincil(Secondary)	ankara	ankara

* DB_UNIQUE_NAME parametre değişkenin her veritabanı için farklı olan, log transfer ayarlarında kullanılan bir değişkendir.Veritabanlarının log transferi seviyesinde birbirlerinden ayrılmalarını sağlar. Aşağıda birincil veritabanına ait bir başlangıç parametleri gösterilmektedir.

DB_NAME=istanbul

DB_UNIQUE_NAME=istanbul

LOG_ARCHIVE_CONFIG='DG_CONFIG=(istanbul,ankara)'

CONTROL_FILES='/opt/oracle/product/10gR2/dbs/control1.ctl',

                                        '/opt/oracle/product/10gR2/dbs/control2.ctl'

LOG_ARCHIVE_DEST_1='LOCATION=/opt/oracle/product/10gR2/archive/

VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
   DB_UNIQUE_NAME=istanbul'

LOG_ARCHIVE_DEST_2='SERVICE=ankara LGWR ASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)

DB_UNIQUE_NAME=ankara'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

LOG_ARCHIVE_MAX_PROCESSES=30

Yukarıdaki parametrelerin oracle başlangıç paremetre dosyasına yazılması gerekir. Öncelikle mevcut sistemdeki SPFILE bir dosyaya yazılır. Oluşturulan bu dosyaya yukarıdaki parametreler eklenir(Control_files parametresi zaten mevcuttur.) ve bu dosya kullanılarak yeni SPFILE oluşturulur.

SPFILE düzenlemesi istanbul #

istanbul # sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 – Production on Sal Mar 18 14:58:19 2008

Bağlantı:Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bit Production

With the Partitioning, OLAP and Data Mining options

SQL>

SQL> shutdown immediate;

SQL> --Veritabanı kapatıldı.

SQL> --Veritabanı kullanıma kapatıldı.

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

SQL> --Dosya yaratıldı.

Yukarıdaki parametrelerde LOG_ARCHIVE_DEST_1 parametresi sistemdeki online redo logların nereye arşivleneceğini belirtiyor. LOG_ARCHIVE_DEST_2 ise ikincil veritabanı hakkında bilgiler içeriyor.”SERVICE=ankara” parametresi logların ankara veritabanına aktarılacağını,”LGWR” aktarma için LGWR yönteminin kullanılacağını (ARCH da olabilir di) ,”ASYNC” ise aktarmanın eşzamansız olduğunu belirtiyor. Bu parametreler daha önce bahsettiğimiz 3 farklı koruma seviyesinden hangisinin kullanılacağını belirler.

Birincil Veritabanınında Log Arşivlemenin Ayarlanması : Eğer birincil veritabanında log arşivleme etkin değilse aşağıdaki komutlar ile etkin hale getirilmelidir.  




SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

  

Artık birincil veritabanı hazır hale geldi. bundan sonraki ilk işlem birincil veritabanına ait bütün datafile dosyalarının , Online Redo Logları ve oluşturulan Standby Redo Logların ikincil veritabanına kopyalanmasıdır. dosyalar ikincil veritabanına kopyalandıktan sonra birincil veritabanından controlfile ve initfile bilgileri aşağıdaki sorgularla alınır ve ikincil veritabanına işlenir.

• İkincil Veritabanı için Controlfile Dosyasının oluşturulması : İkincil veritbanına birincil veritabanına ait controlfile dosyalarının alınıp birebir kopyalanması hatalıdır. Bekleme modundaki ikincil veritabanı için önce birincil veritabanında “Standby Controlfile” oluşturulmalıdır. 

• SQL > STARTUP MOUNT; SQL > ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/ankara.ctl';

  Oluşturulan bu dosya ikincil veritabanına kopyalanmalıdır. Kopyalama SCP ve FTP kullanılarak yapılabilir. ikincil veritabanın da kontrol dosyalarının ‘/opt/oracle/product/10gR2/dbs/control1.ctl’ ve ‘/opt/oracle/product/10gR2/dbs/control2.ctl’ olduğunu, istanbul bilgisayarının ip adresinin ankara bilgisayarındaki /etc/hosts dosyasına tanımlı olduğunu varsayarsak aşağıdaki scp komutları ile kontrol dosyları kopyalanmış olur.
  
  

  ankara # scp istanbul:/tmp/ankara.ctl /opt/oracle/product/10gR2/dbs/control1.ctl; ankara # scp istanbul:/tmp/ankara.ctl /opt/oracle/product/10gR2/dbs/control2.ctl;

• İkincil Veritabanında Başlangıç Parametrelerinin Oluşturulması : İkincil veritabanının başlangıç parametreleri birincil veritabanına göre biraz farklılık gösterir.

  DB_NAME=ankara DB_UNIQUE_NAME=ankara LOG_ARCHIVE_CONFIG=’DG_CONFIG=(istanbul,ankara)’ CONTROL_FILES='/opt/oracle/product/10gR2/dbs/control1.ctl', '/opt/oracle/product/10gR2/dbs/control2.ctl'  LOG_ARCHIVE_DEST_1= 'LOCATION=/opt/oracle/product/10gR2/archive/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ankara' LOG_ARCHIVE_DEST_2='SERVICE=istanbul LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=istanbul' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc LOG_ARCHIVE_MAX_PROCESSES=30

  Buradaki LOG_ARCHIVE_DEST_1 ve LOG_ARCHIVE_DEST_2 ikincil veritabanı birincil veritabanına çevrilirse çalışacaktır.İkincil veritabanında bu parametreler çalıştırılmaz. Bu ayarlar yapıldıktan ve spfile dosyası yukarıda anlatıldığı gibi oluşturulur.Veritabanları başlatılmadan önce Oracle Net ayarlarının yapılması gerekmektedir. aşağıda birincil ve ikincil veritabanına ait TNSNAMES.ora dosyası vardır.
  
  
  ankara =(DESCRIPTION =(ADDRESS_LIST=

                         (ADDRESS = (PROTOCOL = TCP)(HOST = ankara)(PORT =

                  1521)))(CONNECT_DATA =(SERVICE_NAME = FINANS))) istanbul =(DESCRIPTION

                 =(ADDRESS_LIST =(ADDRESS = (PROTOCOL= TCP)(HOST = istanbul)(PORT = 1521)))

              (CONNECT_DATA

                =(SERVICE_NAME = FINANS)))

 İşletim sisteminde her iki bilgisayarda ping ankara ve ping istanbul komutlarının başarılı olması gerekmektedir. Başarılı değil ise linux sistemlerde /etc/hosts dosyasında gerekli tanımların yapılması gerekmektedir.

Artık her iki veritabanı başlatılabilir. Birincil veritabanı
ALTER DATABASE OPEN; komutuyla açılarak kullanıma başlanabilir. daha sonra listener hizmetinin açılması gerekir.

istanbul # lsnctrl start;

İkincil veritabanı ise STARTUP MOUNT; komutuyla
açılmalıdır. Daha sonra gelen log dosyalarının işlenmesini sağlamak için aşağıdaki komut çalıştırılır.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Artık yedekleme işlemi başlamış durumdadır.Birincil veritabanında;

SQL> alter system switch logfile;

Komutu ile bir arşiv log dosyası oluşturulur ve bu dosyanın ikincil veritabanına ulaşıp ulaşmadığı ve işlenip işlenmediği aşağıdaki komutla test edilebilir.İkincil veritabanında :

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;         SEQUENCE# APP          ---------    ---                    8     YES                    9     YES                  10      YES                  11      YES

Birincil veritabanında aşağıdaki sorgu çalıştırılarak sistemin işleyip işlemediği, var ise hatanın sebebi görülebilir.

SELECT * FROM V$ARCHIVE_DEST_STATUS WHERE STATUS 'DEFERRED' AND STATUS 'INACTIVE';