Oke, lanjut ke bagian ke 2, yaitu install OS RedHat Linux Enterprise. Sebenarnya install Linux ini biasa saja sih, ga terlalu banyak masalah yang berarti. Tapi biar lebih lengkap, saya berikan step by stepnya.

Pada bagian ini, akan saya jelaskan mengenai step-by-step menginstal linux versi RedHat Enterprise pada Vmware Workstation. Perlu diketahui, untuk menginstal OS Guest, hanya bisa dilakukan pada Vmware Workstation, tidak pada Vmware Player. Vmware Player hanya digunakan untuk menjalankan OS Guest saja.

Gambar 1. Untuk permulaan jalankan Daemon-Tools. Pada Search Bar Windows 7, ketikkan daemon, lalu klik pada DAEMON Tools. Pada bagian kanan bawah Taskbar akan muncul ikon kecil milik Daemon Tools. Klik kanan pada ikon tersebut, pilih Emulation -> All Option On, hingga ikon tersebut berubah warna menjadi hijau. Lalu klik kanan kembali -> Virtual CD Rom -> set 1 Device. Klik kanan kembali -> Virtual CD Rom -> Device 0 -> Mount Image, lalu pilih OracleEL1.nrg. File distribusi kali ini berekstension .nrg, sebenarnya tidak ada perbedaan jikalau file tersebut berekstension .iso.


Gambar 2. Layar utama VMware Workstation sebelum dijalankan.

Gambar 3. Jalankan VMWare.
Jika tampilan sudah seperti diatas, tekan ENTER.

Gambar 4. Selanjutnya akan muncul seperti layar diatas, klik Next untuk melanjutkan.

Gambar 6. Pada bagian Language Selection, pilih English(English), klik Next untuk melanjutkan.

Gambar 7. Pada bagian berikutnya Keyboard Configuration, pilih U.S English, lalu klik Next.

Gambar 8. Pada bagian Disk Partitioning Setup, pilih Automatic partition untuk memudahkan pembagian partisi. Klik Next untuk melanjutkannya.

Gambar 9. Kemudian akan muncul pesan kecil diatas, klik Yes untuk melanjutkan.

Gambar 10. Pada bagian Automatic Partitioning, klik Remove all partitions on this system, lalu klik Next.

Gambar 11. Kemudian akan muncul warning kembali, klik Yes untuk melanjutkannya.

Gambar 12. Pada bagian Disk Setup akan tampak pembagian partisi pada harddrive virtual, klik Next untuk melanjutkan.

Gambar 13. Pada bagian Boot Loader Configuration akan muncul pembagian GRUB boot loader. Karena yang terinstal hanya satu OS, maka tidak ada konfigurasi yang penting disini. Klik Next untuk melanjutkan.

Gambar 14. Pada Network Configuration, klik pada automatically via DHCP, lalu klik Next untuk melanjutkan.

Gambar 15. Pada Firewall Configuration, pilih No firewall, dan option Disabled pada Enabled SELinux. Lalu klik Next.

Gambar 16. Pada bagian Additional Language Support pilih English (USA), lalu klik Next untuk melanjutkan.

Gambar 17. Pada bagian Time Zone Selection, pilih Asia/Jakarta sebagai waktu TimeZone GMT. Lalu klik Next.

Gambar 18. Pada bagian Set Root Password, ketikkan password untuk root (super user). Pada bagian ini, password akan dikenal sebagai password utama OS, bukan password untuk User Account Anda. Lalu klik Next untuk melanjutkan.

Gambar 19. Pada bagian Package Installation Defaults, pilih bagian mana saja yang ingin diinstall. Pilih Customize software packages to be installed dan selanjutnya klik Next.

Gambar 20. Muncul window Package Group Selection. Pada bagian ini Anda bisa memilih bagian mana saja yang ingin diinstall, jika selesai klik Next untuk melanjutkan. Namun jika belum ingin mengkonfigurasi bagian ini, Anda bisa mengkonfigurasinya setelah instalasi ini selesai.

Gambar 21. Pada bagian About to Install cukup klik Next.

Gambar 23. Karena saya menggunakan 4CD installer, maka pilihan ini ada untuk yang menggunakan 4 CD installer. Akan muncul warning. Warning ini menyatakan CD berapa saja yang dibutuhkan untuk menginstall Linux RedHat. Pada contoh diatas muncul warning jika diperlukan Enterprise Linux 4AS #1 dan #2. Pastikan CD installer tersebut tersedia. Mungkin jikalau lebih banyak software yang ingin diinstall, maka ke-4 CD installer dibutuhkan. Klik Continue untuk melanjutkan.

Gambar 24. Linux akan otomatis menginstall OS didalam harddrive. Tunggu beberapa saat hingga selesai.

Gambar 26. Anda akan diminta untuk memasukan disk installer ke-2. Caranya klik kanan pada ikon Daemon Tools -> Virtual CD/DVD ROM -> Mount Image -> OracleEL2.nrg. Tunggu sebentar hingga kotak dialog Daemon Tools hilang. Lalu klik OK pada Vmware.

Gambar 27. Jika sudah selesai, akan muncul window seperti diatas. Anda akan diminta untuk merestart komputer. Sebelumnya, keluarkan CD instaler dari DVD ROM. Klik kanan ikon Daemon Tools -> Virtual CD/DVD ROM -> Unmount All Device. Lalu klik Restart.

Gambar 28. OS Linux akan restart dan kembali ke layar Welcome dan Licence Agreement. Cukup klik Next dan Accept Licence. Pada tab Date and Time, pilih hari dan tanggal serta jam. Pada tab Network Time Protocol, klik Enable Network Time Protocol, selanjutnya klik Next untuk melanjutkan.

Gambar 29. Pada bagian Display, pilih Resolusi dan Color Depth, selanjutnya klik Next.

Gambar 30. Pada bagian System User, masukan Username, Full Name, Password dan Confirm Password. Sebaiknya jangan gunakan oracle sebagai Username, karena username tersebut akan digunakan selanjutnya.

Gambar 31. Pada bagian Sound Card cukup klik Next.

Gambar 32. Begitu pula pada bagian Additional CDs.

Gambar 33. Lalu akan muncul window Finish Setup, klik Next untuk melanjutkan.

Gambar 34. Selanjutnya akan muncul layar Desktop utama Redhat Enterprise Linux 4 sebagai OS Guest.

Gambar 35. Selanjutnya, penginstalan Vmware Tools. Dengan Vmware Tools, performa OS Guest akan meningkat, karena akan mengambil sebagian resource dari OS Host, seperti VGA dan USB dan sebagainya.

Untuk menginstallnya cukup tekan CTRL-Alt jika berada pada OS Guest. Pilih VM pada jendela Vmware Workstation pada OS Host, lalu Install Vmware Tools. Klik layar Desktop OS Guest, maka akan muncul icon VMware Tools pada Desktop OS Guest. Klik dua kali untuk membukanya. Akan muncul 3 buah file. Pilih VMwareTools-xxxxxxx.rpm. Klik dua kali untuk membukanya. Akan ada konfirmasi Password for root. Masukan password root, lalu vmware tools akan segera terinstall.

Gambar 36. Instalasi Vmware tools. Jika sudah selesai, restart kembali OS Guest untuk melihat perbedaannya.

Gambar 37. RedHat Linux Enterprise 4 yang siap digunakan.

Selanjutnya, kita lanjutkan ke part 3

Oke 2 part sudah selesai, saatnya part ke-3. Instalasi Oracle DBMS.. Disini step-by-stepnya lumayan rumit sebab ya memang lumayan ribet untuk konfigurasi instalasi database yang satu ini.

Sebelum menginstall Oracle Database 10gR2, sebaiknya cek dahulu apakah paket-paket berikut ini sudah terinstall atau belum, caranya:

Buka Terminal RedHat Linux, lalu ketik perintah berikut ini:
# rpm -q binutils compat-db control-center gcc gcc-c++ glibc glibc-common \
> gnome-libs libstdc++ libstdc++-devel make pdksh sysstat xscreensaver libaio openmotif21
binutils-2.15.92.0.2-15
compat-db-4.1.25-9
control-center-2.8.0-12.rhel4.2
gcc-3.4.4-2
gcc-c++-3.4.4-2
glibc-2.3.4-2.13
glibc-common-2.3.4-2.13
gnome-libs-1.4.1.2.90-44.1
libstdc++-3.4.4-2
libstdc++-devel-3.4.4-2
make-3.80-5
pdksh-5.2.14-30.3
sysstat-5.0.5-1
xscreensaver-4.18-5.rhel4.9
libaio-0.3.103-3
openmotif21-2.1.30-11.RHEL4.4

Jika ada paket yang belum terinstall sebaiknya diinstal lebih dahulu. Paket-paket ini ada pada installer Linux RedHat Enterprise 4. Untuk menginstallnya gunakan mount-unmount pada Daemon Tools, sehingga muncul CD/DVD virtual pada layar Desktop Linux. File-file installer ini ada pada Folder RPMS disetiap CD Linux. Anda tinggal mencari file instalasi yang sesuai dengan kebutuhan diatas.

