Re: flashback traffic still getting generated after 'alter tablespace flashback off'
- From: Dan Peacock <danp@xxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 28 Dec 2010 10:07:18 -0500
Not at the moment.
select * from v$restore_point
SCN DATABASE_INCARNATION#
GUARANTEE_FLASHBACK_DATABASE STORAGE_SIZE
TIME RESTORE_POINT_TIME PRESERVED NAME
---------------------- ----------------------
---------------------------- ----------------------
------------------------- ------------------------- ---------
--------------------------------------------------------------------------------------------------------------------------------
On 12/28/2010 10:02 AM, Don Seiler wrote:
Do you have any guaranteed restore points? Those will also cause
flashback logs to be generated and will continue to fill the FRA until
the restore points are dropped.
Don.
On Tue, Dec 28, 2010 at 8:56 AM, Dan Peacock <danp@xxxxxxxxxxxxx
<mailto:danp@xxxxxxxxxxxxx>> wrote:
I may be misunderstanding something here, but I was under the
impression based on what I've read that if you want to exclude
objects from being flashbackable then you would put them in a
tablespace that has that has that turned off. I've got two tables
that I pull from another source each day that I don't care if I
can flash them back to a prior state, so I want to reduce the load
on the flahsback area an exclude them. To test this out, I
created a tablespace in one of my test instances that had the
flashback setting turned off (i.e., ALTER TABLESPACE MMEY_NOFLASH
FLASHBACK OFF). When I moved the table in question, the amount of
space in the flashback area didn't change (it's a 2.5GB table), so
I figured I was golden. However, I'm running the process that
processes the changes (I insert new records and delete and readd
changed records) and I'm experiencing the same level of flashback
file generation that I am seeing on the flashbackable table in
production. What gives? What am I missing?
Database version = 11.2.0.1 (with a few interim patches applied)
OS version = Linux RHEL 64-bit
--
Dan Peacock
Enterprise Data Architect
Auto-wares, Inc.
danp@xxxxxxxxxxxxx <mailto:danp@xxxxxxxxxxxxx>
Dare something great
--
//www.freelists.org/webpage/oracle-l
--
Don Seiler
http://www.seiler.us
--
Dan Peacock
Enterprise Data Architect
Auto-wares, Inc.
danp@xxxxxxxxxxxxx
Dare something great
Other related posts:
