Re: Corruption with active duplication
Date: Fri, 9 Nov 2018 17:56:45 +1100
Message-Id: <1363D274-0ED8-4B0D-87E7-3B1412241183_at_gmail.com>
If you look at the message it’s all on block 1!! So something odd is happening at the auxiliary end. Is the file system mounted correctly?
You can run dbv or Rman validate against just a single block rather than the entire 2tb.
Cheers,
Leng
> On 9 Nov 2018, at 3:09 pm, Stefan Knecht <knecht.stefan_at_gmail.com> wrote:
>
> Since you know which files it is, you can just run a backup validate datafile # instead of the entire database.
>
>> On Fri, Nov 9, 2018 at 10:10 AM Mladen Gogala <gogala.mladen_at_gmail.com> wrote:
>> No, unfortunately, the database is active. The dbverify isn't very good on active data files.
>>
>> Regards
>>
>>> On 11/8/18 10:03 PM, Ruel, Chris wrote:
>>> Try running a dbverify command on the corrupt datafile?
>>>
>>>
>>>
>>> _____________________________________________________________________
>>>
>>> Chris Ruel * Distributed Database Services * Lincoln Financial Group
>>>
>>> cruel_at_lfg.com * Desk:317.759.2172 * Cell 317.523.8482
>>>
>>>
>>>
>>> From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
>>> Sent: Thursday, November 08, 2018 9:17 PM
>>> To: oracle-l <oracle-l_at_freelists.org>
>>> Subject: Corruption with active duplication
>>>
>>>
>>>
>>> ***This email is from an external source. Only open links and attachments from a Trusted Sender.***
>>>
>>> Hi!
>>>
>>> I am doing an active duplication of one test database to another one, for another group of developers. Here is what I am getting:
>>>
>>> consistency value in tail: 0x00000001
>>> check value in block header: 0xb601
>>> computed block checksum: 0x0
>>> Reading datafile '/U02/oradata/test2a/data21.dbf' for corruption at rdba: 0x11000001 (file 68, block 1)
>>> Reread (file 68, block 1) found same corrupt data (no logical check)
>>> Hex dump of (file 69, block 1) in trace file /app01/oracle/diag/rdbms/test2a/test2/trace/test2_ora_25016.trc
>>> Corrupt block relative dba: 0x11400001 (file 69, block 1)
>>>
>>> It probably means that the source database is corrupt, yet there is nothing in the alert log. I will do backup validate logical, but this will take some time, since it's a database over 2TB. Does anyone have any idea how to establish whether the source DB is corrupt faster than using backup validate?
>>>
>>> --
>>> Mladen Gogala
>>> Database Consultant
>>> Tel: (347) 321-1217
>>> Notice of Confidentiality: **This E-mail and any of its attachments may contain
>>> Lincoln National Corporation proprietary information, which is privileged, confidential,
>>> or subject to copyright belonging to the Lincoln National Corporation family of
>>> companies. This E-mail is intended solely for the use of the individual or entity to
>>> which it is addressed. If you are not the intended recipient of this E-mail, you are
>>> hereby notified that any dissemination, distribution, copying, or action taken in
>>> relation to the contents of and attachments to this E-mail is strictly prohibited
>>> and may be unlawful. If you have received this E-mail in error, please notify the
>>> sender immediately and permanently delete the original and any copy of this E-mail
>>> and any printout. Thank You.**
>>>
>> -- >> Mladen Gogala >> Database Consultant >> Tel: (347) 321-1217 > > > -- > // > zztat - The Next-Gen Oracle Performance Monitoring and Reaction Framework! > Visit us at zztat.net | _at_zztat_oracle | fb.me/zztat | zztat.net/blog/
-- http://www.freelists.org/webpage/oracle-lReceived on Fri Nov 09 2018 - 07:56:45 CET