Rollback Segment: dedicate it to a given session ?

Dear Experts,
A job is performing nightly deletion on some data.
I created a "big" RBS for it and perform the following:
SET TRANSACTION USE ROLLBACK SEGMENT RBS01;
DELETE FROM TABLE1 WHERE (...);
COMMIT;
Is it possible that only this transaction uses RBS01 i.e. having RBS01 dedicated to my transaction untill the COMMIT is done ?
Thanks for any advice.
Best Regards,
Guillaume.

I've got a complementary question.
As I don't want the clean-up job to "eat" all my CPU I'd need to limit the CPU allocated to this task. I can see in Profile a CPU_PER_SESSION parameter but I'm looking for a way to set a max % of the CPU usage and not a max in duration. Any trick ?
Thanks for your support.
BR,
Guillau

Similar Messages

OCI setting rollback segment

When using OCI, how does not set which rollback segment to use?
The equiv PL/SQL stmt is "EXEC SQL set transaction use rollback segment BIGRBS2;"

Thanks for replying.
You mean mix Pro*C with OCI? How would it know that the pro*c set transaction goes with a given OCI session?
Or do you mean give the "set transaction" statement to the OCIStmtExecute method?

Forcing a specific rollback segment on a transaction does not seem to work

Hi!
We're using Oracle 9.2.0.5.0 on Sun Solaris and we're still configured to use Rollback Segments.
We have an issue with Snapshot too old due to RBS too small on a long query I attach below for reference:
set heading off
set pagesize 0
set feedback off
set linesize 200
<<<<< SET TRANSACTION USE ROLLBACK SEGMENT UMF_RBS_LARGE_TRAN; <<<<<
SELECT ucms_cards.msisdn
|| ';;' || to_char(to_date(substr(ucms_cards.notes,14+length(ucms_cards.msisdn),19),'MM-DD-YYYY.HH24-MI-SS'),'DD/MM/YYYY HH24:MI:SS')
|| ';;' || to_char(ucms_batches.expiry_date,'dd/mm/yyyy')
|| ';;' || ucms_cards.serial_no
|| ';;' || ucms_cards.serial_no
|| ';;' || ucms_cards.batch_serial_no
|| ';;' || ' '
|| ';;' || CASE ucms_cards.card_status
WHEN 'used' THEN '1'
ELSE '0'
END
|| ';;' || CASE WHEN date_booked_in is null THEN '01/01/1970 00:00:00' ELSE to_char(date_booked_in,'DD/MM/YYYY') || ' 00:00:00' END
|| ';;' || ' '
from ucms_batches,ucms_cards, UCMS_EVENT_LOG
WHERE ucms_cards.batch_serial_no = ucms_batches.serial_no
AND ucms_cards.serial_no = substr(UCMS_EVENT_LOG.ENTITY_ID,11,length(UCMS_EVENT_LOG.ENTITY_ID)-9)
AND UCMS_EVENT_LOG.PARTY_NO in (0)
AND UCMS_EVENT_LOG.TIMESTAMP>=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 00:00:01', 'DD-MM-YYYY HH24:MI:SS')
AND UCMS_EVENT_LOG.TIMESTAMP<=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 23:59:59', 'DD-MM-YYYY HH24:MI:SS')
AND UCMS_EVENT_LOG.USER_ID LIKE 'SCP-AGENT1%'
AND UCMS_EVENT_LOG.EVENT_TYPE_ID IN (1,2)
AND UCMS_EVENT_LOG.ENTITY_TYPE_ID LIKE 'ucms_cards%'
UNION
SELECT ucms_imported_cards.msisdn
|| ';;' || to_char(to_date(substr(ucms_imported_cards.notes,14+length(ucms_imported_cards.msisdn),19),'MM-DD-YYYY.HH24-MI-SS'),'DD/MM/YYYY H24:MI:SS')
|| ';;' || to_char(ucms_imported_cards.expiry_date,'dd/mm/yyyy')
|| ';;' || ucms_imported_cards.serial_no
|| ';;' || ucms_imported_cards.serial_no
|| ';;' || DBMS_UTILITY.GET_HASH_VALUE(ucms_imported_cards.card_type,1,65536)
|| ';;' || ' '
|| ';;' || CASE ucms_imported_cards.card_status
WHEN 'used' THEN '1'
ELSE '0'
END
|| ';;' || '01/01/1970 00:00:00'
|| ';;' || ' '
from ucms_imported_cards, UCMS_EVENT_LOG
where ucms_imported_cards.serial_no = substr(UCMS_EVENT_LOG.ENTITY_ID,11,length(UCMS_EVENT_LOG.ENTITY_ID)-9)
AND UCMS_EVENT_LOG.PARTY_NO in (0)
AND UCMS_EVENT_LOG.TIMESTAMP>=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 00:00:01', 'DD-MM-YYYY HH24:MI:SS')
AND UCMS_EVENT_LOG.TIMESTAMP<=TO_TIMESTAMP(TO_CHAR(SYSDATE-1, 'DD-MM-YYYY') || ' 23:59:59', 'DD-MM-YYYY HH24:MI:SS')
AND UCMS_EVENT_LOG.USER_ID LIKE 'SCP-AGENT1%'
AND UCMS_EVENT_LOG.EVENT_TYPE_ID LIKE '2%'
AND UCMS_EVENT_LOG.ENTITY_TYPE_ID LIKE 'ucms_imported_cards%';
As you see we forced the session to use a huge RBS created for the purpose, but strangely after a long while the query fails with a RBS too small failure due to another RBS, not the one specified.
Is there any chance the UNION or any other component of the query is implicitly opening a new transaction with a different RBS associated?
Any chance to force the same RBS specified explicitly?
Thanks!
Mike