Membuat user dan user-group untuk Oracle

Gambar 1. Buka Terminal, login sebagai root (ketik: su, masukkan password root Anda, lalu tekan Enter). Ketikkan perintah seperti yang dikotakkan diatas.

Membuat Direktori

Gambar 2. Ketikkan perintah seperti diatas untuk membuat direktori baru. Namun jangan lupa untuk login sebagai root.

Konfigurasi Kernel Linux

Ketikkan perintah diatas (didalam box merah). Login pula sebagai root. Untuk login sebagai root, ketikkan su, lalu masukan password root.

Ketikkan pula beberapa perintah berikut ini:
cat >> /etc/security/limits.conf <<EOF
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
EOF

Gambar 5. Ketikkan perintah diatas untuk setting Shell pada Linux.

Untuk mengecek konfigurasi yang telah dibuat ketikkan script Terminal seperti diatas

Gambar 6. Penginstalan Oracle Database 10gR2 versi 10.2.0 pada Linux RedHat Enterprise 4. Cukup mengkopi file installer ke Desktop, lalu ketikkan: cd Desktop/ins pada Terminal. Lalu ketik: ./runInstaller
Perlu diketahui, Terminal mengandung case sensitif artinya ada perbedaan antara huruf kapital dan biasa.

Gambar 7. Jika, persyaratan sudah dipenuhi, maka akan muncul window seperti diatas. Pada kolom Oracle Home Location biarkan seperti kondisi defaultnya. Pada kolom Instalation Type pilih Enterprise Edition. Pada bagian Database Password, ketik password yang Anda inginkan, begitu juga pada Bagian Confirm Password, isikan dengan password yang sama. Lalu klik tombol Next.

Gambar 8. Installer akan menyiapkan file-file yang akan diinstal pada Linux, selanjutnya akan keluar window seperti berikut ini.

Gambar 9. Pada Specify Operating System Group Name pilih oinstall. Lalu klik Next untuk melanjutkan.

Gambar 10. Installer akan mengecek kriteria dalam komputer untuk disesuaikan dengan kebutuhan utamanya. Jika ada peringatan warning atau error, pelajari dan catat apa yang dijadikan sebagai masalahnya. Lalu centang pada bagian Status. Selanjutnya klik Next untuk melanjutkan.

Gambar 11. Layar berikutnya akan muncul konfirmasi apa saja yang akan diinstal pada Linux tersebut, jika ada yang kurang pada konfigurasi installer database, Anda bisa mengklik Back, untuk melanjutkannya klik Next.

Gambar 12. Software Oracle yang sedang menginstall. Tunggu beberapa saat hingga database benar-benar terinstall dan muncul window seperti berikut ini.

Gambar 13. Jika database sudah terinstall akan keluar pesan kecil seperti ini. Layar ini akan bertanya apakah kita ingin menginstall database lain selain database yang dimiliki oleh SYSTEM atau tidak. Capture screen pada bagian ini. Lalu klik OK.

Gambar 14. Selanjutnya akan muncul window Configuration Assistants, pada bagian ini Installer akan mengkonfigurasi secara otomatis. Lalu klik Next untuk melanjutkan.

Gambar 15. Oracle akan membuat database dan starting Oracle Instance. Tunggu beberapa saat hingga bagian ini selesai dijalankan.

Gambar 16. Selanjutnya akan muncul window Execute Configuration scripts, ikuti 4 step diatas untuk menginstall dan memvalidasi hasil install. Setelah itu klik OK.

Gambar 17. Eksekusi kedua script diatas pada Terminal.

Gambar 18. Jika software telah benar-benar diinstal akan muncul konfirmasi seperti diatas. Pada window ini saya anjurkan untuk meng-capturenya kembali dan disimpan. Klik Exit untuk mengakhiri instalasi database Oracle.

Gambar 19. Hasil akhir jika database benar-benar terinstall. Lakukan query:

.oraenv >> orcl
rlwrap sqlplus / as sysdba


Selamat, Oracle database telah terinstall di Linux Anda.

Hi all…

Sudah lama nih ga buka ni blog lagi, maklum lagi sibuk kerjain skripsi,, yang notabene susahnya minta ampun..

Sekedar pengen sharing aja… Kali ini aku bakalan kasih tahu cara-cara instalasi Oracle Database 10g di Linux. Oracle yang saya pake adalah Oracle 10g R2 tepatnya 10.2.0. Untuk dapetinnya silakan klik link INI.Trus instalasinya melalui OS Linux Red Hat Enterprise yang notabene juga saya dapatkan dari Oraclenya langsung. Lalu instalasinya lewat VMWare Workstation versi 6.5, sehingga ga perlu dual booting OS lagi… hehehe…

Oke deh, langsung aja aku kasih unjuk cara-caranya yap..

1. Instalasi VMWare Workstation.

Instalasi VMWare Workstation akan juga langsung nginstalin VMWare player, jadi seandainya kalau file OS-nya rusak bisa di-copy dari backup trus dijalanin ulang tanpa mesti instalasi ulang OS yang rusak tersebut.

Untuk Instal VMWare lakukan seperti menginstal program biasa.

Gambar 1. Untuk menjalankan vmware klik Start lalu ketik vmware pada Search Bar Windows 7, lalu pilih Vmware Workstation. Selanjutnya akan muncul seperti Windows seperti diatas. Lalu pilih File -> New -> Virtual Machine atau CTRL-N. Maka layar berikut akan muncul pada Desktop.


Gambar 2. Kotak dialog New Virtual Machine Wizard akan muncul, untuk memudahkan pilih Typical (recommended). Jika dipilih Custom (advanced) akan muncul beberapa pilihan yang lebih detil lagi, tapi saya anjurkan untuk memilih Typical saja. Lalu klik tombol Next.

Gambar 3. Kotak dialog New Virtual Machine Wizard yang kedua akan segera muncul, jika pada DVD-ROM sudah dimasukan DVD installer RedHat Enterprise, Anda bisa memilih opsi pertama. Jika anda memiliki file .iso (image) installer RedHat Enterprise anda bisa mengklik opsi kedua. Jika belum memiliki DVD installer maupun .iso RedHat, pilih opsi ketiga. Namun saya anjurkan untuk memilih opsi ketiga, karena beberapa setting akan diubah berikutnya. Klik Next untuk melanjutkan.

Gambar 4. Tampilan berikut pilih Linux pada Guest Operating System, lalu pada box Version pilih RedHat Enterprise Linux 4. Lalu klik Next untuk melanjutkan.

Gambar 5. Kotak dialog baru akan muncul. Isikan Nama virtual OS yang baru, lebih baik baris ini dibiarkan saja. Lalu pada baris berikutnya tentukan dimana file OS akan disimpan. Saran saya pilih partisi yang memiliki space kosong yang lumayan banyak. Sebab file ini akan bertambah seiring dengan perubahan didalam virtual OS. Klik Next untuk melanjutkan.

Gambar 6a. Kotak dialog Hardware akan muncul, pada kolom memori isikan berapa MB RAM yang dibutuhkan. Untuk kali ini saya mencoba dengan 768 MB saja, sebab nanti akan diinstal Oracle Database yang memakan memori cukup besar. Pada baris berikutnya yaitu New CD/DVD (IDE), pilih drive mana DVD-ROM Anda berada, jika salah setting maka virtual OS tidak akan pernah booting. Setting lainnya sepertinya bisa diabaikan. Lalu klik OK.

Gambar 6b. Ini window hasil setting, lalu tekan OK.

Gambar 7. Setelah itu virtual OS sudah dibuat. Untuk menjalankannya, cukup tekan Power on this virtual machine.

Gambar 8. Jika belum ada OS yang terinstall pada vmware, maka akan tampak seperti gambar diatas. Untuk menghentikannya cukup tekan tombol Stop pada Toolbar VMware Workstation.

Oke, step pertama berhasil, lanjut ke step ke 2

Oracle version number detail explaination:

Hi friends,

How to check Oracle version from installed Oracle database RDBMS?

Using following queries we can check version of Oracle has been installed.

SQL>select * from v$version;
BANNER
—————————————————————-
Oracle Database 10g Express Edition Release 10.2.0.1.0 – Product
PL/SQL Release 10.2.0.1.0 – Production
CORE 10.2.0.1.0 Production
TNS for 32-bit Windows: Version 10.2.0.1.0 – Production
NLSRTL Version 10.2.0.1.0 – Production

SQL>select * from product_component_version;
PRODUCT VERSION STATUS
—————————————- ———— ———-
NLSRTL 10.2.0.1.0 Production
Oracle Database 10g Enterprise Edition 10.2.0.1.0 Prod
PL/SQL 10.2.0.1.0 Production
TNS for 32-bit Windows: 10.2.0.1.0 Production

Interpretation and understanding of Oracle version numbering:

First digit is Major database release number
Second digit is Database maintenance release number
Third digit is Application server release number
Fourth digit is Component specific release number
Fifth digit is Platform specific release number

For Example take output of above sample:
Oracle 10.2.0.1.0

Explained:

Oracle 10 <=Major database release number
.2 <=Database maintenance release number
.0 <=Application server release number
.1 <=Component specific release number
.0 <=Platform specific release number

Thanks and regards,
Rajiv Shah
http://www.dbametrix.com
http://www.dbametrix.com/remote-dba.html

Applying one-off interim patch of Oracle using OPATCH utility:

Hi friends,

Today we are discussing about Oracle upgrade for applying interim or one-off patch. Interim patch or one-off patch is applied by Opatch utility.

Opatch utility is provided by Oracle itself. If Opatch utility doesn’t install or doesn’t find out in your ORACLE_HOME then you should require to download from Oracle Support site.

Oracle’s oneoff patch or interim patch is installed by Opatch only. For check weather opatch utility has been installed or not check following commands.

$ cd $ORACLE_HOME/OPatch
$ opatch -help
Invoking OPatch 10.2.0.4.2

Oracle Interim Patch Installer version 10.2.0.4.2
Copyright (c) 2007, Oracle Corporation. All rights reserved.

Usage: opatch [ -help ] [ -r[eport] ] [ command ]

command := apply
lsinventory
napply
nrollback
rollback
query
version
prereq
util

:= -help Displays the help message for the command.
-report Print the actions without executing.

example:
‘opatch -help’
‘opatch apply -help’
‘opatch lsinventory -help’
‘opatch napply -help’
‘opatch nrollback -help’
‘opatch rollback -help’
‘opatch prereq -help’
‘opatch util -help’

OPatch succeeded.

For applying any interim or one-off patch please find easy steps.

1) set ORACLE_HOME environment variable.

$ export ORACLE_HOME=/home/oracle10g

2) set JAVA_HOME environment variable.
OPatch requires JDK 1.4 or higher to work properly. JRE is installed using JDK.

$ export JAVA_HOME=/home/jdk/bin/java

3) set proper lsinventory using Opatch using following command.

$ OPatch lsinventory

4) Go to unzipped directory of patch using following command.

cd $ORACLE_HOME/OPatch

5) apply interim or one-off patch of Oracle.

$ /opatch apply /u01/patch/8708077

It will be applied your given one-off interim patch.

Log file of Opatch utility of Oracle:

OPatch maintains logs for all apply, rollback, and lsInventory operations. The log files are located in /cfgtoollogs/opatch directory. Each log file will be tagged with the timestamp of the operation. Log files are named as opatch__.log. Each time OPatch is executed a new log file is created.

Sample:
opatch_09-22-2009_20-05-00.log

How to rollback one-off interim patch whenever find problem:

$ opatch rollback /u01/patch/8708077

OR

$ OPatch/opatch rollback -id

For more detail and troubleshooting of opatch please refer oracle documentation or wait to publish another post.

Thanks and regards,
Rajiv Shah
http://www.dbametrix.com
http://www.dbametrix.com/service.html

To protect against a failure involving the redo log itself, Oracle Database allows a multiplexed redo log, meaning that two or more identical copies of the redo log can be automatically maintained in separate locations. For the most benefit, these locations should be on separate disks. Even if all copies of the redo log are on the same disk, however, the redundancy can help protect against I/O errors, file corruption, and so on. When redo log files are multiplexed, LGWR concurrently writes the same redo log information to multiple identical redo log files, thereby eliminating a single point of redo log failure.

Multiplexing is implemented by creating groups of redo log files. A group consists of a redo log file and its multiplexed copies. Each identical copy is said to be a member of the group. Each number defines a redo log group. Such as group 1, group 2, and so on.

For information about how to find your current online redo log files structure click here.

1. Adding A New redo log Group

sql> ALTER DATABASE ADD LOGFILE(‘/oracledata/test/redo3a.log’,'/test_multiplex/redo3b.log’) SIZE 52429312;

- The command above will add a new redo log group to your database. The group will have two members with size 52429312. A group number will automatically be assigned to your new group. If you want to set it explicitly you may use command below.

sql> ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 15 (‘/oracledata/test/redo3a.log’,'/test_multiplex/redo3b.log’) SIZE 52429312;

- In a RAC (Real Application Cluster) environment you have to specify which instance the redo log group will belong to by setting thread number. Every instance in a RAC database has a thread number. For ex: the command below will add the redo log group to instance with thread number 1.

sql> ALTER DATABASE ADD LOGFILE THREAD 1 GROUP 15 (‘/oracledata/test/redo3a.log’,'/test_multiplex/redo3b.log’) SIZE 52429312;

2. Dropping A redo log Group

– Before dropping a redo log group, make sure that at the moment, logwriter process is not writing to the redo log file you plan to drop.

sql> SELECT GROUP#, THREAD#,ARCHIVED, STATUS FROM V$LOG ;

    GROUP#    THREAD#       ARC        STATUS

———-         ———- —        ——       ———

         1                    1                 YES          INACTIVE

         2                    1                  NO            CURRENT

         3                    1                  YES         INACTIVE

The value for “ARCHIVED” column must be “YES” and STATUS column must be “INACTIVE”.

If the status is “CURRENT” it means that logwriter is currently using this group to store redo records. After the redo files in this group is filled it will switch to next group. You may wait till next log switch operation or you may manually trigger it by command below:

SQL> alter system switch logfile ;

If status is “ACTIVE” it means that there are some redo log records, which have not been applied to datafiles yet. The status is supposed to turn to INACTIVE soon after the next checkpoint operation. If you do not want to wait till then you may manually trigger checkpoint by command below.

sql> alter system checkpoint ;

If the status has turned to INACTIVE you may drop it by specifying the group number.

sql> ALTER DATABASE DROP LOGFILE GROUP 6;

This command will drop the redo log group, which is identified by number 6.

Logwriter writes to redo log files in a circular fashion. When a group is filled it moves to next group. After all groups in database are filled it returns back to first redo log group. Because of that, there has to be at least 2 groups in an instance. Oracle won’t permit dropping a group if there are only two groups in the instance.

After dropping a group, you may delete relevant files from operating system.

3. Adding A New Member To An Existing Group

As mentioned at the beginning of article it is recommended to multiplex redo log members for fault tolerance. You can accomplish this by adding new members to an existing group.

sql> ALTER DATABASE ADD LOGFILE MEMBER ‘/u02/oradata/mydb/redo02.log’ TO GROUP 2;

The above command adds a new redo log file to redo log group with number 2.

4. Dropping A Member From An Existing Group

As stated in subject 3 (Dropping A redo log Group) again the group, whose member you want to drop should be inactive.

sql> ALTER DATABASE DROP LOGFILE MEMBER ‘/u03/oradata/mydb/redo03.log’

5. Relocating A redo log Group

You may want to relocate your existing redo log group and change the path of redo log files. Here are the steps to accomplish it

Step 1: Shutdown database

sql> shutdown immediate ;

Step 2: Backup your existing control file and redo log file at operating system level.

Step 3: Move your redo log member to a new location. You may also change the file name if you want.

# mv /u02/oradata/mydb/redo02.log /u03/oradata/mydb/redo03.log

Step 4: Startup in nomount mode

sql> startup nomount;

Step 5: Path of redo log files is kept in control file. You have to update that record by command below:

sql> ALTER DATABASE RENAME FILE ‘/u02/oradata/mydb/redo02.log’ TO ‘/u03/oradata/mydb/redo03.log’

Control file is modified and the path of redo log member is updated. Now you can open your database.

sql> alter database open;

As you see this way of relocating online redo log files requires downtime.  You may also change the path of your redo log files by adding a new group at desired location and dropping the ones at former location. This approach requires no downtime.

Using  SQL Interface: There are 2 main dynamic performance views to see your database’s current redo log structure.

 1. v$logfile => Shows redo log groups, group members and member status.

sql> select group#,status,member from v$logfile

Here, this database has 3 redo log groups with 3 members. You can see the path of redo log files and see which group they belong to. If status is null then it means that the file is in use.

2. v$log => This view provides information about your redo log groups. This information is fetched from control file.

sql> select group#,archived,members,status from v$log ;

Here this database has 3 groups, which are identified by numbers 1,2,3. At the moment group 1 is the current redo log group. Redo records are written to this group. Group 2 and 3 are inactive and they have been archived. After redo log files in group 1 are filled then redo log records will be written to group 2 then group 3 respectively.

If status of a redo log file is “ACTIVE “it means that this file was recently used then log writer process switched to another redo log group. But still there are some redo records in active group, which has not been applied to datafiles yet. If you see a group with a status “ACTIVE” it should return to status “INACTIVE” soon without manual intervention.

3. There is one more view V$LOG_HISTORY where you can see information about your redo log history. But the information you can extract from this view is not as user-friendly as the two views above. You won’t be dealing with V$LOG_HISTORY view in your routine tasks so we won’t mention it in this article.

Using Operating System

On Linux:

If the database was setup according to Oracle Flexible Architecture ( For more information on OFA on Linux click here) online redo log files will be in redolog<counter>.log or redo<counter>.log format where counter shows the order of online redo log files. So performing a search at operating system level will give you the list of online redo log files.

The command below will start searching from root location (/) and will look for any file, which starts with “redo” and has an “.log” extension.

[root@myserver ~]# find / -name redolog*.log -type f

/u01/oracle/product/10.2.0/oradata/my_db/redolog01.log
/u02/oracle/product/10.2.0/oradata/my_db/redolog02.log
/u03/oracle/product/10.2.0/oradata/my_db/redolog03.log

The files found are “probably” the online redo log files for the instance but it is also possible that they are not associated with an instance. They might me obsolete. Because of that it is more reliable to locate redo log files via sql interface than operating system interface.

On Windows:

If the database was setup according to Oracle Flexible Architecture ( For more information on OFA on Windows click here) online redo log files will be in redolog.log or redo.log format where shows the order of online redo log files. So performing a search at operating system level will give you the list of online redo log files.

The command below will  start searching from root location of drive E and will look for any file, which starts with “redo” and has an “.log” extension.

E:\>dir /s redo*.log
 E sürücüsü birimi: Data
 Birim Seri Numarası: 6CC3-6A8A

 E:\oracle\product\10.2.0\oradata\mydb dizini

14.12.2009  09:19        52.429.312 REDO01.LOG
11.12.2009  18:10        52.429.312 REDO02.LOG
11.12.2009  18:10        52.429.312 REDO03.LOG
               3 Dosya      157.287.936 bayt

     Listelenen Toplam Dosya:
               3 Dosya      157.287.936 bayt
               0 Dizin   157.829.578.752 bayt boş

The files found are “probably” the online redo log files for the database but they might not be associated with a database. They might me obsolete. Because of  that it is more reliable to locate online redo log files via sql interface than operating system interface.

DATAPUMP IN ORACLE

For using DATAPUMP through DB CONSOLE

http://www.oracle.com/technology/obe/obe10gdb/storage/datapump/datapump.htm

There are two new concepts in Oracle Data Pump that are different from original Export and Import.

Directory Objects

Data Pump differs from original Export and Import in that all jobs run primarily on the server using server processes. These server processes access files for the Data Pump jobs using directory objects that identify the location of the files. The directory objects enforce a security model that can be used by DBAs to control access to these files.

Interactive Command-Line Mode

Besides regular operating system command-line mode, there is now a very powerful interactive Command-line mode which allows the user to monitor and control Data Pump Export and Import operations. Changing from Original Export/Import to Oracle Data Pump Creating Directory Objects

In order to use Data Pump, the database administrator must create a directory object and grant privileges to the user on that directory object. If a directory object is not specified, a default directory object called data_pump_dir is provided. The default data_pump_dir is available only to privileged users unless access is granted by the DBA.

In the following example, the following SQL statement creates a directory object named

dpump_dir1 that is mapped to a directory located at /usr/apps/datafiles.

Create a directory.

1. SQL> CREATE DIRECTORY dpump_dir1 AS ‘/usr/apps/datafiles’;

After a directory is created, you need to grant READ and WRITE permission on the directory to other users. For example, to allow the Oracle database to read and to write to files on behalf of user scott in the directory named by dpump_dir1, you must execute the following command:

1. SQL> GRANT READ,WRITE ON DIRECTORY dpump_dir1 TO scott;

Note that READ or WRITE permission to a directory object means only that the Oracle database will read or write that file on your behalf. You are not given direct access to those files outside of the Oracle database unless you have the appropriate operating system privileges. Similarly, the Oracle database requires permission from the operating system to read and write files in the directories. Once the directory access is granted, the user scott can export his database objects with command arguments:

1. >expdp username/password DIRECTORY=dpump_dir1 dumpfile=scott.dmp

Comparison of command-line parameters from Original Export and Import to

Data Pump

Data Pump commands have a similar look and feel to the original Export and Import

commands, but are different. Below are a few examples that demonstrate some of these

differences.

1) Example import of tables from scott’s account to jim’s account

Original Import:

> imp username/password FILE=scott.dmp FROMUSER=scott TOUSER=jim TABLES=(*)

Data Pump Import:

> impdp username/password DIRECTORY=dpump_dir1 DUMPFILE=scott.dmp

TABLES=scott.emp REMAP_SCHEMA=scott:jim

Note how the FROMUSER/TOUSER syntax is replaced by the REMAP_SCHEMA option.

2) Example export of an entire database to a dump file with all GRANTS,

INDEXES, and data

> exp username/password FULL=y FILE=dba.dmp GRANTS=y INDEXES=y ROWS=y

> expdp username/password FULL=y INCLUDE=GRANT INCLUDE= INDEX

DIRECTORY=dpump_dir1 DUMPFILE=dba.dmp CONTENT=ALL

Data Pump offers much greater metadata filtering than original Export and Import. The INCLUDE parameter allows you to specify which object (and its dependent objects) you want to keep in the export job. The EXCLUDE parameter allows you to specify which object (and its dependent objects) you want to keep out of the export job. You cannot mix the two parameters in one job.

Both parameters work with Data Pump Import as well, and you can use different INCLUDE and

EXCLUDE options for different operations on the same dump file.

3) Tuning Parameters

