DBVerify is an inbuilt Oracle utility that performs an integrity check on your database to verify its physical data structure. It can work for offline as well as online Oracle databases and also on your backup files. It proves handy when you need to check for corruption problems and ensure that your backup databases (or data files) are consistent. Although, it performs faster checks, this tool can be only used for cache-managed blocks (data blocks). It cannot verify control files or redo logs.
There are two ways of performing a DBVerify check. You can use DBVerify to check disk blocks of a single data file or you can verify a database segment. In the first case, the tool runs on the specified disk blocks of a single data file and carries out page checks. If you are using an Automatic Storage Management (ASM) file, you should provide a USERID for allowing DBVerify to connect to the Oracle instance.
The following statement will tell you on how to invoke DBVerify from your operating system command line:
'$ dbv file=data01.dbf logfile=verify.log blocksize=8192 feedback=100'
Here, 'data01.dbf' is the data file and its corresponding tablespace has a block size of 8192 bytes.
The feedback parameter is used to put a period on the screen after checking every 100 blocks.
After completion of the process, you will see the following output in your log file:
DBVERIFY – Verification starting : FILE = data01.dbf
DBVERIFY – Verification complete
Total Pages Examined : 640
Total Pages Processed (Data) : 631
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing (Index): 0
Total Pages Marked Corrupt : 0
In this output, the 'Total Pages Failing' denote the number of data or index blocks that were verified and failed the tool checking routine. The 'Total Pages Marked Corrupt' indicate the number of blocks having a bad cache header. If only a small portion of the data file needs to be verified, you need to provide the starting and ending block while running the tool.
In case the 'DBVerify' fails to repair database corruption, you should take help of competent Oracle database recovery tool. These utilities safely recover and restore all your lost or damaged objects, including tables, views, procedures, triggers, functions, package, package body, etc. They provide you with a self-explanatory, easy-to-use interface that makes the recovery process more simple and facile.
There are two ways of performing a DBVerify check. You can use DBVerify to check disk blocks of a single data file or you can verify a database segment. In the first case, the tool runs on the specified disk blocks of a single data file and carries out page checks. If you are using an Automatic Storage Management (ASM) file, you should provide a USERID for allowing DBVerify to connect to the Oracle instance.
The following statement will tell you on how to invoke DBVerify from your operating system command line:
'$ dbv file=data01.dbf logfile=verify.log blocksize=8192 feedback=100'
Here, 'data01.dbf' is the data file and its corresponding tablespace has a block size of 8192 bytes.
The feedback parameter is used to put a period on the screen after checking every 100 blocks.
After completion of the process, you will see the following output in your log file:
DBVERIFY – Verification starting : FILE = data01.dbf
DBVERIFY – Verification complete
Total Pages Examined : 640
Total Pages Processed (Data) : 631
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing (Index): 0
Total Pages Marked Corrupt : 0
In this output, the 'Total Pages Failing' denote the number of data or index blocks that were verified and failed the tool checking routine. The 'Total Pages Marked Corrupt' indicate the number of blocks having a bad cache header. If only a small portion of the data file needs to be verified, you need to provide the starting and ending block while running the tool.
In case the 'DBVerify' fails to repair database corruption, you should take help of competent Oracle database recovery tool. These utilities safely recover and restore all your lost or damaged objects, including tables, views, procedures, triggers, functions, package, package body, etc. They provide you with a self-explanatory, easy-to-use interface that makes the recovery process more simple and facile.
No comments:
Post a Comment