albertone wrote:
but strangely after a long while the query fails with a RBS too small failure due to another RBS, not the one specified.You misunderstand snapshot too old. It can be caused by other sessions same as by your session. Assume AFTER your session issued select some other session modified one (or more) tables ucms_batches, ucms_cards, UCMS_EVENT_LOG and committed changes. By the time your select reaches to fetch rows modified by that other session rollback extents in rollback segment used by that other session were reused. You will get snapshot too old. Bottom line - all sessions modifying table(s) used by your select must use rollback segments large enough so they are not overwritten before corresponding rows are needed by your select.
SY.

Error while creating the rollback segment (Oracle 8i & OS Win NT)

hi
I am using Oracle 8i and when i am creating the new rollback segment for my database i have got following error message
ORA-01593 Rollback segment optimal size (30 blks) is smaller than the computed initial size (2560 blks)
CREATE ROLLBACK SEGMENT "RBS11" TABLESPACE "RBS1"
STORAGE ( INITIAL 120K NEXT
120K OPTIMAL
240K MINEXTENTS 2
MAXEXTENTS 100)
Note:- db_block size is 8k
Tablespace RBS1 is the Locally managed Tablespace having datafile of 50m and uniform size of 10m
But Given statement processed while i am using Tablespace RBS (winch is data dictionary managed)
Plz, suggest me to cause of that error and solution

You said 120K optimal and initial is 120K with minextents of 2. The optimal size then will be smaller than the initial allocation for the rbs.
ORA-01593: rollback segment optimal size (string blks) is smaller than the computed initial size (string blks)
Cause: Specified OPTIMAL size is smaller than the cumulative size of the initial extents during create rollback segment.
Action: Specify a larger OPTIMAL size.

Rollback segment problem

Hello:
I'm using oracle 8 database and I have a process that generates small transactions (and they're really small), usually this process is executed from 2 or 3 different workstations at the same time, but they don't use the same data sets. The frequency of execution of the small transaction is 10 or 12 a second for each workstation. Each time the process is executed I can count near 6000 transactions, and I always have 2 o 3 of them arising "ORA-01562: failed to extend rollback segment number n" error. Since the transaction uses a small space of the rollback segment I can't find an explanation to this behavior. Is this related to the time between transaction and the freeing of the unused rollback segment ? I would really appreciate if somebody could help me!!!
Thanks in advance, Javier Petrozzi

It appears to me that some of the transactions remain open for quite some time and the new transactions are not able to obtain an extent for the rollback segment.
The following query gives some useful information.
1 select s.sid, s.username, r.name "SEGMENT NAME"
2 from v$session s, v$transaction t, v$rollname r
3 where s.taddr=t.addr
4* and t.xidusn = r.usn
SQL> /
SID USERNAME SEGMENT NAME
16 SCOTT _SYSSMU7$You may have to commit your changes sooner.

