Truncate Recover

Hi all
In a recover scenario.A table has truncated and I know truncate time.Database in archive mode and backing up daily.I want to recover table but dont want TSPITR because tables' s tablespace contain a lot of important tables.Is there any way to perform TSPITR but I just recover one table data back ?I guess this operation might be on diffrent machine.Which steps I have to do ? Or any Link ?
Best Regards..

Hi,
In this case, I think that flashback drop feature cannot help you. Since there is no undo command for a truncate, a recovery of the database is required to get the data back in the table.
According to Oracle Metalink Note:141194.1 you can try:
*NOTE: Always backup the database before starting to recover or restore old backups.
1. Is there an export dump of the table which I can use to restore the data?
a. yes -> import the file
b. no -> go to step 2.
2. Is the database is archivelog mode ?
a. yes -> go to step 3.
b. no -> go to step 4
3. The database is in archivelog mode. This makes it possible to recover the
database until a moment just before the truncate command.
a. restore a backup of the database to another location.
b. recover this database to a moment in time BEFORE the truncate command
RECOVER DATABASE UNTIL TIME .....
c. export the table data from this recovered database.
d. import the data back into the original database
e. remove the restored database.
4. Since the database is not in archivelog mode, there is no way to recover
the database to a time just before the truncate command.
Contact Oracle Support to discuss the possible options left.
Cheers

Similar Messages

Recovering Data from a truncated table in OraXE?

A funny thing happened, i truncated a table containing BLOBs and other stuff, with over 700 entries!!, now i wanna know if it´s feasible to recover that truncated data, i'm just wondering about it, i know it sounds silly i know, but the storage space didn´t get shorter after the data was truncated from the table, so after this´s been said, can any body explain me what happened, can i retrieved this truncated data that i truncated from the table (without any previous backup)?
Message was edited by:
efebo_abel2002
Message was edited by:
efebo_abel2002
Mensaje editado por:
efebo_abel2002

Truncate simply resets the pointer that marks the 'end of data' in a table to the beginning of the table. The storage is still allocated, on the assumption that you want to reuse the table and want to avoid the overhead associated with extending the table. The system knows there are never any rows past the 'end of data' and it won;t bother looking past that point.
Recovering that data from the actual current database - about as likely as recovering data from the Windows recycle bin when you've set the max allowable storage in the recycle bin to '0'. Technically possible, but needing someone with a lot of experience and patience ... and absolutely no changes to the database after truncate. An expensive proposition.
You have, of course, switched to archive log mode and been taking regular backups. (Have you not?) In which case, a 'point in time' recover, to just before the truncate, would be the solution. This brings back the database (or at least a tablespace) back to a former 'life', and is quite different from restoring a table.

Table Truncated, Flashback is enabled ... How to recover.

Hi,
There is a table which was truncated, as we have flashback enabled. Even we have previously enabled row movement of the particular table.
How to recover ????
Thanks.

hi,
There are three options available:
1. Restore and recover the primary database to a point in time before the drop.
This is an extreme measure for one table as the entire database goes back in
time.
2. Restore and recover the tablespace to a point in time before the drop.
This is a better option, but again, it takes the entire tablespace back in time.
3. Restore and recover a subset of the database as a DUMMY database to export
the table data and import it into the primary database. This is the best option
as only the dropped table goes back in time to before the drop.
For the first, see information on performing incomplete recovery on a database.
The second and third options are virtually the same, it depends if the entire
tablespace data should be taken back in time, or just recovering the one table.
The tablespace point in time recovery (TSPITR) may be useful if there are
dependencies between the dropped/truncated table and other tables in the
database. For the second option, see RMAN documentation on TSPITR and/or Note 180436.1 RMAN Tablespace Point in Time Recovery Example. Both procedures
for the second and third options are very much the same. The differences are
that the TABLE PITR has to be exported/imported manually while the TABLESPACE
PITR is fully automated by RMAN.
This article will deal with the third option.
General overview of procedure to recover from a DROP or TRUNCATE table by using RMAN.
To recover from a dropped or truncated table, a dummy database (copy of primary)
will be restored and recovered to point in time so the table can be exported.
Once the table export is complete, the table can be imported into the primary
database. This dummy database can be a subset of the primary database. However,
the 'dummy' database must include the SYSTEM, UNDO (or ROLLBACK), and the
tablespace(s) where the dropped/truncated table resides.
The simpliest method to create this 'dummy' database is to use the RMAN
duplicate command. See:Note 228257.1 RMAN Duplicate Database in Oracle9iNote 73912.1 RMAN Creating a Duplicate Database -- Oracle8i
The difference between the two versions is that Oracle9i duplicate command
allows for a 'SKIP TABLESPACE' option. Thus Oracle9i allows for a duplication
of a subset of the database.
In Oracle8i, you cannot 'skip' tablespaces when using duplicate, so you must
duplicate the entire database. If this is not a desired option, or you must
restore the original database and thus cannot use
the rman DUPLICATE.
NOTE: The remainder of this information is for users who cannot use the
DUPLICATE command in Oracle8i. I.e., you want to restore only a subset
of the Oracle8i database.
Requirements :
a) RMAN backup of the primary database should be available to the
host where it has to be restored on.
b) Use of an RMAN-catalog database
c) Auxiliary instance created and started in NOMOUNT
(See Note 180436.1 step I. Create the auxiliary initSID.ora.)
Create this from the init.ora of the primary database and:
!!!!! IMPORTANT !!!!!!!!
If using the same host as the primary, be VERY careful as you do not want to
restore on top of existing files being used by the primary (production database).
Doing so can corrupt and crash the production database!!!!!!
- be sure all paths for this AUX instance are different than primary.
- be sure CONTROL_FILES parameter has different location but more importantly DIFFERENT NAME.
- add LOCK_NAME_SPACE to any value other than the primary database name.
- change/add SERVICE_NAME=AUX1.
- use the SAME DB_NAME as for the production database
- BE SURE you include the 'alter database rename file' command at the end
of the script. This changes the location and/or name of the online
redo log files.
d) Set ORACLE_HOME and ORACLE_SID set to the auxiliary instance
e.q set ORACLE_SID=AUX1
set ORACLE_HOME=<....>
!!!!! IMPORTANT !!!!!!!!
1: Restore and recover the tablespace
The restore and recovery is done by RMAN. Create a file
of the script below (e.q table_pitr.cmd) and execute the following
command :
$ rman cmdfile=table_pitr.cmd
NOTE: ORACLE_HOME and ORACLE_SID set to the auxiliary instance
NOTE: The Auxiliary instance IS the target to rman at this point.
The RMAN-script :
connect catalog rman/rman@v920_nlsu31
connect target /
run
allocate channel t1 type sbt_tape
parms='SBT_LIBRARY=/home/usupport/liblsm.so';
set until time "to_date( '09-10-2005 06:00', 'DD-MM-RRRR HH24:MI')";
restore controlfile;
sql "alter database mount clone database";
set newname for datafile 1 to '/fs01/oradata/tspitr/system01.dbf';
set newname for datafile 2 to '/fs01/oradata/tspitr/undotbs01.dbf';
set newname for datafile 4 to '/fs01/oradata/tspitr/tools01.dbf';
restore tablespace system, undotbs1, tools;
switch datafile all;
sql "alter database datafile 1,2,4 online";
recover database skip forever tablespace TEMP,INDX,USERS,OLTS_ATTRSTORE,
OLTS_CT_DN,OLTS_CT_CN, OLTS_CT_OBJCL,OLTS_CT_STORE,OLTS_DEFAULT,
OLTS_TEMP,OLTS_IND_ATTRSTORE,
OLTS_IND_CT_DN,OLTS_IND_CT_CN,
OLTS_IND_CT_OBJCL,OLTS_IND_CT_STORE,
P1TS_ATTRSTORE,P1TS_IND_STORE;
sql "alter database rename file ''/fs01/oradata/primary/REDO01.LOG'' to ''/fs01/oradata/tspitr/REDO01.LOG''";
sql "alter database rename file ''/fs01/oradata/primary/REDO02.LOG'' to ''/fs01/oradata/tspitr/REDO02.LOG''";
sql "alter database rename file ''/fs01/oradata/primary/REDO03.LOG'' to ''/fs01/oradata/tspitr/REDO03.LOG''";
/* NOTE: Syntax within rman is two single quotes around each name, this may be operating system specific. */
release channel t1;
Explanation :
- Tape channel allocated, but could also be a disk channel, depending
on where the backups are.
- SET UNTIL TIME
User specified time, just before the DROP/TRUNACTE table
- MOUNT CLONE DATABASE.
This forces all datafiles to be put OFFLINE. Just for safety reasons.
- SET NEWNAME
New path for the datafile to be restored. Keep in mind that this is
done on the auxiliary instance and should NOT interfere/overwrite the
prodution database.
- ALTER DATABASE RENAME FILE
This is required to change the location of the online log files. When the
'resetlogs' is issued, Oracle will create online logs based on specification
in the controlfile. This command changes the location and/or name. If
this is being performed on the SAME server, not issuing a rename will
cause Oracle to reset the production online log files. This will corrupt
and crash the production database!!!!!!
- RESTORE TABLESPACE ...;
Restore the tablespaces which need to be recoverd.
This includes always the SYSTEM, rollback/undo tablespace and
the tablespace(s)where the dropped/truncated table resides.
The SYSTEM tablespace is always included as it containts most / all of
the objects owned by SYS and SYSTEM. Some other tablespaces might be
included as well when they contain objects owned by SYS and SYSTEM.
SQL> select distinct tablespace_name
from dba_segments where owner in ('SYS', 'SYSTEM');
- SWITCH DATAFILE ALL;
Make the changes in the pathname (set by SET NEWNAME) active in the
controlfile.
- ALTER DATABASE DATAFILE ... ONLINE
Online the datafiles which are restored and have to be recovered.
- RECOVER DATABASE SKIP FOREVER TABLESPACE ......;
You need to specify the complete list of tablespaces which will not be
recovered. Else the recovery fails, that it cannot dentify/file the
tablespace datafile. The SKIP FOREVER clause causes RMAN to take the
datafiles offline using the DROP option. Only use skip forever when the
specified tablespaces will be dropped after opening the database. I.e.,
all tablespaces except the one which contains your data.
The recovery of RMAN, checks the datafileheaders, to get a starting point
for the recovery.
2: Open auxiliary database with RESETLOGS
$ sqlplus /
SQL> alter database open resetlogs;
This step should ALWAYS be executed outside RMAN via SQL*Plus. If the open
is executed in RMAN it may effect the primary database's entry in the RMAN
catalog. Backups will fail with messages like:
RMAN-20011 "target database incarnation is not current in recovery catalog"
3: Export the table
The database is recovered and open, so it can be used by export.
Example:
$ exp userid=system/<password> file=table.dmp
tables=(<owner>.<tablename>, ...) rows=Y
4: Import the export-dump
Import the data of the dropped table back into the primary/production database.
Example:
$ imp userid=system/<password> file=table.dmp ignore=Y
5: Remove this AUX/DUMMY database
Shutdown and remove all files associated with this database. It has satisfied
your purpose. I.e., to give you an export of this table.

One track is always truncated when I try to import

This is the weirdest thing. I am running iTunes 7.7 on my MacBook, although this problem appears to have occurred ages ago when I originally ripped this CD.
It's a store-bought classical CD, which I very much like. When I put it in the drive, it shows up in iTunes, and all of the track lengths show up correctly. The crucial one here is track 1, which is 8:30 long. If I play it from there, I get the whole track, no problems.
If I then import the CD, all of the tracks come in correctly, except this one. It comes in as only being 2:12 long. That is, if I look at the CD, it still claims to be 8:30 and it claims to have successfully imported, but if I look at the music library, it claims to be 2:12, and when I play it, it's truncated.
I checked the start and stop times with Get Info, and they match what I'm seeing -- if I try to set the imported file to be 8:30, it won't let me do it.
The CD was made in 1990, if that's relevant (I was wondering if perhaps there was some attempt at copy-protection denying me a legal use).
When I try to copy the file by drag-and-drop from CD to desktop, I also get an error, so I'm wondering if the file is just corrupted on the CD. (Other files on the same CD copy okay.)
I've rebooted, I've reimported, I've tried everything I could think of. I have no earthly idea what's going on here.
Any ideas? Any way to recover this piece of music if the CD is corrupted such that it only allows playback but cannot be copied?
-- Aimee

