.ora-code.com

Links
• Home
• Oracle DBA Forum
Frequent Oracle Errors
•TNS:could not resolve the connect identifier specified
•Backtrace message unwound by exceptions
•invalid identifier
•PL/SQL compilation error
•internal error
•missing expression
•table or view does not exist
•end-of-file on communication channel
•TNS:listener unknown in connect descriptor
•insufficient privileges
•PL/SQL: numeric or value error string
•TNS:protocol adapter error
•ORACLE not available
•target host or object does not exist
•invalid number
•unable to allocate string bytes of shared memory
•resource busy and acquire with NOWAIT specified
•error occurred at recursive SQL level string
•ORACLE initialization or shutdown in progress
•archiver error. Connect internal only, until freed
•snapshot too old
•unable to extend temp segment by string in tablespace
•Credential retrieval failed
•missing or invalid option
•invalid username/password; logon denied
•unable to create INITIAL extent for segment
•out of process memory when trying to allocate string bytes
•shared memory realm does not exist
•cannot insert NULL
•TNS:unable to connect to destination
•remote database not found'>ora-02019
•exception encountered: core dump
•inconsistent datatypes
•no data found
•TNS:operation timed out
•PL/SQL: could not find program
•existing state of packages has been discarded
•maximum number of processes exceeded
•error signaled in parallel query server
•ORACLE instance terminated. Disconnection forced
•TNS:packet writer failure
•see ORA-12699
•missing right parenthesis
•name is already used by an existing object
•cannot identify/lock data file
•invalid file operation
•quoted string not properly terminated
v$backup_corruption - FRACTURED vs. LOGICAL & Solutions

v$backup_corruption - FRACTURED vs. LOGICAL & Solutions

2005-08-10       - By Marquez, Chris
Reply:     1     2     3  


What is the meanings for "FRACTURED" & "LOGICAL" values in the CORRUPTION_TYPE
column of the v$backup_corruption view.

We are seeing these results when run this select.

select distinct a.FILE_ID, a.TABLESPACE_NAME, a.FILE_NAME, b.CORRUPTION_TYPE, b
.BLOCK#
from dba_data_files a, v$backup_corruption b
where a.FILE_ID = b.FILE#
order by a.FILE_ID, a.TABLESPACE_NAME, a.FILE_NAME, b.CORRUPTION_TYPE, b.BLOCK#
/
  FILE_ID TABLESPACE_NAME                FILE_NAME                            
   CORRUPTION_TYPE                 BLOCK#
-- ---- -- -- ---- ---- ---- ---- ---- -- -- ---- ---- ---- ---- ---- ---- ----
--- -- ---- ---- ---- ---- ---- -- ---- --
        4 USERS                          /o05/oradata/orcl/users01.dbf        
FRACTURED                        16138
        4 USERS                          /o05/oradata/orcl/users01.dbf        
FRACTURED                        16141
...
        6 E_INDX                   /o04/oradata/orcl/e_indx_06.dbf LOGICAL    
                    193043
        6 E_INDX                   /o04/oradata/orcl/e_indx_06.dbf LOGICAL    
                    193555
...


At one time we did have real RMAN and alert.log block errors when backing up
USERS tablespace.
Today I backed up this datafile using RMAN without error.
We have never used traditional OS HOT backup (mode) methods to backup our
database.

Our db_block_* parameters;
SQL> show parameter db_block_
NAME                                 TYPE            VALUE
-- ---- ---- ---- ---- ---- ---- --- -- ---- ---- -- -- ---- ---- ---- ---- ---
----
db_block_checking                    boolean         FALSE
db_block_checksum                    boolean         TRUE


How could "DBMS_REPAIR" and/or "DBVERIFY" be used to validate and fix any
corruption we might have.
Again, at this time do not have and have never been aware of alert.log errors
related to block corruption.
Also this database has be restored to other servers using RMAN without
indication of block corruption.


And again, what is the meaning, implications, checks, and solutions for;
"FRACTURED" & "LOGICAL" values?

Chris Marquez
Oracle DBA

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7232.39">
<TITLE>v$backup_corruption - FRACTURED vs. LOGICAL &amp; Solutions</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=2>What is the meanings for &quot;FRACTURED&quot; &amp; &quot
;LOGICAL&quot; values in the CORRUPTION_TYPE column of the v$backup_corruption
view.<BR>
<BR>
We are seeing these results when run this select.<BR>
<BR>
select distinct a.FILE_ID, a.TABLESPACE_NAME, a.FILE_NAME, b.CORRUPTION_TYPE, b
.BLOCK#<BR>
from dba_data_files a, v$backup_corruption b<BR>
where a.FILE_ID = b.FILE#<BR>
order by a.FILE_ID, a.TABLESPACE_NAME, a.FILE_NAME, b.CORRUPTION_TYPE, b.BLOCK#
<BR>
/<BR>
&nbsp;&nbsp; FILE_ID TABLESPACE_NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FILE_NAME&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; CORRUPTION_TYPE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BLOCK#<BR>
-- ---- -- -- ---- ---- ---- ---- ---- -- -- ---- ---- ---- ---- ---- ---- ----
--- -- ---- ---- ---- ---- ---- -- ---- --<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4 USERS&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /o05/oradata/orcl/users01.dbf
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FRACTURED&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16138<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4 USERS&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; /o05/oradata/orcl/users01.dbf
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FRACTURED&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 16141<BR>
...<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6 E_INDX&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; /o04/oradata/orcl/e_indx_06.dbf LOGICAL&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 193043<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6 E_INDX&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp; /o04/oradata/orcl/e_indx_06.dbf LOGICAL&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 193555<BR>
...<BR>
<BR>
<BR>
At one time we did have real RMAN and alert.log block errors when backing up
USERS tablespace.<BR>
Today I backed up this datafile using RMAN without error.<BR>
We have never used traditional OS HOT backup (mode) methods to backup our
database.<BR>
<BR>
Our db_block_* parameters;<BR>
SQL&gt; show parameter db_block_<BR>
NAME&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TYPE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VALUE<BR>
-- ---- ---- ---- ---- ---- ---- --- -- ---- ---- -- -- ---- ---- ---- ---- ---
----<BR>
db_block_checking&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; boolean&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FALSE<BR>
db_block_checksum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; boolean&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TRUE<BR>
<BR>
<BR>
How could &quot;DBMS_REPAIR&quot; and/or &quot;DBVERIFY&quot; be used to
validate and fix any corruption we might have.<BR>
Again, at this time do not have and have never been aware of alert.log errors
related to block corruption.<BR>
Also this database has be restored to other servers using RMAN without
indication of block corruption.<BR>
<BR>
<BR>
And again, what is the meaning, implications, checks, and solutions for; &quot
;FRACTURED&quot; &amp; &quot;LOGICAL&quot; values?<BR>
<BR>
Chris Marquez<BR>
Oracle DBA</FONT>
</P>

</BODY>
</HTML>