Unlike original Export and Import, which used the BUFFER, COMMIT, COMPRESS,

CONSISTENT, DIRECT, and RECORDLENGTH parameters, Data Pump needs no tuning to achieve maximum performance. Data Pump chooses the best method to ensure that data and metadata are exported and imported in the most efficient manner. Initialization parameters should be sufficient upon installation.

4) Moving data between versions

The Data Pump method for moving data between different database versions is different from the method used by original Export and Import. With original Export, you had to run an older version of Export to produce a dump file that was compatible with an older database version.With Data Pump, you use the current Export version and simply use the VERSION parameter to specify the target database version. You cannot specify versions earlier than Oracle Database 10g (since Data Pump did not exist before 10g).

Example:

> expdp username/password TABLES=hr.employees VERSION=10.1

DIRECTORY=dpump_dir1 DUMPFILE=emp.dmp

Data Pump Import can always read dump file sets created by older versions of Data Pump Export.

Note that Data Pump Import cannot read dump files produced by original Export.

Maximizing the Power of Oracle Data Pump

Data Pump works great with default parameters, but once you are comfortable with Data

Pump, there are new capabilities that you will want to explore.

Parallelism

Data Pump Export and Import operations are processed in the database as a Data Pump job, which is much more efficient that the client-side execution of original Export and Import. Now Data Pump operations can take advantage of the server’s parallel processes to read or write multiple data streams simultaneously (PARALLEL is only available in the Enterprise Edition of Oracle Database.)

The number of parallel processes can be changed on the fly using Data Pump’s interactive command-line mode. You may have a certain number of processes running during the day and decide to change that number if more system resources become available at night (or vice versa).

For best performance, you should do the following:

• Make sure your system is well balanced across CPU, memory, and I/O.

• Have at least one dump file for each degree of parallelism. If there aren’t enough dump Files, performance will not be optimal because multiple threads of execution will be trying to access the same dump file.

• Put files that are members of a dump file set on separate disks so that they will be written and read in parallel.

• For export operations, use the %U variable in the DUMPFILE parameter so multiple dump files can be automatically generated.

Example:

> expdp username/password DIRECTORY=dpump_dir1 JOB_NAME=hr

DUMPFILE=par_exp%u.dmp PARALLEL=4

REMAP

• REMAP_TABLESPACE – This allows you to easily import a table into a different

tablespace from which it was originally exported. The databases have to be 10.1 or later.

Example:

> impdp username/password REMAP_TABLESPACE=tbs_1:tbs_6

DIRECTORY=dpumpdir1 DUMPFILE=employees.dmp

• REMAP_DATAFILES – This is a very useful feature when you move databases between platforms that have different file naming conventions. This parameter changes the source datafile name to the target datafile name in all SQL statements where the source

datafile is referenced. Because the REMAP_DATAFILE value uses quotation marks, it’s best to specify the parameter within a parameter file.

Example:

The parameter file, payroll.par, has the following content:

DIRECTORY=dpump_dir1

FULL=Y

DUMPFILE=db_full.dmp

REMAP_DATAFILE=”’C:\DB1\HRDATA\PAYROLL\tbs6.dbf’:’/db1/hrdata/payroll/tbs6.dbf

You can then issue the following command:

> impdp username/password PARFILE=payroll.par

Even More Advanced Features of Oracle Data Pump

Beyond the command-line and performance features of Oracle Data Pump are new capabilities that DBAs will find invaluable. A couple of prominent features are described here.Interactive Command-Line Mode

You have much more control in monitoring and controlling Data Pump jobs with interactive command-line mode. Because Data Pump jobs run entirely on the server, you can start an export or import job, detach from it, and later reconnect to the job to monitor its progress. Here are some of the things you can do while in this mode:

See the status of the job. All of the information needed to monitor the job’s execution is available.

• Add more dump files if there is insufficient disk space for an export file.
• Change the default size of the dump files.
• Stop the job (perhaps it is consuming too many resources) and later restart it (when more resources become available).
• Restart the job. If a job was stopped for any reason (system failure, power outage), you can attach to the job and then restart it.
• Increase or decrease the number of active worker processes for the job. (Enterprise Edition only.)
• Attach to a job from a remote site (such as from home) to monitor status.

Network Mode

Data Pump gives you the ability to pass data between two databases over a network (via a database link), without creating a dump file on disk. This is very useful if you’re moving data between databases, like data marts to data warehouses, and disk space is not readily available. Note that if you are moving large volumes of data, Network mode is probably going to be slower than file mode. Network export creates the dump file set on the instance where the Data Pump job is running and extracts the metadata and data from the remote instance. Network export gives you the ability to export read-only databases. (Data Pump Export cannot run locally on a read-only instance because the job requires write operations on the instance.) This is useful when there is a need to export data from a standby database.

Generating SQLFILES

In original Import, the INDEXFILE parameter generated a text file which contained the SQL commands necessary to recreate tables and indexes that you could then edit to get a workable DDL script. With Data Pump, it’s a lot easier to get a workable DDL script. When you run Data Pump Import and specify the SQLFILE parameter, a text file is generated that has the necessary DDL (Data Definition Language) in it to recreate all object types, not just tables and indexes. Although this output file is ready for execution, the DDL statements are not actually executed, so the target system will not be changed.

SQLFILEs can be particularly useful when pre-creating tables and objects in a new database. Note that the INCLUDE and EXCLUDE parameters can be used for tailoring sqlfile output. For example, if you want to create a database that contains all the tables and indexes of the source database, but that does not include the same constraints, grants,and other metadata, you would issue a command as follows:

>impdp username/password DIRECTORY=dpumpdir1 DUMPFILE=expfull.dmp

SQLFILE=dpump_dir2:expfull.sql INCLUDE=TABLE,INDEX

The SQL file named expfull.sql is written to dpump_dir2 and would include SQL DDL that could be executed in another database to create the tables and indexes as desired.

Every Oracle database has a control file. A control file contains entries that specify the physical structure of the database. For example, it contains the following information:

- Database name
- Names and locations of datafiles and redo log files
- Time stamp of database creation

 Oracle can multiplex the control file, that is, simultaneously maintain a number of identical control file copies, to protect against a failure involving the control file. 

Every time an instance of an Oracle database is started, its control file identifies the database and redolog files that must be opened for database operation to proceed.

If the physical makeup of the database is altered (for example, if a new datafile or redo log file is created), then the control file is automatically modified by Oracle to reflect the change. A control file is also used in database recovery.

There are several methods to find control files:

1. ON  LINUX

a. Using Sql: Query v$parameter view to fetch control files location. The “value” column will return a list of comma-separated locations of control files.

sql> select value from v$parameter where name=’control_files’ ;

/test_multiplex/control01.ctl, /oracle_multiplex2/control02.ctl, /oracle_multiplex3/control03.ctl
b. Using Sqlplus:

SQL> show parameter control_files ;

NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_files                        string      /test_multiplex/control01.ctl,
                                                                    /oracle_multiplex2/control02.ctl,
                                                                   /oracle_multiplex3/control03.ctl

c. Using Operating System

If the database was setup according to Oracle Flexible Architecture ( For more information on OFA on Linux click here) control files will be in control<counter>.ctl format where <counter> shows the order of control files. So performing a search at operating system level will give you the list of control files. Also those files are supposed to be owned by “oracle” operating system user and belong to “oinstall” operating system group.

The command below will start searching from root location (/) and will look for any file, which starts with control and has an .ctl extension.

[root@myserver ~]# find / -name control*.ctl -type f

/test_multiplex/control01.ctl
/oracle_multiplex2/control02.ctl
/oracle_multiplex3/control03.ctl

The files found are “probably” the control files for the database but it is also possible that they are not associated with a database. They might me obsolete. Because of that it is more reliable to locate control files via sql interface than operating system interface.

2. ON WINDOWS

a. Using Sql: Query v$parameter view to fetch control files location. The “value” column will return a list of comma-separated locations of control files.

sql> select value from v$parameter where name=’control_files’ ;

E:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL01.CTL, E:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL02.CTL,
E:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL03.CTL

b. Using Sqlplus:

SQL> show parameter control_files ;

NAME                                 TYPE        VALUE
———————————— ———– ——————————
control_files                        string      E:\ORACLE\PRODUCT\10.2.0\ORADA TA\MYDB\CONTROL01.CTL,
                                                                    E:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL02.CTL,
                                                                   E:\ORACLE\PRODUCT\10.2.0\ORADATA\MYDB\CONTROL03.CTL

c. Using Operating System

If the database was setup according to Oracle Flexible Architecture ( For more information on OFA on Windows click here) control files will be in control<counter>.ctl format where <counter> shows the order of control files. So performing a search at operating system level will give you the list of control files.

The command below will  start searching from root location of drive E and will look for any file which starts with control and has an .ctl extension.

E:\>dir /s control*.ctl

 E sürücüsü birimi: Data

 E:\oracle\product\10.2.0\oradata\mydb dizini

08.12.2009  09:26         7.061.504 CONTROL01.CTL
08.12.2009  09:26         7.061.504 CONTROL02.CTL
08.12.2009  09:26         7.061.504 CONTROL03.CTL

               3 Dosya       21.184.512 bayt

     Listelenen Toplam Dosya:
               3 Dosya       21.184.512 bayt
               0 Dizin   158.115.127.296 bayt boş

The files found are “probably” the control files for the database but they might not be associated with a database. They might me obsolete. Because of that it is more reliable to locate control files via sql interface than operating system interface.

        You can configure your instance by setting parameters. You can see the parameters that your instance can process by querying v$parameter dynamic performance view.

sql> desc v$parameter ;

Name                                                               Null?    Type
 —————————————– ——– ————-
 NUM                                                                            NUMBER
 NAME                                                                         VARCHAR2(80)
 TYPE                                                                           NUMBER
 VALUE                                                                       VARCHAR2(512)
 DISPLAY_VALUE                                                 VARCHAR2(512)
 ISDEFAULT                                                              VARCHAR2(9)
 ISSES_MODIFIABLE                                             VARCHAR2(5)
 ISSYS_MODIFIABLE                                            VARCHAR2(9)
 ISINSTANCE_MODIFIABLE                              VARCHAR2(5)
 ISMODIFIED                                                             VARCHAR2(10)
 ISADJUSTED                                                            VARCHAR2(5)
 ISDEPRECATED                                                       VARCHAR2(5)
 DESCRIPTION                                                          VARCHAR2(255)
 UPDATE_COMMENT                                             VARCHAR2(255)
 HASH                                                                            NUMBER

             You don’t have to set parameters manually everytime you start your instance, you can keep the values in a file called “parameter file” and your instance reads the parameters stored in that file. If the parameter file is text-based it is called “parameter file” (pfile) , if it is binary it is called “server parameter file” (spfile).

On Linux:

As a rule spfile resides under $ORACLE_HOME/dbs/ directory.

When you start an instance Oracle will try to locate spfile in following order:

1) $ORACLE_HOME/dbs/spfile<SID>.ora => This file should be binary. SID is $ORACLE_SID environment value. If Oracle does not find the file then it looks for it in second location.

2) $ORACLE_HOME/dbs/spfile.ora => This file should be binary. SID is $ORACLE_SID environment value. If Oracle does not find the file then it looks for it in third location.

3) $ORACLE_HOME/dbs/init<SID>.ora => SID is $ORACLE_SID environment value. This file should be text based and it is not a server parameter file indeed. This file is read-only. Instance can not modify this, however it may read values in the file and start instance based on them. You may  modify this file using a text editor like vi and set values manually. It is not recommended to use init<SID>.ora files.

On Windows:

As a rule spfile resides under ORACLE_HOME\database\ directory.

When you start an instance Oracle will try to locate spfile in following order:

1) ORACLE_HOME\database\spfile<SID>.ora => This file should be binary. SID is your ORACLE_SID. If Oracle does not find the file then it looks for it in second location.

2) ORACLE_HOME\database\spfile.ora => This file should be binary. SID is your ORACLE_SID. If Oracle does not find the file then it looks for it in third location.

3) ORACLE_HOME\database\init<SID>.ora => SID is your ORACLE_SID. This file should be text based and it is not a server parameter file indeed. This file is read-only. Instance can not modify this, however it may read values in the file and start instance based on them. You may  modify this file using a text editor like vi and set values manually. It is not recommended to use init<SID>.ora files.

I honestly had to pick up my jaw off the floor when I heard that the DoJ cleared Oracle’s acquisition of Sun earlier this year.  By all of the literature supported by the DoJ’s official policy book, The Horizontal Merger Guidelines, it seemed like Oracle and Sun becoming one great Valley monolith was the worst thing that could happen. Monopolistic control of the resource market for a product? Check. Price setting powers by significantly reducing competition in a major revenue center? Check. I could go on, but you get the idea: this was exactly the type of thing the DoJ and the Sherman Antitrust Act was supposed to stop.

Of course, that’s not what happened. The DoJ and the FTC greenlighted the acquisition based off of the idea that Oracle’s purchase would not constitute a monopoly in its products’ markets. They recognized Sun as a manufacturer of servers and Oracle as an enterprise software company. Now this isn’t all lies and deceit. Sun continues to derives a ton of revenue (if not most of its revenue) from its production and maintenance of its line of SPARC-based Solaris servers. This has largely been the same since the late 80’s. But, like a lot of other people, I was concerned about the effect of Oracle owning a fairly recent acquisition that Sun had made the year before.

In February of 2008, Sun purchased the rights to an open-source database server known as MySQL. MySQL is the preeminent open-source database server. Everyone that isn’t on IBM, Oracle, or Microsoft SQL uses it: Google, Facebook, Twitter…etc.  MySQL may not be as immediately scalable as its polished enterprise database server competitors. But it’s free, and the community has done a great job to work on making sure it runs well in distributed environments. MySQL was the poster child for innovative reform in the database sector. Its presence has changed the game considerably. It’s a damning threat to enterprise offerings by all of the older players just like Linux threatens proprietary Unix servers, Solaris, and Windows solutions in the server OS market with good technology at the low-low price of free. It’s forced everyone to really up their game in terms of cranking out great products in order to compete.

Once again, wohoo free market.

Oracle’s purchase of Sun does give it the rights to nifty cool things like the ZFS file system, Java (which they use with 10G to create a very cool app server/db server solution), and Solaris. But it also gets the rights to MySQL. With most of Oracle’s business done in the database sector, this whole maneuver could  be an expensive way of eliminating the competition from MySQL to push the market back towards the 90’s-era database oligopoly. That’s dangerously anti-competitive behvior there, buddy. In fact, that’s textbook anti-competitive behavior.

But maybe the Department of Justice is right. Maybe this isn’t about Oracle sweeping away the competition like ants. I mean, it’s not like Oracle CEO Larry Ellison has a reputation or anything.

And again, this stuff isn’t all new. I wrote a lot about this whole affair before when word broke that Oracle and Sun started doing the M&A dance earlier this year. What is new is what the EU recently said in their review of the issue: “no.”  The EU rejected Oracle’s acquisition based on this very issue. They felt that if Oracle acquired Sun, Oracle would wind up with monopolistic control of the database market. Who called it.

With the EU’s formal objection of Oracle and Sun getting married all hell has broken lose. Sun has announced some horrifying layoffs. Oracle has petitioned congressman and ambassadors to reach out and shake the EU’s commission into OK’ing the deal (one has some very scary The Godfather imagery from this), and in general the sky is falling. Oracle and Sun were already in maneuvers to start consolidating their businesses, so this revelation is as crushing as it is sudden for them.

But the lack of concern by both Oracle and Sun about whether or not they’d run into antitrust problems is what really disturbs me. With MySQL and 10g falling under the same command, did you really think this wasn’t going to be an issue? Maybe the DoJ and the FTC would not do their homework about Sun’s intellectual properties, but someone had to realize at some point that you’d walk away with a radically-powerful control over the database market.

Don’t get me wrong: layoffs are horrible, terrible things. And despite the seemingly popular sentiment that Sun’s execs are asleep at the wheel and that working at Oracle is about as non-political as being a member of Congress, both of these companies really are filled with smart and capable people on both an individual contributor level and at a strategic level. This is why I’m really unsettled. Why did nobody think that the acquisition might not run into trouble? Include something in your proposal about how Sun would divest MySQL during its dissolution into Oracle.  Talk about how Oracle would immediately sell MySQL to someone else. Do something to address this glaring and radical increase in market power that Oracle would get by acquiring one of its major competitors.

At best, not addressing MySQL seems like a glaring mistake. At worst it seems like pure hubris – like Oracle smugly and casually disregarded the possibility of being hit with antitrust concerns for being able to take out one of its major competitors in an already small market through acquisition.

WIDTH_BUCKET function is used to assign bucket value for a list of values based on maximum and minimum number. This is one of the new analytic function introduced in Oracle 10g. Consider the following table.

StudentId
Mark


1
56


2
43


3
76


4
89


5
90


6
91


7
49


8
63


9
83


10
74

If you want to assign buckets based on the mark they got, the SQL to that would be

SQL> select StudentId
2       , Mark
3       , wIDTH_BUCKET(Mark, 50, 100, 5) as Grade#
4    from hr.Students
5  /

STUDENTI MARK   GRADE#
-------- ------ ------
1        56     1
2        43     0
3        76     3
4        89     4
5        90     5
6        91     5
7        49     0
8        63     2
9        83     4
10       74     3

If you want to assign grade 1 for 90-99, then change the WIDTH_BUCKET (MARK, 100, 50, 5).

Referrence

Oracle documentation for WIDTH_FUNCTION.

The Optimal Flexible Architecture (OFA) standard is a set of file naming and configuration guidelines created to ensure reliable Oracle installations that require little maintenance.

You can think of Optimal Flexible Architecture as a set of good habits to adopt when organizing Oracle directories and files on your computer. All Oracle components on the installation media are Optimal Flexible Architecture-compliant; that is, Oracle Universal Installer places Oracle components in directory locations that follow Optimal Flexible Architecture guidelines. Although using Optimal Flexible Architecture is not a requirement, Oracle recommends that you use it.

Here are the steps to accomplish OFA before an Oracle installation on a Windows environment:

Step 1: Create ORACLE_BASE Directory

ORACLE_BASE is the root of the OFA compliant Oracle directory tree. It is a base for all oracle installations.  It should be in format <DRIVE_LETTER>:\oracle\product\<version>. For example:  D:\oracle\product\10.2.0\ is a good choice for an Oracle 10.2.0.1 database server installation.

Step 2: Create ORACLE_HOME Directory

ORACLE_HOME directory is the directory of the current Oracle installation and contains subdirectories for Oracle software executables and network files. Every ORACLE_HOME directory is also associated with a ORACLE_HOME name which you specify during Oracle Software installation.

ORACLE_HOME directory should be in format <ORACLE_BASE>\<type>_<counter> where type is the purpose of installation (db, app, client etc.) and counter is an identifier which shows the order of installations. For example:  <ORACLE_BASE>\db_1\ => D:\oracle\product\10.2.0\ db_1\  is a good choice for an Oracle Database installation for the first time.

Step 3: Create Admin Directory

Create an admin directory to store administration files.  It should be in format <ORACLE_BASE>\admin\<DB_NAME>\ .

For ex: <ORACLE_BASE>\admin\my_db\ => D:\oracle\product\10.2.0\ admin\my_db\

Some of the directories that the admin directory should contain are shown below:

\bdump –background process trace files
\cdump –core dump files
\create –database creation files
\exp –database export files
\pfile –initialization parameter files
\udump –user SQL trace files
\arch — archived redolog files

Step 4: Create Oradata Directory

Oracle data related files (data files, online redolog files and control files) should be kept in an directory called “ORADATA”. The oradata directory should be in format <ORACLE_BASE>\oradata\<DB_NAME> . For example:  D:\oracle\product\10.2.0\ oradata\my_db\

Step 5: Naming Files In Oradata Directory

Datafiles should be in format <tablespace_name><counter>.dbf . For example:  mytablespace01.dbf .

Online redolog files should be in format redolog<counter>.log . For example: redolog01.log, redolog02.log, redolog03.log .

Control files should be in format control<counter>.ctl . For example: control01.ctl, control02.ctl, control03.ctl .

Step 6:  Spreading Files

It is quite common to have data on multiple physical disks to spread I/O workload and thereby provide better performance and reliability. In such a situation create the same directory structure on all drives and spread the files in relevant directories.  For example the log files can be shared among the drives like:

 C:\oracle\product\10.2.0\oradata\my_db\redolog01.log
 D:\oracle\product\10.2.0\oradata\my_db\redolog02.log
 E:\oracle\product\10.2.0\oradata\my_db\redolog03.log

            It is a very common scenario where some users were created in your database at a past time, the software that owns those users became obsolete but as a dba you are unaware of that because nobody has informed you. Or you may have inherited a database in your new job, which you had no control before. In such a situation the first thing you have to do is to detect users who no longer needs to stay in database and delete their accounts or at least lock them.

Here are the steps to accomplish this:

Step 1: Capture Logon-Logoff Events

* Auditing should be enabled and audit trails must be configured to be kept in database.

sql> alter system set audit_trail = db scope=spfile;
System altered.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup;
ORACLE instance started.
Database mounted.
Database opened.

* We have enabled auditing and our audit records will be kept in database. Now lets enable session auditing and capture logon-logoff events.

SQL> audit session ;

* That’s all. From now on whenever a user logs in an audit record will be created. Now you have to wait to let active users login. One month is a reasonable duration.

Step 2: Detect Database Users Who Has Never Logged In

* Audit trails are kept in DBA_AUDIT_TRAIL dictionary view. Lets query the view to detect who has logged in since we enabled auditing.

sql> select distinct username from dba_audit_trail where action_name in (‘LOGOFF’,'LOGON’)

* The information of all database users can be seen in DBA_USERS dictionary view. Now simply extract the active users from all users list.

sql> select username from dba_users where account_status=’OPEN’ and username not in

(
select username from dba_audit_trail where action_name in (‘LOGOFF’,'LOGON’) and username is not null
)

** Now you have got a list of users who have never logged in to database since you enabled auditing.

Step 3: Take Action

* Feel free to lock all users that are inactive.

sql> alter user <inactive_user> account lock;

* Those inactive users never needed to login but they could have login privileges. We unlocked their account. Now they can’t login even if they have login privileges. Our database became more secure.

Step 4: Evaluating Users and Deleting Unnecessary Schemas

* Is it enough lock accounts only or should we also delete users and their corresponding schema objects. Well, it depends. If user does not own any object do not hesitate to delete the user.

sql> drop user <inactive_user> ;

*  But if they own objects, active users may be using those inactive users’ objects like reading from their table, executing their procedures etc. It is better to keep the inactive users with objects at first. Try to find the owner of those users within your organization. If you can’t find anyone who owns them, those schemas are good candidates for removing. User’s creation time may also give you an idea.

sql> select created from dba_users where username=’INACTIVE_USER’

* If you are skeptical you can check one more thing before dropping users. First find objects belonging to an inactive user.

sql> select owner,object_name,object_type from dba_objects where owner=’<inactive_user>’ and status=’VALID’

* Audit every activity on that objects

sql> audit all on <inactive_user>.<object_name> ;

* Give time to your users. Again one month is a reasonable duration. After that, query audit records. If you detect any activity on those objects, it means that although schema owner never logs on to database, his objects are still used by other active users. Do not ever drop such schemas.

* And finally if no activity is detected on objects drop those schemas.

sql> drop user <schema_name> cascade ;

* The command above will drop user and its objects including those which depend on them.

* It is a good idea to take a dump of your schema before dropping it. Keep your dump files in a safe place. If one day the owner of those users come and ask for their data back you can restore them.

$ exp system/<my_system_user_password>@<my_db_net_service_name> file=<export_file_location> log=<location_of_log_gile>  owner=<inactive_user>

* The command above will backup your schema and store it under <export_file_location>.

** Finally the work is completed. Now you have a cleaner database where there is no obsolete users and data. This means your database is more secure and you have more control over it.

Delivering Oracle 10g R2 Administration Workshop II we had a closer look at the new recommended backup strategy for Oracle.

With Oracle 10g R2 we can recover datafile copies like we recover the real datafiles.
This gives us the oportunity to recover the entire database without having to restore it from backup first.
Which of course saves very valuable time in case of a disaster.

Here is how you could do it:

- use a “flash recovery area” to store everything needed for recovering, such as:
- an image copy of the entire database
- one incremental backup of the database
- the archived redo logs which have been created since the last incremental backup

The flash recovery area is a location on disk which you specify by the parameter db_recovery_file_dest. It can be changed dynamically without having to restart.
With the also dynamically changeable parameter db_recovery_file_dest_size you can limit the amount of disk space you want to use for this area.

Once you use it rman will create backupserts and image copies of datafiles there by default.

- create an image copy of the entire database:

RMAN > BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY DATABASE;

This will first search for a parent image copy to recover. If there is none yet, it will create one.
If there is an image copy of the database already, it will create an incremental level 1 backup.

- after you have create the first incremental backup for your image copy you can update these image copies of the datafiles by applying the incremental backup to them.

RMAN > RECOVER COPY OF DATABASE;

This is what you do every night.
Then you will have a copy of the database which is always
at least at the level of last night.

In case of a disaster you can now tell rman to just change the locations of the datafiles in the controlfile to the image copies by issuing the following:

RMAN > SWITCH DATABASE TO COPY;
You can only do this in MOUNT.
- Now you are already where you were last night and you only have to recover what has changed since last incremental update without having to restore the database at first.

This is a very handy way to perform recovery.
We were able to switch datafiles to copies before 10g already, but could not incrementally update them.

connect lutz hartmann as sysdba



Creating ASM on windows .

step 1: create a windows based service for asm.
c:\oradim -new -asmsid +asm -startmode manual

step 2: create init+asm.ora file in your oracle_home/database directory
with just this lines–

instance_name=’+asm’
instance_type=’asm’
asm_diskstring=’\\.\*:’
#asm_diskgroups=dg1

step 3 : set oracle env for ASM

c:\set oracle_sid=+asm

step 4: connect asm instance with sqlplus as sysdba and start the instance.
C:> sqlplus / as sysdba

SQL> STARTUP
ORA-29701: unable to connect to Cluster Manager
–if u see the error that means your CM is not started so follow this step
C:\>CD F:\oracle\product\10.2.0\db_1\BIN
C:\>localconfig delete
Step 1: stopping local CSS stack
Step 2: deleting OCR repository
failed to open the OCR subkey, err(1060)
failed to cleanup local OCR repository
successfully deleted local CSS setup

C:\>localconfig add
Step 1: creating new OCR repository
Successfully accumulated necessary OCR keys.
Creating OCR keys for user ‘robin’, privgrp ”
Operation successful.
Step 2: creating new CSS service
successfully created local CSS service
successfully added CSS to home

step 5: now try again.

SQL> STARTUP
ASM instance started

Total System Global Area 79691776 bytes
Fixed Size 1247396 bytes
Variable Size 53278556 bytes
ASM Cache 25165824 bytes
ORA-15110: no diskgroups mounted
SQL> select path from v$asm_disk ;

no rows selected

a–so you have no asm disk group,for disk group first you need to create asm disk first.
b–go to disk management
c–select unallocated space
d–right click unallocated space and luance a new partition wizard..click next
e–choose extended partition not a primary. click next
f–choose the meximum size click finish.
g–right click the free space in the new partition. select logical drive,click next
h–when prompted for a partition size ,enter your desire size from maximum size.
i–select the redo button to assign a drive letter.and acceep what ever later is suggested.
j–select the redo button Do not format the partition.click next.
k–click finish ,the logical drive ,with no file system.
l–repert step “G” to create additional unformatted drive.

Step 6: go to sqlplus
Sql> select path,total_mb from v$asm_disk;

Path total_mb
——— —————–
\\.\k: 2000
\\.\l: 2000

Step 7 :
Create a disk group ,nominating the two raw volumes.
Sql>create diskgroup dg1 disk ‘\\.\k:’,'\\.\l:’

Step 8 :
Shutdown asm instance
Remove # from asm_diskgroups=dg1 parameter in asm+init.ora file.
Startup
–u see your database is mount , actually asm mount the disk group not controlfile , because asm hasn’t any controlfile.

Step 9: go to RDBMS instance. Run the following command.

Sql> create tablespace new_tabs datafile ‘+dg1’ size 10m;

Sql> select name from v$datafile;

Sql>alter database add logfile group 4 ‘+dg_log1’,’+dg_log2’ size 10m;

Sql> select group#,member from v$logfile.

Note : ASM instance should start first before any rdbms instance start.

Creating ASM on windows .

step 1: create a windows based service for asm.
c:\oradim -new -asmsid +asm -startmode manual

step 2: create init+asm.ora file in your oracle_home/database directory
with just this lines–

instance_name=’+asm’
instance_type=’asm’
asm_diskstring=’\\.\*:’
#asm_diskgroups=dg1

step 3 : set oracle env for ASM

c:\set oracle_sid=+asm

step 4: connect asm instance with sqlplus as sysdba and start the instance.
C:> sqlplus / as sysdba

SQL> STARTUP
ORA-29701: unable to connect to Cluster Manager
–if u see the error that means your CM is not started so follow this step
C:\>CD F:\oracle\product\10.2.0\db_1\BIN
C:\>localconfig delete
Step 1: stopping local CSS stack
Step 2: deleting OCR repository
failed to open the OCR subkey, err(1060)
failed to cleanup local OCR repository
successfully deleted local CSS setup

C:\>localconfig add
Step 1: creating new OCR repository
Successfully accumulated necessary OCR keys.
Creating OCR keys for user ‘robin’, privgrp ”
Operation successful.
Step 2: creating new CSS service
successfully created local CSS service
successfully added CSS to home

step 5: now try again.

SQL> STARTUP
ASM instance started

Total System Global Area 79691776 bytes
Fixed Size 1247396 bytes
Variable Size 53278556 bytes
ASM Cache 25165824 bytes
ORA-15110: no diskgroups mounted
SQL> select path from v$asm_disk ;

no rows selected

a–so you have no asm disk group,for disk group first you need to create asm disk first.
b–go to disk management
c–select unallocated space
d–right click unallocated space and luance a new partition wizard..click next
e–choose extended partition not a primary. click next
f–choose the meximum size click finish.
g–right click the free space in the new partition. select logical drive,click next
h–when prompted for a partition size ,enter your desire size from maximum size.
i–select the redo button to assign a drive letter.and acceep what ever later is suggested.
j–select the redo button Do not format the partition.click next.
k–click finish ,the logical drive ,with no file system.
l–repert step “G” to create additional unformatted drive.

Step 6: go to sqlplus
Sql> select path,total_mb from v$asm_disk;

Path total_mb
——— —————–
\\.\k: 2000
\\.\l: 2000

Step 7 :
Create a disk group ,nominating the two raw volumes.
Sql>create diskgroup dg1 disk ‘\\.\k:’,'\\.\l:’

Step 8 :
Shutdown asm instance
Remove # from asm_diskgroups=dg1 parameter in asm+init.ora file.
Startup
–u see your database is mount , actually asm mount the disk group not controlfile , because asm hasn’t any controlfile.

Step 9: go to RDBMS instance. Run the following command.

Sql> create tablespace new_tabs datafile ‘+dg1’ size 10m;

Sql> select name from v$datafile;

Sql>alter database add logfile group 4 ‘+dg_log1’,’+dg_log2’ size 10m;

Sql> select group#,member from v$logfile.

Note : ASM instance should start first before any rdbms instance start.

Error occurs during export dumpfile:-

ORA-01555: snapshot too old: rollback segment number 11 with name “_SYSSMU11$” too small

How to solve:

- increase undo_retention to 36 hours

SQL> ALTER SYSTEM SET UNDO_RETENTION = 129600;

  
         In Oracle, listeners run on port 1521 as a default. As everyone knows this standard port, an attack to your database will be performed on that port by a hacker. Changing this default port will make your database more secure. Yes, a hacker still may find your database port by scanning all ports respectively but this action (port scanning) will be detected by your IDS (intrusion-detection system) or IPS (intrusion prevention system) and you will be able to take required actions.

Here are the steps to change your default oracle listener port:

Step 1: Create A Listener On A New Port

* Find your listener.ora file which resides under $ORACLE_HOME/network/admin/ .This file is responsible for holding definitions of your listeners.
Locate your current listener definition and change the port. For example I choose port 1645 for my database:

my_listener  =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = <my_host>)(PORT = 1645))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
    )
  )