It sounds like there might be some weird error on the disc. iTunes' ripper isn't necessarily the best for dealing with damaged discs, give this one a whirl:
http://sbooth.org/Max/

Replace Metadata in Bridge CS4 appears to truncate 5.9GB .PSB File; Does CS6 do this too?

I am running Photoshop CS4 on a MacBook Pro with Mac OS X 10.6.8, and ran into a problem with Bridge. I would like to know if this problem occurs with Photoshop CS6. Here's the sequence of events:
1. I have a 5.9GB .psb file created with PS; it loads into PS cleanly - no errors.
2. In Bridge, I create a metadata template, and apply it to my .psb file using "Replace Metadata".
3. The "Replace Metadata" operation completes quite quickly, no error messages
4. Immediately after the "replace Metadata" operation Bridge reports that my 5.9GB file is now a 1.6GB file - 4.3GB smaller!!
5. Bridge displays the updated metadata, no visible indication anything is wrong.
6. Now the file will not open in Photoshop - the read starts, but errors out with "unexpected end of file".
7. I restore the 5.9GB file and can open it in Photoshop without problems.
Update:
This problem is not specific to the "Replace Metadata" function in the Bridge menu. I get a similar result by updating the metadata for this file in the Metadata Panel; the resulting file is truncated, but appears to be a different size this time, and it will not open in Photoshop - same error message as before.
This is a 34-image 36856px X 7464px panorama

Thanks for your suggestion, appreciate your effort to help. The link you provided seems to focus on transfer rates and performance; it does take a while to write or read this file, but I expect that. I'm not using RAID of any flavour. I do not expect file corruption, which is what I believe is happening (and PS is reporting).
I have a number of large panoramas; this is the largest. I believe the largest of the others is a bit over 3GB; I have no difficulty updating the metadata in the other panoramas through the metadata panel or with "Replace Metadata". All of these files live on the same drive (therefore connected to the same firewire port). They are backed up to a USB drive with Time Machine, and I've recovered the 5.9GB file from the Time Machine drive a number of times. I can always read the recovered file with PS, and the size after recovery is always exactly the same. When I realized that the size of my 5.9GB file changed during/because of the metadata update, I reverted to an earlier stage in the post-processing, got a 3.8GB .PSB and put a copy on DVD; the DVD copy is good, and I can easily and quickly reconstruct the 5.9GB file by applying the same actions used the first time (the 5.9GB file has three layers that are not in the 3.8GB .PSB). I have not tried to change metadata in the 3.8GB PSB, and can't try that for the next few weeks as I'll be travelling. The only thing I'm certain of is that updating the metadata in the 5.9GB .PSB reduces the size to 1.6GB (put text in Headline field through Metadata panel) or 1.4GB ("Replace Metadata" in Bridge Tools menu), depending on how the update is done.
So, the 5.9GB file has survived several complete transfers (PS=>Disk, Disk=>Time Machine, multiple Time Machine=>Disk, PS=>Disk to 3.8GB after deleting layers, and Disk(3.8GB)=>DVD) with no signs of corruption.
It's very hard to accept the idea that there's some kind of hardware problem that afflicts just one file. The 5.9GB file is output from PS CS4, and I can read it back into PS with no problem.
I'll watch this forum for a few days to see if there are more answers until I have to travel. If not, I'll figure it out another way and report a bug in CS6 if that appears to be appropriate.

