Failure when initializing OCR

28 11 2008

Kemarin ada problem pas coba instal Oracle Database di tempat client, OS yang dipake adalah Windows Server 2003, Oracle Database yang diinstal adalah Oracle Database versi 10.1.0.2 Saat proses instalasi berlangsung keluar pesan error :

Failure when initializing OCR..

Kemudian, error kedua yang muncul :

install program cannot initialize service
OracleCSService..

Solusi buat ngatasi hal ini pertama kita harus pastikan saat kita melakukan instalasi kita menggunakan user administrator (Local Admin), atau jadikan user kita jadi member dari group Administrators dan ORA_DBA. Kalau untuk solusi cepat untuk menghindari problem ini kita bisa langsung lakukan instalasi gunakan Oracle Database versi 10.1.0.3 atau langsung ke 10.2.0.1 yaitu versi diatas 10.1.0.2

Oracle CS Service biasanya digunakan apabila kita menggunakan RAC atau ASM. Jika kita hanya menggunakan komputer standalone dan tidak mengunakan ASM, kita bisa seting manual service ini. Apabila kita tetap mau melakukan instalasi dengan menggunakan Oracle Database versi 10.1.0.2 maka kita harus melakukan patching saat proses instalasi berlangsung. Kalau dari Oracle metalink kita bisa search patch ini dengan code 3555863 file ini berisi orahasgen10.dll dan orahasgen10.sym

Jadi saat proses instalasi berlangsung, saat keluar pops up OCR error kita perlu untuk copy file orahasgen10.dll dari patch 3555863 yang kita download ke direktori %ORACLE_HOME%\bin. Buat backup copy file orahasgen10.dll yang lama.
Setelah ini jangan langsung continue pada error tadi. Buka command prompt dan jalankan :

“clscfg -local -o %ORACLE_HOME% -l NA”

Kemudian masih di command prompt jalankan :

“net start oraclecsservice”

Kemudian klik untuk continue pada dialog error untuk melanjutkan proses instalasi .

Hope it can help.





Oracle 11g [ Virtual Column ]

19 11 2008

Semisal sebuah tabel SALES dengan struktur sebagai berikut

SALES_ID NUMBER
CUST_ID NUMBER
SALES_AMT NUMBER

User akan menambah kolom SALE_CATEGORY, yang akan mengidentifikasi tipe penjualan : LOW, MEDIUM, HIGH dan ULTRA tergantung jumlah penjualan
kolom ini akan membantu mengidentifikasi record untuk analisa. Berikut logika untuk nilai kolomnya

If sale_amt is more than: And sale_amt is less than or equal to: Then sale_category is:

Apabila kita tidak akan merubah code dengan menambah kolom sale_category di tabel, dan membuat triger untuk membuat logika yang kita perlukan,
Di Oracle 11g kita tidak perlu membuat sebuah triger. Yang kita perlukan adalah menambah sebuah virtual column. Virtual Column menawarkan
fleksibilitas untuk menambah kolom yang memenuhi permintaan bisnis tanpa menambah kompleksitas atau mempengaruhi performance
Berikut Querynya

SQL> create table sales
2 (
3 sales_id number,
4 cust_id number,
5 sales_amt number,
6 sale_category varchar2(6)
7 generated always as
8 (
9 case
10 when sales_amt <= 10000 then ‘LOW’
11 when sales_amt > 10000 and sales_amt <= 100000 then ‘MEDIUM’
12 when sales_amt > 100000 and sales_amt <= 1000000 then ‘HIGH’
13 else ‘ULTRA’
14 end
15 ) virtual
16 );

Kita perhatikan pada baris 6-7 , kolom dispesifikasikan sebagai “generated always as”, berarti nilai kolom digenerate dalam runtime(saat diakses), tidak
sebagai bagian dari table. Klausa tsb diikuti bagaimana nilai akan dihitung dengan memakai pernyataan CASE. Dan baris 15 berarti menunjukkan bahwa
itu adalah sebuah kolom virtual. Sekarang jika kita insert sebuah data.