* Now add a tnsnames entry to your tnsnames.ora file, which resides in the same directory as listener.ora file. This file is responsible for holding net service names and is used for resolving tns names.

listening_endpoint_1645 = (ADDRESS = (PROTOCOL = TCP)(HOST = <my_host>)(PORT = 1645))

* Restart Your Listener With New Port:

$ lsnrctl stop  my_listener
$ lsnrctl start  my_listener

Step 2: Present Your New Listener To Your Instance

* Listeners have to be aware of services and instances running on that host so that they can forward client connection requests to relevant instances. For that reason, instances locate the listeners on that host and give them the information they need every 60 seconds. PMON (process monitor) process is responsible for carrying this information that instances supply to listeners. This is called dynamic service registration. 

But how will the instance know where the listener is located?  You have to tell instance where listener is located manually by setting the LOCAL_LISTENER parameter.

$ sqlplus / as sysdba
sql> alter system set LOCAL_LISTENER = ‘ listening_endpoint_1645′ scope=both;

* Now your instance is aware of location of the listener that is running. But it may take up to 60 seconds for PMON process to carry instance information to the listener. If you want this to happen immediately you can manually trigger service registration.

$ sqlplus / as sysdba
sql> alter system register ;

** Now your instance has registered with the listener. You can verify it by running the command below:

$ lsnrctl status my_listener

LSNRCTL for Linux: Version 10.2.0.4.0 – Production on 09-NOV-2009 11:55:21

Copyright (c) 1991, 2007, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<my_host>)(PORT=1645)))
STATUS of the LISTENER
————————
Alias                        my_listener
Version                   TNSLSNR for Linux: Version 10.2.0.4.0 – Production
Start Date                09-NOV-2009 11:52:55
Uptime                     0 days 0 hr. 2 min. 25 sec
Trace Level             off
Security                  ON: Local OS Authentication
SNMP                     OFF
Listener Parameter File   /opt/oracle/app/oracle/product/10.2.0/db/network/admin/listener.ora
Listener Log File             /opt/oracle/app/oracle/product/10.2.0/db/network/log/my_listener.log
Listening Endpoints Summary…
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<my_host>)(PORT=1645)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary…
Service “katalogDBXDB” has 1 instance(s).
  Instance “katalogDB”, status READY, has 1 handler(s) for this service…
Service “my_service” has 1 instance(s).
  Instance “katalogDB”, status READY, has 1 handler(s) for this service…

The command completed successfully

* As you see, your listener knows which services and instances are available.

Step 3: Route All Your Clients To Your New Address

* Now your database is listening on port 1645 instead of 1521. All your clients have to adapt to new settings by changing their connection strings. They have to explicitly set the port to 1645. As a DBA it is your responsibility to coordinate the changes on clients.

         
             A patchset update (PSU) is a collection of both security and non-security patches. They are published quarterly. There will be totally 4 psu published in a year. It is recommended by Oracle to install PSU’s when they are announced.  Here are the steps to upgrade to oracle patchset update 2 .

Step 1: Downloading PSU

* Login to your Metalink account => Patches & Updates => Advanced Search
* On Advanced Search Page click the flashlight icon near “Select a Product or Product Family” and a new popup page will appear.
* On the popup page choose “Database & Tools” from Search Dropdown and click Go.
* Results will be displayed in a table. Choose “Oracle Database Family”
* Now we are back at the Advanced Search Page. Select the release of your database. It should be “Oracle “.
* On the Classification dropdown list choose “Recommended” and click Go.
* You must see a couple of results. We are looking for the PSU for database with a description Oracle Database Family: Patch DATABASE PSU .
(INCLUDES CPU)

- As you may have noticed Critical Patch Updates (CPU) are now included in PSU’s. Oracle recommends to install only PSU’s. No need to install CPU’s separately.
- Every PSU has a version. The PSU released by October-2009 is version 2. The next PSU’s version will be 3. When you apply the PSU to your database, the fifth number of your database’s version will show the PSU version. For ex: if your database is 10.2.0.4, after applying pathset update, your db version will be CALLED 10.2.0.4.2 . Yes your database will only be CALLED 10.2.0.4.2. You may think of it as a virtual version. When you query v$version you will still see the old version without a fifth number.

Step 2: Upgrade Your Opatch To Latest Version

- PSU’s can not be applied with the standard version of opatch. You need to upgrade your opatch version to latest release. For ex: for database 10.2.0.4 you must have at least opatch 10.2.0.4.7 . For your database release, refer to README file of your PSU.

- If you already have an up-to-date version of Opatch you may skip this step and jump to step 3.

* Login to Metalink => Patches & Updates => Simple Search
* In the textbox near “Patch Number/Name” write 6880880, choose your platform and click Go.
* From the table choose the appropriate version of Opatch depending on your database version. For ex: If your database version is 10.2.0.4 choose Opatch version 10.2.
* Click on the floppy disk icon to download the setup file.
* Copy the zip file to $ORACLE_HOME.

$ cp <zipped_file> $ORACLE_HOME

* Simply unzip the zip file under $ORACLE_HOME

$ unzip <zipped_file>

* Now your Opatch is upgraded. To verify it, enter command below.

$ ./OPatch/opatch version

Invoking OPatch 10.2.0.4.8

OPatch Version: 10.2.0.4.8

OPatch succeeded.

Step 3: Installing PSU

* Backup your $ORACLE_HOME folder before you start installing PSU.

* Change the current user to Oracle software owner. This is usually “oracle”.

$ su – oracle

* Verify that oracle user has access to make, ar, ld and nm commands.

$ which make
$ which ar
$ which ld
$ which nm

* verify that oracle user has access to opatch command.

$ which opatch

* If oracle user can’t reach opatch command, add path of opatch command to $PATH enviroment variable. Opatch command can be found under $ORACLE_HOME/OPatch/

$ export PATH=$PATH:$ORACLE_HOME/OPatch

* Unzip zipfile and enter to directory of patch

$ unzip <zipped_file>
$ cd <unzipped_folder>

* Apply the patch

$ opatch apply

* If Opatch detects a conflicting bug and errors out, create a service request to Oracle Support. They will supply you a

merged patch which won’t conflict with your system.

* Now change user to root. Set $ORACLE_HOME environment variable and execute the psu_root.sh command.

$ su – root
$ export ORACLE_HOME=<your_oracle_home>
$ sh psu_root.sh

* Patching binary files is completed. Now we have to load some sql scripts to our database and execute them.

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus /nolog

SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT

* The sql script above will leave log files under “$ORACLE_HOME/cfgtoollogs/catbundle/” having a format like

catbundle_PSU__APPLY_.log
catbundle_PSU__GENERATE_.log

You can examine the relevant log files for errors.

* In this step we will recompile all views in database. If you have done this process before you can skip this step.

$ cd $ORACLE_HOME/cpu/view_recompile
$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @recompile_precheck_jan2008cpu.sql
SQL> QUIT

$ cd $ORACLE_HOME/cpu/view_recompile
$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> SHUTDOWN IMMEDIATE
SQL> STARTUP UPGRADE
SQL> @view_recompile_jan2008cpu.sql
SQL> SHUTDOWN;
SQL> STARTUP;
SQL> QUIT

* Commands above will create a log file in current directory named “vcomp__.log”

* As a final step execute statements below.

$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> @utlrp.sql

* Now patching is done. I hope you don’t encounter any problem during these steps.