While posting truncation in *j1incust* (enter withholding tax certificate

Dear experts
while posting truncation in j1incust (enter withholding tax certificate from customer ) am getting this error
No unpaid tax lines exist for the given selection criteria.
Message no. 8I702
Diagnosis
The corresponding withholding tax line &1& is not present in WITH_ITEM table.
System Response
For withholding tax recovered from the vendor, tax line is present in table BSIS, but the corresponding entry is missing in table WITH_ITEM , which is necessary for challan updation. Check the entries.
Procedure
check entries in table WITH_ITEM for the open tax items chosen for clearing.
thankx in advance
Ajeesh.s

Dear,
This happens mainly due to wrong or no business place assignment at invoice or payment.
Try to update the business place and run teh program. You can update the business place using J1INPP.
check also whether the TDS account is maintained on Open Item basis.
regards

Recover database using cold backup

Hi All,
One of the table is delete by one of our DBA from PROD accidentally. We have a cold backup on one day before.
Now we are trying to restore it from the cold backup. PROD DB is in archivelog and all the archive is in tact.
The table got truncated today at 8 PM. Can we apply the database till 8 PM so that we can restore the truncated table using cold backup.
Please find the below steps which we are using to restore.
creating controlfile
starting the db in mount state
recover database;
Will it ask for latest archive log when we try to recover it.
ENV details -
DB - 11.2.0.1
Please suggest.
Thanks

Hi,
If you have doubts about the procedure to use to restore a backup to a point in time, then please take a look at the documentation first: Performing Flashback and Database Point-in-Time Recovery - 11g Release 2 (11.2)
After you specify the time when the recovery must end (UNTIL clause in rman), then the RECOVER command will try to use the archivelogs needed.
Before starting with this PITR operation, you should check if your database has flashback active, because it will be much easier to recover using it.
This is also explained on the same document linked above.
Regards.
Nelson

Recover a deleted record / table

Hello,
Our Oracle DB (10.2.0.4) is on archive mode. But flashback is not enabled
In such cases, If a user deleted a table entry / a entire table itself, Is it possible to recover
How to solve this kind of a issue.
Is it really deleting from the DB or else is it just mark as flag (flag as deleted.)
regards,
Zerandib

Hello Zerandib,
depending on how the user deleted the data (DML = DELETE or DDL = TRUNCATE) from the entire table or just a table entry - you can use flashback query. Flashback query works with the undo data - so you can flashback your table until UNDO_RETENTION.
Official documentation:
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e17125/adfns_flashback.htm#ADFNS01003
If the data is not stored in undo tablespace anymore - you can also use the LogMiner to rebuild your data with help of the archive logs:
http://download.oracle.com/docs/cd/E11882_01/server.112/e16536/logminer.htm#SUTIL1553
If your entire table was deleted with DDL (TRUNCATE) you need to restore your whole database and recover it.
Regards
Stefan

Recover from full backup

Hi,
I want to recover a tablespace from a RMAN full backup. Now the related schema has many truncated objects (in a bach process), so normal tablespace restore, recovery won't help. Have to go for TSPITR. But the time I can't fix. Is there any other way to recover the tablespace other than point-in-time recovery ?

Hi Hemant,
When I run the TSIPTR recovery I am getting error,
RMAN> run {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_CLIENT=UBIHQ,NB_ORA_SERV=UBIHQ';
RECOVER TABLESPACE PD811T UNTIL TIME "to_date('02-JUL-2010 23:00:00','DD-MON-YYYY HH24:MI:SS')";
auxiliary destination '/tmp';
}2> 3> 4> 5>
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00558: error encountered while parsing input commands
RMAN-01009: syntax error: found "auxiliary": expecting one of: "allocate, alter, backup, beginline, blockrecover, catalog, change, copy, convert, crosscheck, configure, duplicate, debug, delete, execute, endinline, flashback, host, mount, open, plsql, recover, release, replicate, report, restore, resync, }, set, setlimit, sql, switch, startup, shutdown, send, show, transport, validate"
RMAN-01007: at line 5 column 1 file: standard input

I want to know when we issue truncate table statement in oracle .

i want to know when we issue truncate table statement in oracle .No log will be write in redo log .But we can recover data using flashback or scn.I want to know where is the actually truncate table statement log is stored in oracle database.Please explain me in detail step by step .

Hi,
I have truncated table after that i have restored that data.See below the example.I want to know from where it's restored.
From which log file it's restored.
create table mytab (n number, x varchar2(90), d date);
alter table mytab enable row movement;
Table altered.
SQL> insert into mytab values (1,'Monsters of Folk',sysdate);
1 row created.
SQL> insert into mytab values (2,'The Frames',sysdate-1/24);
1 row created.
SQL> commit;
Commit complete.
SQL> select CURRENT_SCN from v$database;
CURRENT_SCN
972383
SQL> select * from mytab;
N
X
D
1
Monsters of Folk
30-DEC-12
2
The Frames
30-DEC-12
N
X
D
SQL> set lines 10000
SQL> /
N X D
1 Monsters of Folk 30-DEC-12
2 The Frames 30-DEC-12
SQL> select to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'
20121230 09:29:24
SQL> set timing on
SQL> truncate table mytab;
Table truncated.
Elapsed: 00:00:15.75
SQL> select * from mytab as of timestamp TO_TIMESTAMP('20121230 09:29:24','yyyymmdd hh24:mi:ss');
N X D
1 Monsters of Folk 30-DEC-12
2 The Frames 30-DEC-12
Elapsed: 00:00:00.28
SQL> insert into mytab select * from mytab as of timestamp TO_TIMESTAMP('20121230 09:29:24','yyyymmdd hh24:mi:ss');
2 rows created.
Elapsed: 00:00:00.01
SQL>

How to recover from database consistency errors?

I have a SQL server cluster 2005. Due to the broken of SAN storage's controller and disks, one of my SharePoint content DB has corrupted and has been causing numerous error to the SharePoint. I have run the command "DBCC CHECKDB WITH NO_INFOMDGS"
and the truncated output are as following:
Table error: Object ID 53575229, index ID 1, partition ID 72057594038583296, alloc unit ID 72057594043564032 (type In-row data), page ID (3:21580503) contains an incorrect page ID in its page header. The PageId in the page header = (3:21580511).
CHECKDB found 0 allocation errors and 6 consistency errors in table 'AllDocs' (object ID 53575229).
Table error: Object ID 53575229, index ID 1, partition ID 72057594038583296, alloc unit ID 72057594043564032 (type In-row data), page ID (3:21580503) contains an incorrect page ID in its page header. The PageId in the page header = (3:21580511).
CHECKDB found 0 allocation errors and 6 consistency errors in table 'AllDocs' (object ID 53575229).
Object ID 1058102810, index ID 4, partition ID 72057594052411392, alloc unit ID 72057594058571776 (type In-row data): Page (3:21580478) could not be processed. See other errors for details.
CHECKDB found 0 allocation errors and 4 consistency errors in table 'EventCache' (object ID 1058102810).
Table error: Object ID 1762105318, index ID 1, partition ID 72057594055819264, alloc unit ID 72057594062897152 (type LOB data). The off-row data node at page (3:21985593), slot 35, text ID 5702751551488 is not referenced.
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 1762105318, index ID 1, partition ID 72057594055819264, alloc unit ID 72057594062897152 (type LOB data). The off-row data node at page (3:21985594), slot 14, text ID 5702751354880 is not referenced.
Msg 8986, Level 16, State 1, Line 1
Too many errors found (201) for object ID 1762105318. To see all error messages rerun the statement using "WITH ALL_ERRORMSGS".
CHECKDB found 0 allocation errors and 307 consistency errors in table 'AuditData' (object ID 1762105318).
CHECKDB found 0 allocation errors and 363 consistency errors in database 'ALCIM_WSS_Content'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (WSS_Content).
Error show in the event log:
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 3:21580475; actual 0:0). It occurred during a read of page (3:21580475) in database ID 9 at offset 0x00002929576000 in file 'E:\Microsoft SQL Server\Data\MSSQL.1\MSSQL\DATA\WSS_Content_2.ndf'.
The last DB backup creatred was about a month ago so doing DB resotre will be my last choice. Is it possible I can recover the DB without data loss using "DBCC CHECKDB ('WSS_Content', REPAIR_REBUILD)"? Any alternative method to acheive my
goal?
Thank you.