Is "SET TRANSACTION USE ROLLBACK SEGMENT" only a hint

I have two users, one makes some inserts in a table.
The other makes a select which visits many rows.
I have a big rollback-segment.
To ensure, both users use this rollback-segment I created a logon-trigger:
CREATE OR REPLACE TRIGGER a_logon AFTER LOGON
ON DATABASE
WHEN ( USER IN ( 'SCOTT', 'BOB' ) )
BEGIN
SET TRANSACTION USE ROLLBACK SEGMENT rbs_big;
END;
But I still get "snapshot to old" messages from the select, which contains the name off an other rollback-segment in the message.
The trigger really fires, i tested it by adding an insert-statement to a log-table.
What`s wrong ?

The set transaction use rollback segment lasts only until you commit or rollback first time and all other transactions in that session will not be forced to that rbs anymore. Other possible solution could be that other users are accessing same tables / updating them so those sessions can't keep the read consistent image available anymore for your sessions.

How can I avoid using rollback segment for batch updates.

I am currently trying to avoid associating a large amount of space for rollback segment as this gets filled up only during the nightly batch updates. All that space will never be used during the day. Hence want to know if there is any way of avoiding the use of rollback segment at the session level.
Rajesh

No, but what you can do is create a large rollback segment to use with your batch job, at the start of your batch job bring the segment online, then use set transaction to use that rollback segment, when the batch job is finished and committed, you can then bring the rollback segment offline.
If you are really pressed for space, as an alternate plan, you could actually create the large segment before the batch job and drop it after.

How to Create Exclusive Rollback Segment

How can we create exclsive rollback segment for a particular
session,
Even setting "set transaction use rollback segment
rollack_segment"
still other session can step on newly created rollback segment

Hi Santanu,
The steps that you mentioned are in sequence. You also need to check if user exist for this requirement.
sap help can give u a good deal of information.

ORA-01581: attempt to use rollback segment...

We've started getting "ORA-01581: attempt to use rollback segment (31) new extent (3) which is being allocated" messages in our production database over the last couple of days. Of course, each time we get these the rollback segment number is different, and we are getting these randomly from different applications that connect to the same database. We are using automatic undo management, so the rollback segments are not really under our control. The action in the Oracle docs for this error message doesn't give any specific actions that we should take, but we continue to get these.
We started to get these about the same time as we ran out of available sessions on the database (sessions = 1500 and we had 1500 open sessions). Could these be related? Could there be some open session that may be causing the rollback segment issue? Would a restart of the database fix this? Of course the max sessions issue was cleaned up two days ago but the rollback segment issue is a lingering problem.
Any help would be appreciated. We couldn't find anything for this online and Oracle hasn't responded to our service request yet.
Thanks,
Bobby

As I understand it, you can not explicitly set the size for the undo segments in automatic undo management mode. From the Concepts guide:
"In automatic undo management mode, the system controls exclusively the assignment of transactions to undo segments, and controls space allocation for undo segments."
It looks like we are also using the default storage options that are set when the UNDO tablespace was created. Here is the DDL used to create this tablespace:
CREATE SMALLFILE UNDO TABLESPACE "UNDOTBS" DATAFILE '/alpha/oradata/prod01/undotbs01.dbf' SIZE 750M REUSE AUTOEXTEND ON NEXT 25600K MAXSIZE 2000M , '/alpha/oradata/prod01/undotbs03.dbf' SIZE 2000M REUSE AUTOEXTEND ON NEXT 51200K MAXSIZE 2000M , '/alpha/oradata/prod01/undotbs04.dbf' SIZE 2000M REUSE AUTOEXTEND ON NEXT 104K MAXSIZE 2000M , '/alpha/oradata/prod01/undotbs02.dbf' SIZE 2000M REUSE AUTOEXTEND ON NEXT 25600K MAXSIZE 2000M

Error:cannot use system rollback segment for non-system tablespace

Hi,
I have created a oracle database 10.2.0 on fedora 9 system. I have created a user and assigned the default tablespace SATYA and given the permissions. But when I create a table in the user I am getting the following error.
Can anyone help me in rectifying this error.
ORA-01552: cannot use system rollback segment for non-system tablespace 'SATYA'
thankyou
satya

Undo management is either AUTO or Manual, no local
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/undo.htm#sthref1469
Since you are using 10g, you are recommended to use Auto undo management
If you still plan to use manual undo management, make sure you have other non-system rollback segment in place.

ROLLBACK segments are not deallocated

Hi,
on 8i, Win 2003 the Roll back tablespace is not deallocated and enlarge since it is in Autoextend.
1-How can we see which query or application occupies RollBack segment ?
2-How to see why it is not deallocated ?
Many thanks before.

1 You need to look at v$transaction. V$session points to v$transaction by means of the column taddr.
2 extents of rollback segments are not allocated ever, by design. Deallocating an extent is costly, also it increases the chance you run into ora-1555.
IIRC 8i is desupported for quite some time, and not certified on Win2003.
Sybrand Bakker
Senior Oracle DBA

GettingTransaction in a specific Rollback segment

          Hi
          I m using bea weblogic 6.0. as Application Server and Oracle 8.x as Database.
          I get user transaction from weblogic server by looking up ("javax.transaction.UserTransaction")
          Now my requirement is that i want to begin transaction with a particular rollback
          segment. ( oracle
          allows this ) but UserTransaction object that we get from weblogic has only one
          method .begin()
          In this case is it possible for me to get usertransaction and begin transaction
          in a particular rollback
          segment.
          Thanks
          Pranav


albertone wrote:
but strangely after a long while the query fails with a RBS too small failure due to another RBS, not the one specified.You misunderstand snapshot too old. It can be caused by other sessions same as by your session. Assume AFTER your session issued select some other session modified one (or more) tables ucms_batches, ucms_cards, UCMS_EVENT_LOG and committed changes. By the time your select reaches to fetch rows modified by that other session rollback extents in rollback segment used by that other session were reused. You will get snapshot too old. Bottom line - all sessions modifying table(s) used by your select must use rollback segments large enough so they are not overwritten before corresponding rows are needed by your select.
SY.

ROLLBACK SEGMENT의 MINEXTENTS를 20 이상으로 하면 좋은 이유

제품 : ORACLE SERVER
작성날짜 : 2003-06-19
ROLLBACK SEGMENT의 MINEXTENTS를 20 이상으로 하면 좋은 이유
=========================================================
PURPOSE
이 자료는 다음과 같은 주제에 대하여 소개하는 자료이다.
이 문서는 database application의 요구 사항을 충족시키기 위해 고려되어
져야 할 rollback segment tablespace 구성에 관한 내용을 담고 있다.
Creating, Optimizing, and Understanding Rollback Segments
-Rollback Segment 구성과 기록 방식
-Transaction에 Rollback Segment를 할당하는 Oracle 내부 메커니즘
-Rollback Segment 크기와 갯수
-Rollback Segment의 크기와 갯수 결정을 위한 테스트
-Rollback Segment extent의 크기와 갯수
-Rollback Segment의 minextents를 20 이상으로 하면 좋은 이유?
-Rollback Segment의 Optimal storage parameter와 Shrink
Explanation
Rollback Segment 구성과 기록 방식
Rollback segment는 extent라 불리는 연속적인 여러 개의 block으로 구성된다.
Rollback segment는 ordered circular 방식으로 extent를 쓰게 되는데,
current extent가 full이 되면 next extent로 옮겨 가며 사용하게 된다.
Transaction은 rollback segment 내의 current location에 record를 쓴 다음,
record의 size 만큼 current pointer를 옮겨 간다.
Rollback segment에 현재 record가 쓰여지고 있는 위치를 "Head"라고 한다.
또한, "Tail"이란 용어는 rollback segment에서 가장 오래된 active
transaction record의 시작 위치가 되는 부분을 말한다.
Transaction에 Rollback Segment를 할당하는 Oracle 내부 메커니즘
새로운 transaction이 rollback segment 를 요청하면, 각 rollback segment
를 이용하고 있는 active transaction 갯수를 확인하여 가장 적은 갯수의
active transaction 을 가진 rollback segment를 할당하게 된다.
Rollback segment는 transaction load를 처리하기에 충분한 크기를 가져야
하고, 필요한 만큼의 rollback segment를 사용할 수 있도록 적당한 갯수의
rollback segment를 가져야 한다.
1. 한 transaction은 단 하나의 rollback segment만을 사용할 수 있다.
2. 같은 extent에 여러 transaction이 기록할 수 있다.
3. Rollback segment의 Head는 Tail에 의해 현재 사용 중인 extent를
침범하지 않는다.
4. 링 형태로 구성되어 있는 rollback segment의 extent들은 다음 extent를
찾을 때 절대 건너 뛰는 일이 없으며, 순서를 뒤바꾸어 사용하지도 않는다.
5. Head가 next extent를 찾지 못하면, 새로운 extent를 추가로 할당하고,
그 extent를 링 안에 포함시킨다.
위와 같은 원리를 감안할 때, transaction size 뿐만 아니라 transaction
time도 상당히 중요한 고려 사항이라는 것을 알 수 있다.
Rollback Segment 크기와 갯수
Rollback segment size가 충분한지 판단하는 기준은 transaction activity에
직접적으로 영향을 받는다. 주로 일어나는 transaction activity에 근거하여
rollback segment size를 결정하여야 하고, 잘 일어나지 않는 특수한 경우의
큰 transaction이 문제라면 별도의 rollback segment로 관리되어야 한다.
Transaction 발생 중 Head가 너무 빨리 wrap around 시켜서 tail을 catch하
지 않도록 하여야 하며, 자주 변경되는 data에 대해 long-running query가
수행되었을 경우 read-consistency가 유지될 수 있도록 rollback segment
가 wrap around되지 않아야 한다.
Rollback segment 갯수를 적당히 잡아야 하는 이유는 process들 간에
contention을 방지하기 위함이고, V$WAITSTAT, V$ROLLSTAT, V$ROLLNAME
view를 통해서 contention을 확인할 수 있으며, 조회문은 다음과 같다.
sqlplus system/manager
select rn.name, (rs.waits/rs.gets) rbs_header_wait_ratio
from v$rollstat rs, v$rollname rn
where rs.usn = rn.usn
order by 1;
위의 query에 의해 조회된 rbs_header_wait_ratio 가 0.01 보다 크면,
rollback segment 갯수를 추가한다.
Rollback Segment의 크기와 갯수 결정을 위한 테스트
1. Rollback segment tablespace 생성
2. 테스트하기 위해 생성할 Rollback segment 갯수 결정
3. 같은 크기의 extent로 rollback segment 생성
extent 갯수는 최대 확장 시 10 - 30 개 정도가 되도록 extent 크기를 결정
4. Rollback segment의 minextents는 2이다.
5. 테스트할 rollback segment와 system rollback segment만 online 상태로 한다.
6. Transaction을 수행하고, 필요하면 application을 load한다.
7. Rollback segment contention을 확인한다.
8. Rollback segment가 최대 얼마까지 확장하는지 모니터링한다.
Rollback Segment extent의 크기와 갯수
Rollback segment가 자라나는 최대 사이즈를 알 수 있는데, 이 수치를
"minimum coverage size"라 한다. 만약, contention이 발생한다면 rollback
segment 갯수를 늘려 가면 테스트를 반복한다. 또한, extent 갯수가 10개
미만이나 30개 이상이 될 필요가 있다면 extent 크기를 늘리거나 줄이면서
테스트를 반복해 나가면 된다.
Rollback segment의 extent 크기를 정할 때, 각 extent는 모두 같은 크기로
생성할 것을 recommend한다.
Rollback tablespace의 크기는 extent size의 배수로 지정한다.
최적의 성능을 위한 rollback segment의 minextents는 20 이상이어야 한다.
Rollback Segment의 minextents를 20 이상으로 하면 좋은 이유?
Rollback segment는 dynamic하게 allocate되고, 더 이상 필요 없게 되었을 때
(만약, Optimal parameter가 셋팅되어 있으면) 모두 commit된 extent에
대해서는 optimal size 만큼만 남기고 release(deallocate)된다.
Rollback segment가 적은 수의 extent를 가질 수록, space 할당/해제 시
extent 수가 많을 때보다 큰 사이즈의 space가 할당되고, 해제된다.
다음과 같은 예를 들어 보자.
200M 정도의 rollback segment가 있는데, 100M 짜리 2개의 extent로 이루어져
있다고 가정해보자. 이 rollback segment에 추가로 space를 할당해야 할 일이
생겼을 때, 모든 rollback segment extent는 같은 크기를 가져야 한다는 점을
감안할 때, 100M 짜리 extent를 하나 더 할당해야 할 것이다.
이 결과 직전의 rollback segment 크기에 비하여 50% 만큼의 크기 증가분이
생겨나게 된 것인데, 실제 필요로 하는 space보다 더 많은 space가 할당되었을
것이다.
이와 반대로, 10M 짜리 extent 20개로 구성된 200M 짜리 rollback segment를
생각해보자.
여기에 추가로 space를 할당해야 할 일이 생겼을 때, 10M 짜리 extent 하나만
추가되면 되는 것이다.
Rollback segment가 20개 또는 그 이상의 extent로 구성되어 있다면 extent가
하나 더 증가할 경우가 생겼을 때, rollback segment의 전체 크기가 5% 이상은
늘어나지 않는다는 것이다.
즉, space의 할당과 해제 작업이 보다 유연하고 쉽게 일어날 수 있다.
요약하면, rollback segment의 extent 갯수를 20 이상으로 잡으면 space
할당과 해제가 "보다" 수월해진다.
실제로 extent 갯수를 20 이상으로 잡았을 때, 처리 속도가 훨씬 빨라진다는
사실이 많은 테스트 결과 밝혀졌다.
한가지 확실한 사실은, space를 할당하고 해제하는 작업은 cost가 적게 드는
작업이 아니라는 사실이다.
실제로 extent가 할당/해제되는 작업이 일어날 때, performance가 저하되는
일이 발생한다는 것이다.
Extent 하나에 대한 cost는 별 문제가 안 된다고 할지라도, rollback segment
는 끊임없이 space를 할당하고 해제하는 작업을 반복하기 때문에 작은 크기의
extent를 갖는 것이 cost 측면에서 훨씬 효율적이라는 결론이다.
Rollback Segment의 Optimal storage parameter와 Shrink
Optimal은 deallocate 시에 rollback segment 내에 optimal size 만큼의
extents를 유지하기 위해 사용하는 rollback segment storage parameter이다.
다음과 같은 명령으로 사용한다.
alter rollback segment r01 storage (optimal 1m);Optimal size는 storage 절 안에서 기술되어야 한다.
Optimal size 이상이 되면, 모두 commit된 extent에 대해서는 optimal size
만큼만 남기고 release된다.
즉, optimal에서 지정한 크기 만큼만 rollback segment를 유지하겠다는
뜻이며, 일정한 크기로 늘어났다가 다음번 tx이 해당 rbs를 취할 경우
optimal size만큼 resize하는 option이다.
rbs의 가장 최근에 사용된 extent가 다 차서 다른 extent를 요구할 때
이 optimal size와 rbs size를 비교하게 되며, 만약 rbs size가 더 크다면
active tx에 관여하지 않는 tail extent에 대하여 deallocation이 이루어진다.
특정 rollback segment가 너무 큰 space를 차지해서 다른 rollback segment가
extent를 발생할 수 있는 여유 공간을 부족하게 만들기 때문에 이를 극복하기
위해서 optimal size를 지정할 필요가 있다.
즉, optimal parameter를 지정하면 space availability 측면에서 효율적이다.
다음과 같이 shrink 명령을 수행하는데, size를 지정하지 않으면 optimal
size 만큼 shrink된다.
alter rollback segment [rbs_name] shrink to [size];Shrink 명령 수행 후, 바로 줄어들지 않는 경우가 있는데,
transaction이 있는 경우는 줄어들지 않고, transaction이 종료되면 줄어든다.
Optimal이 적용되는 시간은 session이 빠져 나가고 약 5~10 분 정도 걸린다.
적당한 OPTIMAL SIZE?
=> 20 ~ 30 extents 정도가 적당한데, batch job의 성격에 따라 size는 달라
지며 각 optimal의 합이 datafile의 size를 넘어도 전혀 상관없다.
Optimal size를 initial, next와 같게 주면 extent가 발생하는 매번 shrink가
일어나므로 좋지 않다.
RBS들의 평균 크기를 구하여 이것을 optimal 크기로 지정하여 사용하는 것을
권한다.
다음의 query를 이용하여 peak time에 rollback segment들의 평균 크기를 구한다.
select initial_extent + next_extent * (extents-1) "Rollback_size", extents
from dba_segments
where segment_type ='ROLLBACK';
이 크기의 평균값(bytes)을 rollback segment들의 optimal size로 사용할 수
있다.
주의할 사항은 너무 자주 shrink된다거나 optimal 값을 너무 작게 주면
ora-1555 : snapshot too old error가 발생할 확률이 높아지므로,
사용하지 않는 것이 좋을 수도 있고, 되도록 큰 값으로 셋팅해야 한다.
Rollback segment의 optimal size를 확인할 수 있는 view는 V$ROLLSTAT
이라는 dynamic view로서 OPTSIZE column에서 확인이 가능하다.
Example
none
Reference Documents
<Note:69464.1>

Sql to find check Percent of Rollback Segment Used?

I have the following queries to find information about rollback segments.
I want the sql to find % of rollback segment used.
--rollsegs.sql
select SEGMENT_NAME, OWNER, TABLESPACE_NAME, SEGMENT_ID, status
from dba_rollback_segs order by segment_name;
select name, extents, writes, xacts, gets,waits, shrinks, aveactive, status
from v$rollname n, v$rollstat s
where n.usn = s.usn
order by name;
--rolbstat.sql
select name, rssize, hwmsize "High", optsize "Opt", wraps, extends, shrinks,
aveshrink "Aveshr", aveactive "Aveact"
from v$rollname n, v$rollstat s
where n.usn = s.usn
order by name;
set numformat 999999990;

DrBurgs, there was a time when your session was assigned a rollback segment that rollback segment held all the updates performed by your session but by Oracle version 8.1 every transaction executed by your session could be assigned to a different rollback segment.
So every 100,000 or whatever value of N use choose as your commit point could result in a different rollback segment being used. You can use v$rollstat and v$transaction to monitor rollback segment usage while the job is running.
You stated that you had one rollback segment for every tablespace. There is no relation in Oracle between the number of tablespace and the number of rollback segments you should have.
You should choose the number of rollback segments to create based on the expected user load and how large a transaction you need to be able to support. For manually defined rollback segments set the initial extent size and the next extent size equal with pctincrease = 0. Then set optimal to the size you would like each rollback segment to be. This size should be large enough that shrinks do not happen often but small enough that one segment that expands will not result in other rollback segments being able to extend. By using uniform extent size you guarentee that every free extent is usable by any other rollback segment that needs to extend.
With a true warehouse you probably have very little update compared to your select load and the updates are probably load jobs. In this case you may need very few, very large rollback segments to handle the load.
HTH -- Mark D Powell --

Persistent Rollback Segment Header Lockouts (8.1.6)

We are encountering the following situation on a 3-tier production system:
Users occasionally inadvertently disconnected from client tier while a long-standing transaction (individual inserts controlled manually) has not yet been committed. (client cannot rejoin the severred session, by the way).
At the point of disconnection, users often appear to be holding a rollback segment header enqueue.
Subsequently, other users are getting locked out by this enqueue as they go for a transaction.
We have 400 active users, and 80 rollback segments (ie. 5 potential transactions per segment). Each RBS is split into an minimum of 16 extents.
My question:
I have been led to believe by Oracle documentation that rollback seg. header locks are only held v. briefly. If this were so, the chances of this situation occurring would be slim. However, we observe this situation occurring daily.
Yes I can up the number of RBS, but is there some other action I could be taking ? - indeed upping the RBS count may have no appreciable impact on this situation at all !

Hi,
Generally "Snapshot too old " error occurs when your rollback segment has not enough space for keeping your undo information. If you still facing that problem even after assigning a big tablespace, means your transaction is taking so much space. You can try to assign some more space in tablespace where you ahve created rollback segment. Have you assigned the tablespace using the same syntax
SET TRANSACTION USE ROLLBACK SEGMENT large_rs1;
For getting more information on this pls go through the following link
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96521/undo.htm#9114
Please let me know if you have any other issue.
Thanks

Rollback Segment: dedicate it to a given session ?

Similar Messages

Maybe you are looking for