SQL> insert into sales (sales_id, cust_id, sales_amt) values (1,1,100);

1 row created.

SQL> insert into sales (sales_id, cust_id, sales_amt) values (2,102,1500);

1 row created.

SQL>insert into sales (sales_id, cust_id, sales_amt) values (3,102,100000);

1 row created.

SQL> commit;

Commit complete.

SQL> select * from sales;

SALES_ID CUST_ID SALES_AMT SALE_C
———- ———- ———- ——
1 1 100 LOW
2 102 1500 LOW
3 102 100000 MEDIUM

3 rows selected.

Nilai dalam virtual column di perlakukan seperti biasa.Meskipun kolom ini tidak disimpan, kita bisa mengakses kolom ini seperti kolom lain ditabel
Kita jg dapat membuat index didalamnya

SQL> create index in_sales_cat on sales (sale_category);

Index created.

Hasilnya adalah berupa function-based index

SQL> select index_type
2 from user_indexes
3 where index_name = ‘IN_SALES_CAT’;

INDEX_TYPE
—————————
FUNCTION-BASED NORMAL

SQL> select column_expression
2 from user_ind_expressions
3 where index_name = ‘IN_SALES_CAT’;

COLUMN_EXPRESSION
——————————————————————————–
CASE WHEN “SALES_AMT”<=10000 THEN ‘LOW’ WHEN (“SALES_AMT”>10000 AND “SALES_AMT”
<=100000) THEN CASE WHEN “CUST_ID”<101 THEN ‘LOW’ WHEN (“CUST_ID”>=101 AND “CUS
T_ID”<=200) THEN ‘MEDIUM’ ELSE ‘MEDIUM’ END WHEN (“SALES_AMT”>100000 AND “SALES
_AMT”<=1000000) THEN CASE WHEN “CUST_ID”<101 THEN ‘MEDIUM’ WHEN (“CUST_ID”>=101
AND “CUST_ID”<=200) THEN ‘HIGH’ ELSE ‘ULTRA’ END ELSE ‘ULTRA’ END

Kita juga dapat melakukan partisi pada kolom ini, yang tidak dapat kita lakukan adalah memasukkan nilai ke kolom ini, semisal

insert into sales values (5,100,300,’HIGH’,'XX’)
*
ERROR at line 1:
ORA-54013: INSERT operation disallowed on virtual columns





Oracle 11g [ DDL Wait Option ]

17 11 2008

Contoh kasus, semisal tabel SALES akan ditambah kolom, TAX_CODE, dengan menggunakan pernyataan SQL sebagai berikut

SQL> alter table sales add (tax_code varchar2(10));

tapi ternyata tidak berhasil membuat table altered, keluar output sbg berikut

alter table sales add (tax_code varchar2(10))
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

Pesan kesalahan tsb menjelaskan bahwa tabel sedang digunakan sekarang, kemungkinan sedang terjadi transaksi, jadi tabel dikunci secara exclusive
Tentu saja row tidak akan di lock selamanya, saat sesi menjalankan commit, maka lock dirow tsb akan dilepas. Tapi sebelum periode unlock tsb terlalu lama
sesi lain mungkin update row lain dalam tabel tsb sehingga sedikit waktu untuk mendapat exclusive lock akan hilang. Dikebanyakan lingkungan bisnis,
waktu untuk lock tabel secara exclusive tidak terbuka secara periodic, dan DBA tidak bisa menjalankan perintah alter tepat diwaktu tsb.
Tentu saja dengan keadaan seperti itu , kita hanya bisa mengetik perintah yang sama berulang-ulang sampai mendapat exclusive lock.
Dalam Oracle 11g, Kita punya pilihan lebih baik, DDL Wait Option

SQL> alter session set ddl_lock_timeout = 10;

Session altered.

Sekarang saat pernyataan DDL dalam sebuah sesi tidak mendapat lock exclusive, ini tidak akan keluar error. Ini akan menunggu selama 10 detik.
Dalam waktu tsb , ini akan berulang-ulang menjalankan operasi DDL sampai sukses atau waktu habis. Saat kita jalankan perintah

SQL> alter table sales add (tax_code varchar2(10));

Pernyataan tersebut hang dan tidak keluar error sama sekali. Tapi pernyataan tsb tetap berjalan seperti sebuah program telepon yang mencoba
terus retry kenomer yang sibuk yang akan dihubungi. Fitur ini sangat membantu , kita jg bisa menjadikan ini sebagai default sehinggan kita tidak perlu
menjalankan ALTER SESSION tiap kali, jika kita menjalankan ALTER SYSTEM SET DDL_LOCK_TIMEOUT = 10 maka secara automatis sesi akan menunggu
selama periode yang kita tentukan selama proses DDL.





Oracle Basic [ Table Compression ]

17 11 2008

Oracle Basic [ Table Compression ]

Sistem yang kita develop sekarang hampir kebanyakan membutuhkan jumlah data yang sangat banyak dan pasti memerlukan beberapa tabel yang sangat besar. Ini tentu saja akan membutuhkan banyak space di disk kita. Untuk memanage kapasitas disk fitur tabel compression yang ada sejak Oracle 9i release 2 dapat menekan jumlah pemakaian disk space oleh tabel2 didatabase secara signifikan dan meningkatkan performance query di beberapa kasus.

Mekanisme kerja fitur ini adalah dengan mengeliminasi value untuk data yang terduplikasi yang ditemukan di tabel. Kompresi data bekerja di level database block. Saat tabel didefinisikan sebagai “compressed”, maka database akan memesan space dalam tiap database block untuk menyimpan single copy dari tiap data yang juga muncul di beberapa tempat selain block tersebut. Reserved space ini disebut dengan symbol table. Data yang di beri label untuk kompresi disimpan hanya di symbol table dan bukan di row databasenya sendiri. Bila data yang diberi label untuk kompresi muncul dirow database, maka row akan menyimpan sebuah pointer yang menuju ke data yang relevan di symbol table. Dan space yang akan dihemat datang dari proses eliminasi data yang sama yang ada ditabel. Efek dari kompresi tabel transparan kepada user atau developer aplikasi karena developer dapat mengakses tabel dengan cara yang sama terhadap tabel yang kita kompresi maupun tidak kita kompress. Jadi query SQL tidak perlu dirubah setelah kita putuskan untuk melakukan kompresi tabel. Kompresi tabel ini biasanya dimanage oleh DBA, dengan sedikit keterlibatan developer atau user.

Untuk membuat tabel kompresi, gunakan keyword COMPRESS di statement CREATE TABLE. berikut contohnya :

CREATE TABLE EMP (
ID NUMBER NOT NULL,
NAME VARCHAR2(50) NOT NULL,
SAL NUMBER NOT NULL,
JOIN_DATE DATE NOT NULL,
ADDRESS VARCHAR2(100)
) COMPRESS;

Sebagai alternatif kita bisa gunakan ALTER TABLE untuk merubah atribut kompresi dari tabel yang sudah ada.

ALTER TABLE EMP COMPRESS;

Untuk menentukan apakah sebuah tabel telah dibuat menggunakan COMPRESS, kita lihat diview data dictionary

USER_TABLES dan lihat dikolom COMPRESSION.

SELECT TABLE_NAME, COMPRESSION FROM USER_TABLES WHERE TABLE_NAME=’EMP’;

TABLE_NAME COMPRESSION
—————— ———–
EMP ENABLED

Atribut COMPRESS juga dapat kita definisikan pada level TABLESPACE, bisa saat kita CREATE TABLESPACE atau ALTER TABLESPACE bila kita lakukan pada tablespace yang sudah ada. Untuk menentukan apakah sebuah tablespace didefinisikan dengan COMPRESS, cek pada DBA_TABLESPACES pada kolom DEF_TAB_COMPRESSION.

SELECT TABLESPACE_NAME,DEF_TAB_COMPRESSION FROM DBA_TABLESPACES;

TABLESPACE_NAME DEF_TAB_COMPRESSION
————— ——————-
DATA_TS_01 DISABLED
INDEX_TS_01 DISABLED

Sebagai catatan bahwa saat kita menggunakan COMPRESS seperti diatas, kita tidak sebenarnya melakukan kompress data. Command diatas hanya memodifikasi seting dari data dictionary. Data tidak sebenarnya dikompres sampai kita load atau insert data ke dalam tabel. Selanjutnya untuk memastikan bahwa data sebenarnya telah dikompres, kita perlu menggunakan metode yang tepat untuk melakukan load atau insert kedalam tabel. Kompresi data hanya berperan selama proses load atau insert dengan menggunakan salah satu dari metode berikut :

1. SQL*Loader scr direct
2. INSERT dengan APPEND
3. Paralel INSERT
4. CREATE TABLE … AS SELECT

Dan jika kita tidak menggunakan metode load data atau INSERT yang tepat, maka data dalam tabel akan tetap tidak dikompres, meskipun tabel telah didefiniskan dengan atribut COMPRESS. Sebagai contoh jika kita menggunakan perintah INSERT biasa maka data tidak akan dikompress.

Pertanyaannya adalah, kapan kita gunakan Table Compression?
Seperti disebutkan diatas, data didalam tabel didefinisikan menggunakan COMPRESS hanya akan dikompres hanya jika data kita load menggunakan mode direct atau INSERT menggunakan append atau paralel mode. Data kita insert menggunakan pernyataan insert biasa akan tetap tidak dikompres. Dalam Online Transaction Processing (OLTP), data biasanya diinsert dengan insert biasa. Hasilnya, tabel ini tidak akan mendapat banyak keuntungan dengan menggunakan kompresi tabel. Table compression dapat bekerja maksimal dalam read-only table yang diload sekali tapi dibaca berkali-kali. Selain itu, update data dalam tabel yang terkompresi akan membutuhkan beberapa baris data untuk di uncompress terlebih dulu, yang mana akan menghilangkan tujuan dari kompresi.Sehingga tabel yang membutuhkan operasi update dengan frekuensi tinggi tidak cocok untuk dilakukan table compression.

Dan selanjutnya adalah mempertimbangkan efek dari delete pada baris data dalam penggunaan kompresi tabel. Saat kita melakukan delete sebuah data dalam suatu tabel yang dikompresi, database akan melepaskan space yang ditempati oleh baris data tsb diblok database. free space ini dapat digunakan kembali oleh operasi insert yang akan dilakukan kemudian.

Melakukan kompresi pada tabel yang sudah ada dan belum dikompres sebelumnya kita gunakan command berikut

ALTER TABLE EMP MOVE COMPRESS;

Kita bisa menggunakan pernyataan ALTER TABLE … MOVE untuk melakukan uncompress tabel.

ALTER TABLE EMP MOVE NOCOMPRESS;

Perhatikan bahwa operasi ALTER TABLE … MOVE mendapat lock EXCLUSIVE didalam tabel, yang mana akan mencegah semua operasi DML terhadap tabel tsb saat pernyataan dieksekusi.

Melakukan Kompresi pada tabel yang dipartisi

ALTER TABLE EMP MOVE PARTITION EMP3_03 COMPRESS;

Alasan sesungguhnya untuk menggunakan kompresi tabel adalah untuk menghemat space pada storage kita. Sebuah tabel dalam mode kompresi akan memakan lebih sedikit ruang di storage kita saat dibandingkan dengan tabel yang tidak terkompresi. Query terhadap tabel yang dikompres akan membutuhkan waktu yang lebih cepat, karena akan lebih sedikit membaca database block dalam prosesnya.





ORA-01562 dan ORA-01650

11 11 2008

Selagi kita jalanin update data yang lumayan gede error ini keluar, kebetulan kita jalanin update sekitar 8jt an data yang dipisah jadi beberapa query update, jadi tiap query paling ga jalanin update sekitar 2jt data.. berikut pesan errornya..

ORA-01562: failed to extend rollback segment
ORA-01650: unable to extend rollback segment RBS5 by 64 in tablespace RBS

ORA-01562: failed to extend rollback segment
hal ini berarti kita kehabisan space ditablespace yang berisi rollback segment. Dan ini berarti, kita mungkin mempunyai transaksi yang sangat besar yang menghabiskan semua space ditablespace. Yang bisa kita lakukan dalam kasus ini adalah cut down the size dari transaksi (dengan melakukan commit lebih banyak secara teratur) atau dengan solusi dibawah ini :

Solusi 1 :

Untuk menentukan nama dari roolback segment kita gunakan query berikut.

SELECT SEGMENT_NAME FROM DBA_ROLLBACK_SEGS WHERE SEGMENT_ID=<string> (string adalah nomor segment yang keluar di pesan error)

Kemudian gunakan command berikut untuk membuat rollback segment menjadi offline.

ALTER ROLLBACK SEGMENT <nama> OFFLINE;

Solusi 2 :

Naikkan nilai MAXEXTENTS di rollback segment dengan command berikut.

ALTER ROLLBACK SEGMENT <nama segment> STORAGE (MAXEXTENTS n);

dimana n adalah nilai integer yang buat menentukan seberapa besar kita mau menambah nilai maxextents. Kita juga bisa menggunakan MAXEXTENTS UNLIMITED disini.

Solusi 3 :

Atau jika kita mau menggunakan big rollback segment dan kita membuatnya dengan nilai yang tinggi buat INITIAL dan NEXT, dan mempunyai MAXEXTENTS yang tinggi juga kemudian menempatkannya ke dalam transaksi akan menyebabkan data rollback yang amat besar.

kita login sebagai SYS kemudian create big rollback segment terlebih dahulu

CREATE ROLLBACK SEGMENT <nama segment>
TABLESPACE <nama tablespace>
STORAGE (
INITIAL 512K
NEXT 512K
MAXEXTENTS UNLIMITED
);

Semisal rollback segment kita kita beri nama RBSBIG, sebelum kita lakukan update statement kita jalankan command

berikut ini:

SET TRANSACTION USE ROLLBACK SEGMENT RBSBIG;





ORA-01536 : space quota exceeded for tablespace

10 11 2008

Error ini terjadi saat kita melakukan insert ke dalam sebuah table dan gagal sehingga keluar pesan error sebagai berikut ORA-01536 : space quota exceeded for tablespace “<name>” tapi sebenarnya tablespace masih mempunyai space yang cukup. Kita jalankan ” grant unlimited tablespace to <username>” tapi masih keluar error yang sama.
Penyebabnya ternyata adalah karena terdapat dependency object ditabel tersebut. Melakukan Insert ditabel ini memerlukan update ke object lain yang terhubung ke table tsb, yang mana memerlukan quota yang tidak dapat dipenuhi oleh tablespace.

Solusi :

1. Cari object yang terhubung ke table tersebut.

select NAME,TYPE from dba_dependencies where REFERENCED_NAME=’table name’;

2. Apabila ketemu, kita cari owner dari object tersebut.

select OWNER,OBJECT_NAME from dba_objects where OBJECT_NAME=’dependant object name’;

3. Grant unlimited tablespace kepada user tersebut.

grant unlimited tablespace to <dependant object owner name>;

4. Sekarang kita bisa melakukan insert ke table tersebut.

That’s all..





ORA-01658: unable to create INITIAL extent for segment in tablespace

6 11 2008

Hari ini saya hadapin oracle error saat jalanin import dump file ke oracle 9i database. Errornya adalah “ORA-01658: unable to create INITIAL extent for segment in tablespace”. I investigated the problem and find a solution…

Salah satu tablespace di create dengan command seperti ini :

“CREATE TABLESPACE DATA BLOCKSIZE 8192

DATAFILE ‘/data07/oradata/pd02/data01.dbf’ SIZE 10000M

AUTOEXTEND ON NEXT 25000M MAXSIZE 32767M

EXTENT MANAGEMENT LOCAL AUTOALLOCATE

ONLINE PERMANENT NOLOGGING SEGMENT

SPACE MANAGEMENT AUTO;”

Jadi, saat tablespace butuh ruang penyimpanan, maka akan dialokasikan sebesar 25000M. Saat database tidak bisa memenuhi ( tidak ada ruang kosong di disk ) maka akan terjadi error seperti diatas.

Salah satu solusinya adalah kita create lagi secara manual sebuah datafile dengan ukuran yang lebih kecil seperti berikut :

“ALTER TABLESPACE DATA

ADD DATAFILE ‘/data07/oradata/pd02/data02.dbf’

SIZE 3000M AUTOEXTEND ON;”

Atau bisa juga dengan menambah space ke datafile yang ada dengan command berikut :

“ALTER DATABASE DATAFILE ‘/data07/oradata/pd02/data01.dbf’ RESIZE 15000M;”





Parallel Backup of the Same Datafile

4 11 2008

Di Oracle kita bisa melakukan backup secara paralel dengan mendeklarasikan lebih dari satu chanel sehingga tiap chanel menjadi sesi-sesi RMAN
Tapi bagaimanapun jg tiap channel dapat melakukan backup hanya 1 data file tiap kali. Jadi meskipun ada beberapa channel , tiap datafile hanya
dapat diproses oleh satu channel
Di RMAN Oracle 11g , dapat memilah datafile ke dalam bagian2 yang disebut “SECTIONS”. Kita dapat menentukan ukuran dari tiap SECTIONS
Seperti contoh berikut :

RMAN> run {
2> allocate channel c1 type disk format ‘/backup1/%U’;
3> allocate channel c2 type disk format ‘/backup2/%U’;
4> backup
5> section size 500m
6> datafile 6;
7> }

RMAN mengalokasikan 2 channel dan melakukan backup users tablespace secara paralel di 2 channel. Tiap channel mengambil 500MB sections
dari datafile dan membackup nya secara paralel.Ini menjadikan backup file berukuran besar menjadi lebih cepat.

RMAN> list backup of datafile 6;

<snipped>

List of Backup Pieces for backup set 901 Copy #1
BP Key Pc# Status Piece Name
——- — ———– ———-
2007 1 AVAILABLE /backup1/9dhk7os1_1_1
2008 2 AVAILABLE /backup2/9dhk7os1_1_1
2009 3 AVAILABLE /backup1/9dhk7os1_1_3
2009 3 AVAILABLE /backup2/9dhk7os1_1_4

Sebagai catatan bahwa potongan tiap backup kita lihat sebagai sections dari file. Tiap sections berada di channel yang berbeda,
Kita bisa mendefinisikan mereka sebagai mount point yang berbeda ( seperti /backup1 atau /backup2 ) Kita bisa mengembalikannya ke Tape secara paralel
Tapi jika file besar #6 ditempatkan hanya di satu DISK, maka tidak ada keuntungannya menggunakan paralel backup.





Proactive Health Checks

4 11 2008

Bagaimana kita tahu tidak ada bad blocks dalam database kita, karena bad blocks dapat ketahuan saat kita mengaksesnya.
dan bagaimana kita dapat mengidentifikasinya sebelum itu terjadi, dan memperbaikinya sblm error dialami oleh user.
Dalam Oracle 11g, dengan perintah baru dalam RMAN yaitu VALIDATE DATABASE.dapat melakukan operasi untuk melakukan cek
terhadap database blocks dari physical corruption.

RMAN> validate database;

Starting validate at 09-SEP-07
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=110 device type=DISK
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00002 name=/home/oracle/oradata/ODEL11/sysaux01.dbf
input datafile file number=00001 name=/home/oracle/oradata/ODEL11/system01.dbf
input datafile file number=00003 name=/home/oracle/oradata/ODEL11/undotbs01.dbf
input datafile file number=00004 name=/home/oracle/oradata/ODEL11/users01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:02:18
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
1 OK 0 12852 94720 5420717
File Name: /home/oracle/oradata/ODEL11/system01.dbf
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 0 65435
Index 0 11898
Other 0 4535

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
2 OK 0 30753 115848 5420730
File Name: /home/oracle/oradata/ODEL11/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 0 28042
Index 0 26924
Other 0 30129

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
3 OK 0 5368 25600 5420730
File Name: /home/oracle/oradata/ODEL11/undotbs01.dbf
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 0 0
Index 0 0
Other 0 20232

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
4 OK 0 2569 12256 4910970

… <<dipotong..>> …
Sebaliknya misalnya terdapat error maka output dari oracle adalah seperti dibawah

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
7 FAILED 0 0 128 5556154
File Name: /home/oracle/oradata/ODEL11/test01.dbf
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 0 108
Index 0 0
Other 10 20

Kita juga dapat melakukan validasi terhadap tablespace yang spesifik

RMAN> validate tablespace dataku;

Starting validate at 02-JUL-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=00006 name=C:\APP\ADMINISTRATOR\ORADATA\ORCL\DATAKU

channel ORA_DISK_1: validation complete, elapsed time: 00:00:03
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
6 OK 0 12766 12800 1433028
File Name: C:\APP\ADMINISTRATOR\ORADATA\ORCL\DATAKU
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 0 10
Index 0 1
Other 0 23

Finished validate at 02-JUL-08

Atau kita lakukan validasi terhadap datafile

RMAN> validate datafile 1;

Ataupun block dalam sebuah datafile;

RMAN> validate datafile 4 block 56;

Selain datafile kita juga bisa melakukan validasi terhadap spfile, controlfilecopy, recovery file, Flash Recovery Area





5 ways to detect invisible users on Yahoo Messenger

3 11 2008

Apakah kamu mencari jalan tercepat buat mencari tahu salah satu account Yahoo Messenger di list kamu bener2 offlline atau hanya Invisible? dan ternyata banyak juga orang yang penasaran mau tahu gimana caranya mendeteksi seseorang apakah Invisible atau tidak.. Ya buat iseng2 ajalah , mungkin ini salah 5 caranya..

  1. Invisible Scanner – Ya seperti namanya , buat nyari account yang invisible..

    yahoo invisible scanner

  2. Invisible.ir – Yang lainnya adalah juga bisa dicoba. Kita juga bisa melakukan hal lain seperti mendeteksi lebih dari satu user secara bersamaan user2 Yahoo ID.


  3. Buddy Spy – Dua services diatas adalah web service, Tapi Buddy Spy adalah program kecil yang bisa kamu download dan install dikomputer kamu. Saya sarankan pake ini buat mendeteksi Invisible IM “simply the best in invisible detection”!


  4. Xeeber.com - Service yang lain buat deteksi invisible user, Tapi terakhir aku coba udah tidak bisa, kemungkinan situsnya sudah down..


  5. BuddyCheck – Program lainnya yang bisa kamu download dan kamu install, yang mana akan memperlihatkan user yang Online dan siapa yang Offline. Dan ini satu2nya yang butuh biaya alias bayar.. sekitar $20.. yah klo emang lu bener2 frustasi pengen tahu orang lain yang invisible atau ga.. ini aplikasi yang pantas buat lu..

    buddy check

Yah mungkin ada yang tau metode lain buat deteksi invisible user di Yahoo Messenger bisa di share.. Dan hal ini tentu saja ga bisa 100% digunakan .. paling ga bisa di coba2 buat isenglah .. Enjoy !








Follow

Get every new post delivered to your Inbox.