Hi,
Check this part of the output that you have posted
"repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB (WSS_Content)."
Which clearly states that your only option is "repair_allow_data_loss". This option should ONLY be tried as a last resort. If you have any chance of restoring the backup as Bass_player suggested that should be your way. Even if you run repair_allow_data_loss
and it runs successfully and fixes the corruption, you still would be facing logical corruption with data, as we never know which all records repair_allow_data_loss removes.
More over in case of SharePoint databases as far as I know, Microsoft Sharepoint Support never used to support those sharepoint databases which were repaired. They will only support a backup of the database in case of corruptions.
I would suggest you to start working on a better disaster recovery plan in the mean while you are waiting for the backups :)
HTH,
Regards, Ashwin Menon My Blog - http:\\sqllearnings.wordpress.com

Error 820D - Invalid database - truncated to 0 bytes

Hi Forum.
I'm importing Mail into an account and every time I ran into the following error when the ofuser DB file size hit the 2gb.
POA Log:
10:05:37 F403 The database function 44 reported error [820D] on userq4f.db
10:05:37 F403 Error: File size is too large [820D] User:$USER ($USER)
GWcheck log:
STRUCTURAL VERIFICATION of database /media/nss/$DIR/ofuser/userq4f.db
Error 42- Invalid database - truncated to 0 bytes
Suggestion- No direct recovery possible. Attempt to recover file from external backup.
If no backup exists, request explicit structural rebuild from Admin and the
database will be replaced by valid empty database, to allow re-create.
However, all data previously contained in the database will be lost!
It seems to me that there is a limitation somewhere but I don't get exact information where?
I found nothing about the 820D in the error code documentation...
Someone experienced this ever? Can someone explain that?
Thanks in advance,
Pascal

