Re: rman fail on backup control file
Date: Tue, 21 Aug 2018 07:54:25 -0700
Message-ID: <CAKsxbLoaUo_O0bWzJnYMZFfLV_WJN6gVuquz4gxrjn1pLsMBHg_at_mail.gmail.com>
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: ===========================================================RMAN-00558: error encountered while parsing input commands RMAN-01009: syntax error: found "parameter": expecting one of: "all, archivelog,
auxiliary, auxname, backup, channel, controlfile, datafile, device, default, ex
clude, encryption, maxsetsize, retention, snapshot" RMAN-01007: at line 1 column 6 file: standard input
On Tue, Aug 21, 2018 at 3:59 AM LK <lkaing_at_gmail.com> wrote:
> Hi Jeff,
>
> From the debug we can see the failure is here:
>
> DBGRPC: krmxrpc: xc=15378960 kpurpc2 rc=19624 db=target
> proc=DBMS_BACKUP_RESTORE.BACKUPPIECECREATE
> DBGMISC: ENTERED krmzejob [10:13:23.281]
> DBGMISC: Input Args(failed=1),(errnum=-19624) [10:13:23.359] (krmzejob)
>
> It's trying to create the backuppiece and can't do so.
>
> So I suspect that you have permission issues with the backup location.
>
> eg.
>
> How to Configure RMAN to Write to Shared Drives on Windows NT/2000/2003
> (Doc ID 145843.1)
>
> You said that the rest of the backup works, except for the autobackup.
>
> So please show me the result of the following:
>
> RMAN> show all;
> RMAN> backup datafile 1;
>
> SQL> show parameter control
>
> I'm thinking that we need to configure the autobackup and snapshot
> controlfile locations to wherever your datafile backup goes. I
>
> But please show me the above and see what we get.
>
> Cheers,
>
> Leng Burgess.
>
>
> On Tue, Aug 21, 2018 at 3:19 AM, Jeff Chirco <backseatdba_at_gmail.com>
> wrote:
>
>> Sorry you are right the backup portion is running, it just last part that
>> is not.
>> Thanks for your help!
>>
>>
>> RMAN> backup current controlfile;
>>
>> Starting backup at 20-AUG-18
>> using target database control file instead of recovery catalog
>> allocated channel: ORA_DISK_1
>> channel ORA_DISK_1: sid=197 devtype=DISK
>> channel ORA_DISK_1: starting full datafile backupset
>> channel ORA_DISK_1: specifying datafile(s) in backupset
>> including current control file in backupset
>> channel ORA_DISK_1: starting piece 1 at 20-AUG-18
>> RMAN-00571: ===========================================================
>> RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
>> RMAN-00571: ==============================
>>
>
>
>
>> =============================
>> RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/20/2018
>> 10:17:
>> 26
>> ORA-19599: block number 10014 is corrupt in control file
>> C:\ORACLEXE\APP\ORACLE\
>> PRODUCT\10.2.0\SERVER\DATABASE\SNCFXE2.ORA
>>
>>
>> On Sun, Aug 19, 2018 at 12:39 AM Leng <lkaing_at_gmail.com> wrote:
>>
>>> What do you meany by ‘my Rman backups are failing everyday’? Is it the
>>> entire backup or just the last part where it tries to do an autobackup?
>>>
>>> You could try turning on debug as follows:
>>>
>>> Rman> debug on;
>>> Rman> spool trace to ‘c:\temp\ctl.debug;
>>> Rman> backup current control file;
>>> Rman> spool trace off
>>>
>>> Please email the trace file and output from the above and I’ll have a
>>> quick look...
>>>
>>> Cheers,
>>> Leng Burgess.
>>>
>>> On 18 Aug 2018, at 12:58 am, Jeff Chirco <backseatdba_at_gmail.com> wrote:
>>>
>>> Thanks for the suggestions. I checked the drive space and it is not an
>>> issue. However I did change the snapshot controlfile location to a
>>> different disk and ran a backup spfile. Still getting same corruption
>>> notice. It keeps talking about corruption in (file 0, block 10014). No
>>> other errors in alert log.
>>> We use this instance in retail locations and there haven't been any
>>> issues with the database, and it gets rebooted every night. Just my rman
>>> backups are failing everyday. Good thing we also do data pump exports.
>>>
>>> On Thu, Aug 16, 2018 at 4:16 PM LK <lkaing_at_gmail.com> wrote:
>>>
>>>> Yep, agreed.
>>>>
>>>> Try using a different drive that has plenty of free space and do the
>>>> tests that I've outlined before...
>>>>
>>>> eg:
>>>>
>>>> RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'F:\DBA\SNAPCF_XE.F';
>>>>
>>>> And take an spfile backup - this should genereate a new snapshot
>>>> controlfile:
>>>>
>>>> RMAN> backup current controlfile;
>>>>
>>>> I'd also get the sysadmin to do hardware/os/firmware check of the
>>>> server in case this is just the tip of the iceberg... is there corruption
>>>> in the underlying hardware/storage/firmware etc.
>>>>
>>>> And check the alert.log - have you got other issues as well?
>>>>
>>>> Cheers,
>>>>
>>>> Leng Burgess.
>>>>
>>>> On Fri, Aug 17, 2018 at 8:38 AM, Andrew Kerber <andrew.kerber_at_gmail.com
>>>> > wrote:
>>>>
>>>>> You may simply be out of space.
>>>>>
>>>>> Sent from my iPad
>>>>>
>>>>> On Aug 16, 2018, at 17:35, Jeff Chirco <backseatdba_at_gmail.com> wrote:
>>>>>
>>>>> Yes I have 3 control files but this is not a control file, its the
>>>>> snapshot control file. I have deleted this snapshot file and it recreates
>>>>> it as corrupt. I am wondering which control file could be corrupt.
>>>>>
>>>>> On Thu, Aug 16, 2018 at 1:19 PM Mladen Gogala <gogala.mladen_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On 08/15/2018 07:21 PM, Jeff Chirco wrote:
>>>>>>
>>>>>> > I have an 10g XE database that is failing during rman backup.
>>>>>> > ORA-19624: operation failed, retry possible
>>>>>> > ORA-19599: block number 10014 is corrupt in control file
>>>>>> > C:\ORACLEXE\APP\ORACLE\PRODUCT\10.2.0\SERVER\DATABASE\SNCFXE.ORA
>>>>>> >
>>>>>> > I am not sure what SNCFXE.ORA is but I believe it is some snapshot
>>>>>> > control file backup. Anybody know how to recover for this? Do I
>>>>>> need
>>>>>> > to do a full recovery from controlfile trace?
>>>>>>
>>>>>> Hopefully, you have more than one control file? If you do, please
>>>>>> copy
>>>>>> the correct one over the corrupt
>>>>>> C:\ORACLEXE\APP\ORACLE\PRODUCT\10.2.0\SERVER\DATABASE\SNCFXE.ORA
>>>>>> file.
>>>>>> Check your control_files parameter in the instance. If you don't have
>>>>>> more than one, try dumping it to trace (ALTER DATABASE BACKUP
>>>>>> CONTROLFILE TO TRACE AS 'C:\temp\ctlfile.sql' NORESETLOGS) then
>>>>>> shutting
>>>>>> down the instance and re-creating the control file.
>>>>>>
>>>>>> --
>>>>>> Mladen Gogala
>>>>>> Database Consultant
>>>>>> Tel: (347) 321-1217
>>>>>>
>>>>>> --
>>>>>> http://www.freelists.org/webpage/oracle-l
>>>>>>
>>>>>>
>>>>>>
>>>>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Aug 21 2018 - 16:54:25 CEST