Reduce flashback log - disable flashback for a table

Hi,
We have a table which we use only for logging. This information is not essential but there is a lot (given our scale of data :p ) of data (5.000.000 by day)
So we have put the table in nologging (reduce redo => archived),
the insert are /*+ append*/ (reduce undo)
Now, we want to reduce the flashback logs?
Is there a way to disable flashback for a given table ?
thanks
Nicolas

Hi,
first i would use:
alter table tablename nologging;
So you won't generate a lot of redo.
http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_3001.htm#CJAHHIBI
I'm not sure you can disable flashback at table level.
You can do that on tbs level.
Hope this helped..
Bye
Acr

Similar Messages

Disable Statistics for specific Tables

Is it possible to disable statistics for specific tables???

If you want to stop gathering statistics for certain tables, you would simply not call DBMS_STATS.GATHER_TABLE_STATS on those particular tables (I'm assuming that is how you are gathering statistics at the moment). The old statistics will remain around for the CBO, but they won't be updated. Is that really what you want?
If you are currently using GATHER_SCHEMA_STATS to gather statistics, you would have to convert to calling GATHER_TABLE_STATS on each table. You'll probably want to have a table set up that lists what tables to exclude and use that in the procedure that calls GATHER_TABLE_STATS.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Estimate of Flashback logs to expect for my database

Hi all,
Please I need to know (roughly) the size of flahback logs to expect for my database.
My database is about 500G in size, grows at about 1% per month and I hope to keep flashback logs for 48 hrs.
If you currently use the flashback technology, let me know your database size, how many hours of flashback logs you keep and the size of your logs. If I get 2 or 3 responses, then I'll be able to make an intelligent guess for what my database flahback log size might be.
Regards
baffy

The value of the DB_FLASHBACK_RETENTION_TARGET parameter (1440
minutes in our example) determines how much flashback data the database should
retain in the form of flashback database logs in the flash recovery area. In order to
estimate the space you need to add to your flash recovery area for accommodating
the flashback database logs, first run the database for a while with the flashback
database feature turned on. Then run the following query:
SQL> select estimated_flashback_size, retention_target,
flashback_size from v$flashback_database_log;
ESTIMATED_FLASHBACK_SIZE RETENTION_TARGET FLASHBACK_SIZE
126418944 1440 152600576

Disabling sorting for a table

Hi All,
I want to disable the sorting function for my table. How can I achieve this? Please help...!!!
-sps

If you are using a JTable, by default row sorting is unable. Infact, to provide you the Table sorting, you have to put the line
JTable table = new JTable (...);
table.setAutoCreateSorter (true) //this enableinto your code or writing a RowSorter.
Otherwise there's no sorter for the Table and you can't do any kind of sorting.
Regards,
Maurizio

How to Force Flashback Logs to Grow

Hi, I want to test RMAN and Oracle's handling of disk space over time as a database is used, specifically flashback logs.
For this I want to increase the size of the flashback logs and see oracle delete the old flashback logs as the sizes grow. Is there a way to force the flashback logs to grow? Or at least an efficient way to do it? I know flashback logs are block level deltas of my datafiles but I don't want to modify the entire database to generate flashback data.
Thanks

Hi,
Is there a way to force the flashback logs to grow? Or at least an efficient way to do it? I know flashback logs are block level deltas of my datafiles but I don't want to modify the entire database to generate flashback dataThe size of flashback logs generated by the database for a given time period can vary considerably, however, depending on the specific database workload.
When flashback is in use, a before image of each block that is updated is copied to the flashback log ; this only needs to be done once since no matter how many times the same block is updated as, if we flash back, we only care about the initial contents of the block. The size of the before image will be the same as db_blocksize. So the key to understanding how much flashback data will be generated is not just how much redo is generated but how many physical blocks are updated. If more blocks are affected by database updates during a given interval, then more disk space is used by the flashback log data generated for that interval and you will find that the size of the flashback data may greatly exceed the size of the redo generated.
Read it:
CALCULATE THE VOLUME OF FLASHBACK LOG GENERATION [ID 761126.1]
Regards,
Levi Pereira

Logs the activities for specific critical tables

Hi Guys,
rec/client     Logs the activities for specific critical tables      OFF     Absence of logging of changes to critical tables in SAP could lead to unauthorized modifications being overlooked     ON
                    (Only for critical tables)     Set to ON
What does it mean? This is a piece of Audit Recommendation
what to do?Please help me out.
Itzz very urgent guys.
Points will be rewarded.
Warm Regards,
Mohandoss P.
Edited by: mohan doss on May 28, 2008 1:37 PM

Hi,
Parameter description :
This parameter is used to activate and deactivate client-dependent table logging. Depending on the setting of this parameters, certain change options are either not logged at all, or only in certain clients or in all clients. The settings for these tables in the ABAP Dictionary must be correctly set for this.
OFF       Table logging is deactivated. No change operations are logged, even if table logging is activated for certain tables in the ABAP Dictionary.
ALL       Table logging is activated in all clients. All change operations for tables are logged, according to the settings in the ABAP Dictionary.
<Client1>,<Client2>,...,<ClientN> (1 <= N <= 10)
          Table logging is only activated for the specified clients. You can specify up to 10 different clients.
   Caution: Make sure there are no space characters before or after the separator ",".
         Incorrect: rec/client=001, 002 , 003
         Correct: rec/client=001,002,003
Regards
Suresh Radhakrishnan
Edited by: Suresh Radhakrishnan on May 28, 2008 9:56 PM

11g block recover doesn't look for flashback logs

dear all
could you please let me know the reason of why rman doesn't uses flashback logs for block recovery? Here's the thread I've opened in ddatabase-general
Re: 11g block recover doesn't look for flashback logs
thanks
john

dear all
could you please let me know the reason of why rman doesn't uses flashback logs for block recovery? Here's the thread I've opened in ddatabase-general
Re: 11g block recover doesn't look for flashback logs
thanks
john

DR server flashback error : Unable to allocate flashback log

Hi,
I have a Standby Database and the DR log synchronization with Primary Database was interrupted due to below errors:
Unable to allocate flashback log of 1946 blocks from
current recovery area of size 2147483648 bytes.
Recovery Writer (RVWR) is stuck until more space is
available in the recovery area.
Unable to write Flashback database log data because the
recovery area is full, presence of a guaranteed
restore point and no reusable flashback logs.
Use ALTER SYSTEM SET db_recovery_file_dest_size command
to add space. DO NOT manually remove flashback log files
to create space.
--> On DR server
SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS FROM V$DATABASE;
DATABASE_ROLE INSTANCE PROTECTION PROTECTION_LEVEL
SWITCHOVER_STATUS
PHYSICAL STANDBY A80 MOUNTED MAXIMUM PERFORMANCE
SESSIONS ACTIVE
SQL> select process, status, thread#, sequence#, block#, blocks from v$managed_standby;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MRP0 APPLYING_LOG 1 29118 125049 186723
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
6 rows selected.
--> Alert log
Sat Mar 17 04:51:00 2012
RFS[606]: Archived Log: 'L:\ORACLE\A80\ORAARCH\A80ARCH\ARC29222_0681431456.001'
Primary database is in MAXIMUM PERFORMANCE mode
Sat Mar 17 05:51:07 2012
RFS[606]: Archived Log: 'L:\ORACLE\A80\ORAARCH\A80ARCH\ARC29223_0681431456.001'
Primary database is in MAXIMUM PERFORMANCE mode
Sat Mar 17 06:51:04 2012
RFS[606]: Archived Log: 'L:\ORACLE\A80\ORAARCH\A80ARCH\ARC29224_0681431456.001'
Primary database is in MAXIMUM PERFORMANCE mode
Sat Mar 17 08:50:40 2012
RFS[606]: Archived Log: 'L:\ORACLE\A80\ORAARCH\A80ARCH\ARC29225_0681431456.001'
Sat Mar 17 12:28:30 2012
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
I did a "ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL" to stop the log shipping on DR server but the command is hanging.
I also tried freeing up the disk space in my flashback drive but I think it won't help as indicated in the error message:
"DO NOT manually remove flashback log files to create space".
What is the best way to set the DR server back to normal operation?
I do not need the flashback logs and will disable the flashback once this is rectified.
This is Oracle 10.2.0.4 Physical Standby using Oracle Dataguard.
Thanks a lot!

<smacking forehead on the table>
Bloody hell! How the heck I missed that darn "B" ? I guess, time to get some sleep and after that some coffee.Please don't do ;-)
When knowledge is in extreme level, there is possibilities to miss small and small things some time.
@OP,
Here some practice
sys@ORCL> show parameter db_reco
NAME                                 TYPE        VALUE
db_recovery_file_dest                string      C:\Oracle\flash_recovery_area
db_recovery_file_dest_size           big integer 3852M
sys@ORCL> alter system set db_recovery_file_dest_size=3900mb scope=both;
alter system set db_recovery_file_dest_size=3900mb scope=both
ERROR at line 1:
ORA-02065: illegal option for ALTER SYSTEM
sys@ORCL> alter system set db_recovery_file_dest_size=4gb scope=both;
alter system set db_recovery_file_dest_size=4gb scope=both
ERROR at line 1:
ORA-02065: illegal option for ALTER SYSTEM
sys@ORCL> alter system set db_recovery_file_dest_size=3900m scope=both;
System altered.
sys@ORCL> alter system set db_recovery_file_dest_size=4g scope=both;
System altered.
sys@ORCL> show parameter db_reco
NAME                                 TYPE        VALUE
db_recovery_file_dest                string      C:\Oracle\flash_recovery_area
db_recovery_file_dest_size           big integer 4G
sys@ORCL>

Flashback questions - particularly flashback table

Hi,
Oracle 10GR2
The docs state that flashback must be turned on in order to enable the functionality. Subsequently, a flashback logfile is started where designated. Now, for flashback table the docs also state that data comes from the UNDO iin order to restore. My first question is: What is kept in the flashback log and how does it fit in (given that the restore is done via UNDO)? The docs also state that if a flashback database is done that you should perform a resetlogs, but nothing is specified with respect to after a flashback table is done. I could see why you wouldn't want to but still wonder about the table that was flashed back and if it is in a vulnerable state.
I'm also interested in understanding the significance of flashback retention time vs undo_retention.
I guess I see some overlap here between the UNDO and FLASHBACK and want to understand the difference.
Thanks

Know that Flashback logs are not the only thing
stored in Flashback Recovery Area. Archived redo logs
and RMAN backups are also stored and they are used
for Flashback Table, Flashback Drop, Flashback
Versions Query, and Flashback Transaction Query
features.Hmm....this is news to me. Are you are sure about this????? Archived logs, backups are stored in the FRA, but it doesn't mean that they are used for Flashback table, Flashback drop, and FBQ or FTQ....
So yes, I would say, you need flashback on to
flashback a table.Again, NO, this is not required. You may like to review the facts associated with these technologies once again.
Thanks
Chandra

Disable logging completly- even for missing objects

Hi
i hav dev database that is generating millions of job failure/due to missing objects... is there away to disable the errors?
those jobs are scheduled thru dbms_schedule jobs have their logging level already set to "no logging ( off ) "
but i think oracle still geenrates eror when there is missing object ....

RnR wrote:
Hi,
Can you post exactly what error messages you are seeing and where ? Oracle does log job failures to the alert log even if logging is off. But if logging is off there shouldn't be any rows in the JOB_LOG or JOBRUN_DETAILS views.
One other thing to consider is that the job class that the job points to also has a logging level which specifies the minimum logging level that will be done for the job, so you may need to reduce the logging level of the job class as well.
Hope this helps,
Ravi.for example
ORA-12012: error on auto execute of job "DEV-SCHEMA1"."P_DELETE_Data"
ORA-06576: not a valid function or procedure name
looks like a job failing because its calling P_Delete_data which doesnt exist ... .. the job belongs to default job class and logging level set to "Log Job runs only (RUNS)" will end users notice if I change it to off ?
I only want to stop the logging in the db alert.log not in the job tables and views ... I still want them there so users can debug their jobs ...

Excessive flashback log generates with select statement

Hi everyone;
We have some extractions taken from a "flashback on" database.
Extractions are just select statements but when they are run, database produces excessive flashback logs.
What may be the reason database produce flashback logs with just select statements?
(It's certain that there are no insert-update-delete operations)
Version: 10.2.0.4.3
Thanks...

Do you do heavy update/delete before you select the statements ?
I am not very sure if delayed block cleanout also have the same effect on flashback logs but the output below is leading me to think that way
HR@ORACOS> select * from v$flashback_database_stat;
BEGIN_TIME        END_TIME          FLASHBACK_DATA    DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE
20100527 15:32:53 20100527 15:50:16      875266048 1207132160 2038729728                        0
20100527 14:32:50 20100527 15:32:53      248160256 127295488 450139648               1.3215E+10
20100527 13:32:48 20100527 14:32:50       10452992   15646720    4400640               1.5549E+10
20100527 12:32:43 20100527 13:32:48      745693184 948461568 1311620608               2.2789E+10
20100527 11:25:56 20100527 12:32:43     1262026752 1984741376 2358546432               2.7212E+10
HR@ORACOS> set autotrace traceonly statistics
HR@ORACOS> update base_table_np set y='INVALID';
commit;
4021808 rows updated.
Statistics
       2512 recursive calls
    8341430 db block gets
    4069140 consistent gets
     120569 physical reads
1908471980 redo size
        848 bytes sent via SQL*Net to client
        793 bytes received via SQL*Net from client
          3 SQL*Net roundtrips to/from client
          1 sorts (memory)
          0 sorts (disk)
    4021808 rows processed
HR@ORACOS> set autotrace off;
HR@ORACOS> select * from v$flashback_database_stat;
HR@ORACOS>
BEGIN_TIME        END_TIME          FLASHBACK_DATA    DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE
20100527 15:32:53 20100527 16:00:36     1236664320 2021974016 4019910656                        0
20100527 14:32:50 20100527 15:32:53      248160256 127295488 450139648               1.3215E+10
20100527 13:32:48 20100527 14:32:50       10452992   15646720    4400640               1.5549E+10
20100527 12:32:43 20100527 13:32:48      745693184 948461568 1311620608               2.2789E+10
20100527 11:25:56 20100527 12:32:43     1262026752 1984741376 2358546432               2.7212E+10
HR@ORACOS> set autotrace traceonly statistics
HR@ORACOS> select * from base_table_np;
4021808 rows selected.
Statistics
        139 recursive calls
          0 db block gets
      53908 consistent gets
       4404 physical reads
    1652384 redo size                                                  ------->delayed block cleanout effect
175008833 bytes sent via SQL*Net to client
      88996 bytes received via SQL*Net from client
       8045 SQL*Net roundtrips to/from client
          4 sorts (memory)
          0 sorts (disk)
    4021808 rows processed
HR@ORACOS> set autotrace off
HR@ORACOS> select * from v$flashback_database_stat;    ----flashback data size increases
HR@ORACOS>
BEGIN_TIME        END_TIME          FLASHBACK_DATA    DB_DATA REDO_DATA ESTIMATED_FLASHBACK_SIZE
20100527 15:32:53 20100527 16:01:11     1305264128 2054594560 4021728256                        0
20100527 14:32:50 20100527 15:32:53      248160256 127295488 450139648               1.3215E+10
20100527 13:32:48 20100527 14:32:50       10452992   15646720    4400640               1.5549E+10
20100527 12:32:43 20100527 13:32:48      745693184 948461568 1311620608               2.2789E+10
20100527 11:25:56 20100527 12:32:43     1262026752 1984741376 2358546432               2.7212E+10Basically what I do is I update a 4 million table big redo generated with flashback logs
When I do select after the update I still see the redo generated because of delayed block cleanout but what I also see is the slight increase in flashback data size (check the first row of flashback_database_stat) which suits what you asking for. Select statement generates flashback log
Tested on 11.2.0.1 with single active session on the db
Coskan Gundogar
Blog: http://coskan.wordpress.com
Twitter: http://www.twitter.com/coskan
Linkedin: http://uk.linkedin.com/in/coskan
---------

Should we use LOGGING or NOLOGGING for table, lob segment, and indexes?

We have some DML performance issue on cf contention over the tables that also include LOB segments. In this case, should we define LOGGING on tables, lob segments, and/or INDEXES?
Based on the metalink note < Performance Degradation as a Result of 'enq: CF - contention' [ID 1072417.1]> It looks we need to turn on logging for at least table and lob segment. What about the indexes?
Thanks!

>
These tables that have nologging are likely from the application team. Yes, we need to turn on the logging from nologging for tables and lob segments. What about the indexes?
>
Indexes only get modified when the underlying table is modified. When you need recovery you don't want to do things that can interfere with Oracle's ability to perform its normal recovery. For indexes there will never be loss of data that can't be recovered by rebuilding the index.
But use of NOLOGGING means that NO RECOVERY is possible. For production objects you should ALWAYS use LOGGING. And even for those use cases where use of NOLOGGING is appropriate for a table (loading a large amount of data into a staging table) the indexes are typically dropped (or at least disabled) before the load and then rebuilt afterward. When they are rebuilt NOLOGGING is used during the rebuild. Normal index operations will be logged anyway so for these 'offline' staging tables the setting for the indexes doesn't really matter. Still, as a rule of thumb you only use NOLOGGING during the specific load (for a table) or rebuild (for an index) and then you would ALTER the setting to LOGGING again.
This is from Tom Kyte in his AskTom blog from over 10 years ago and it still applies today.
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5280714813869
>
NO NO NO -- it does not make sense to leave objects in NOLOGGING mode in a production
instance!!!! it should be used CAREFULLY, and only in close coordination with the guys
responsible for doing backups -- every non-logged operation performed makes media
recovery for that segment IMPOSSIBLE until you back it up.
>
Use of NOLOGGING is a special-case operation. It is mainly used in Datawarehouse (OLAP systems) data processing during truncate-and-load operations on staging tables. Those are background or even offline operations and the tables are NOT accessible by end users; they are work tables used to prepare the data that will be merged to the production tables.
1. TRUNCATE a table
2. load the table with data
3. process the data in the table
In those operations the table load is seldom backed up and rarely needs recovery. So use of NOLOGGING enhances the performance of the data load and the data can be recovered, if necessary, from the source it was loaded from to begin with.
Use of NOLOGGING is rarely, if ever, used for OLTP systems since that data needs to be recovered.

Oracle not using space occupied by flashback logs

Hi,
oracle 10g R2 10.2.0.1 on RHEL 4 64-bits.
my db_flashback_retention_target is set to 1440 and my db_recover_file_dest_size is set to 40G.
flashback logs are occupying about 36G so whenever rman tries to backup the database, it breaks saying it cannot reclaim enough space from the 40G limit.
when checking the flashback logs,i saw that the DB is keeping 3 day old logs. should it not reclaim the space occupied by these logs and delete them?

Others have reported similar issues: http://www.wayneadamsconsulting.com/
>
One thing that I have not seen the database do, however, is delete reclaimable flashback logs in order to make room for a backup. If there is not enough free space in you FRA for a backup but there is plenty of space used by relcaimable flashback logs, RMAN and the database will not delete flashback logs to free up room in the FRA for the backup. This seems like a fairly large gap in the flashback log functionality, but hopefully Oracle will handle it in a future release.
>
See MOS note: Space issue in Flash Recovery Area( FRA ) [ID 829755.1] .
Note also that 10.2.0.1 is a old 10.2 release and that you could consider upgrading to 10.2.0.4.

Delete flashback log dynamically.

i want to delete flashback log dynamically.
suppose today is 1st feb while running shell script it will remove flashback log 31stjan ...
i have set retention policy 1 days.
following is the my sh script
=====================
#!/bin/sh
# Daily Backup
. oraenv.oratest
export NLS_DATE_FORMAT="Dy DD-Mon-YYYY HH24:MI:SS"
LOG_DIR="/var/log/oracle"
LOG_FILE="$LOG_DIR/$ORACLE_SID-daily-backup.log"
EMAIL_TO="[email protected]"
echo -e "\nBackup Commenced: " $(date) "\n"
pushd $HOME/rman
rman target / cmdfile="daily-backup.rman" log="$LOG_FILE" append
retcode=$?
if [ "$retcode" -ne "0" ]; then
echo -e "\n***\n*** BACKUP FAILURE: Database $ORACLE_SID on $HOSTNAME \n***"
mail -s "BACKUP FAILURE: Database $ORACLE_SID on $HOSTNAME" $EMAIL_TO < $LOG_FILE
exit 1
else
mail -s "INFO: Backup success: $ORACLE_SID on $HOSTNAME" $EMAIL_TO << EOF
Database $ORACLE_SID on $HOSTNAME backed up successfully.
EOF
fi
popd
echo -e "\nBackup Completed: " $(date) "\n"
rman script
run {
# Remove any obsolete files prior to backup
crosscheck backupset;
crosscheck copy;
delete noprompt obsolete;
delete noprompt expired backup;
delete noprompt expired copy;
# Incremental backup and update of current image copy
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA\$OEM_LEVEL_0';
delete noprompt obsolete;
delete noprompt expired backup;
delete noprompt expired copy;
backup incremental level 1 cumulative copies=1 for recover of copy with tag 'ORA\$OEM_LEVEL_0' database;
# Following backup - remove any now-obsolete files
delete noprompt obsolete;
delete noprompt expired backup;
delete noprompt expired copy;

RMAN cannot delete flashback logs, these are maintained automatically according to parameter 'db_flashback_retention_target'. Don't confuse FLASHBACK DATABASE with RMAN point-in-time recovery.
RMAN backups become obsolete as soon as no longer needed to meet the defined retention policy, 'delete obsolete' will never delete flashback logs.

Flashback Logs Location

Well, I am confused whether Oracle Flashback Technology uses Undo Tablespace or Flash Recovery Area. I was going through http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm, and the page mentions both Undo Tablespace and Flash Recovery Area.
Can someone please clarify.
Thanks

furqan_sindhu wrote:
Well, I am confused whether Oracle Flashback Technology uses Undo Tablespace or Flash Recovery Area. Completely wrong thought process. Oracle Flashback Technology is based on the Undo data which is stored Undo Tablespace. The Flash Recovery Area is nothing but a destination where the Flashback Logs are stored but they are used for a different purpose, which is for sending the complete database back into the past. So comparing both Flashback and FRA is actually a wrong thing to do.
I was going through http://www.oracle.com/technology/deploy/availability/htdocs/Flashback_Overview.htm, and the page mentions both Undo >Tablespace and Flash Recovery Area.
Read my reply above. Flashback is based on the Undo data which is not stored in the FRA but in the Undo tablespace. The FRA is used to store the backup files, archive files and a sepcial set of files called flashback logs (which I mentioned above) . Don't compare both and a suggestion, don't read white papers since they contain snippets of information only. Read oracle docs since they contain the complete stuff.
HTH
Aman....

Reduce flashback log - disable flashback for a table

Similar Messages

Maybe you are looking for