Hi Laura,
done with the options:
<?xml version="1.0" encoding="UTF-8"?>
<GWCheck database-path="L:\XX_PO">
<database-type>
<post-office>
<post-office-name>
XX_PO
</post-office-name>
<object-type>
<user-resource>
<name>
userq4f.db
</name>
</user-resource>
</object-type>
</post-office>
</database-type>
<action name="analyze-fix-database">
<contents/>
<fix-problems/>
</action>
<process-option>
<databases>
<user/>
<message/>
</databases>
<logging>
<file>
gwchk32.log
</file>
</logging>
<results>
<send-to>
<admin/>
</send-to>
</results>
<misc>
<support-option>
SUBJECTLIST
</support-option>
</misc>
</process-option>
</GWCheck>
But there is nothing in the folder from where I gwcheck.exe started.... Any other suggestions?
Thanks,
Pascal

TRUNCATE = DELETE

Hi all,
11g and 10g
I am truncating a big table and it took 1hr to complete :(
If I set my database to force logging, does this mean that truncate table is forced to log and behave like delete command?
Thanks a lot,
zxy

Force logging is for redo. See http://www.orafaq.com/wiki/Nologging_and_force_logging
Your problem might be Oracle's tendency to do lazy databases writes. It's quick to write things to memory, then the dbwr writes it whenever it damn well pleases, which could be never in the case of delayed block cleanout. Why is this not a problem? Because redo is the critical write for Oracle to know conclusively that something is real when you have to recover. That's why you need to do a backup right after nologging operations, because things are not in the redo stream, and use force logging for standby databases, which are basically in continuous recovery.
It is possible for some performance effects to be seen if you have contention between redo and datafiles. But that is consequential, not likely causative for what you are talking about. Then again, if you have some kind of redo writing problem, who knows? You probably should check what Oracle is actually waiting on.

Corrupted innodb table crashing mysql instance how to recover table?

Hello,
Running a simple query against corrupted innodb table is crashing mysql instance .
table test.xyz got corrupt during crash and truncate table command was in progressing when mysql crash , now
running a simple select * query is also crashing db .
mysql> use test;
Database changed
mysql> select * from xyz;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql>
mysql>
mysql> select * from xzy;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
ERROR:
Can't connect to the server

Try to start mysql with innodb_force_recovery = 6
Or to try to restore by means of the tool:
MySql Recovery Toolbox and find out how you can use the corrupt MySQL recovery tool for damaged database restoration and easily repair known issues or already known problems, occurred in MySql files. This MySql repair utility offers many benefits
like:
Supports all MySql file versions and parses even very large documents on older PC computers;
Supports primary and external keys, tables, views, indexes and other objects;
Allows previewing recovered data in freeware mode so you can get results without purchasing MySql Recovery Toolbox
For more information: http://www.mysqlrecoverytoolbox.com/
As you can look for the answer here:
http://www.filerepairforum.com/forum/databases/databases-aa/mysql/197-corrupted-innodb-table-crashing-mysql-instance-how-to-recover-table

Undo tablespace/redo logs/ DML /DDL/ truncate/ delete

1st scenario:Delete
10 rows in a table
Delete 5 rows
5 rows in the table
savepoint sp1
Delete 3 rows
2 rows in the table
rollback to savepoint sp1
5 rows in the table
So all DML affected values are noted in the undotablespace and present in the undotablespace until a commit is issued.And also redo logs make note of DML statements.AM I RIGHT??????
2nd scenario-truncate
10 rows in table
savepoint sp1
truncate
0 rows in table
rollback to savepoint sp1 gives this error
ORA-01086: savepoint 'SP2' never established
So is truncate [are all DDL statements] noted in the undo tablespace and are they noted in the redologs????????
I KNOW THAT A DML IS NOT AUTOCOMMIT AND A DDL IS AN AUTOCOMMIT

When you issue a delete is the data really deleted ?WHen you issue a delete, there is a before image of the data recorded to the undo area. (And that undo information itself is forwarded to the redo.) Then the data is actually deleted from the 'current' block as represented in memory.
Therefore, the data is actually deleted, but can be recovered by rolling back until a commit occurs.
It can also be recovered using flashback techniques which simply rebuild from the undo.
When you issue a truncate is the data really deleted
or is the high water mark pointer for a datablock lost?The data is not deleted. Therefore there is no undo record of the data 'removal' to be rolled back.
The high water mark pointer is reset. It's old value is in the undo, but the truncate is a DDL command, and it is preceded and followed by an implicit commit, voiding any potential rollback request.
I mean you can always rollback a delete and not
rollback a truncate?Correct - using standard techniques, deletes can be rolled back and truncates can not.

Truncate Recover

Similar Messages

Maybe you are looking for