Intão, os segmentos são um pouco mais que simples "divisões" lógicas,
eles tem um papel físico também. Antes de falar sobre isso, de cara já
aviso que o que segue é mais conhecimento acadêmico do que qquer
outra coisa, a Oracle desencoraja e recomenda contra o controle manual
de undo nas versões mais recentes de banco, e é o que é praxe, então
só mesmo num exercício teórico (como o é o OCP), ou num eventual caso
de banco enorme e ultra-ativo é que vc vai precisa disso . Por causa
disso também a documentação atual fala muito pouco deles, ela os
considera como um mecanismo interno que deveria ser controlado
internamente pelo banco, para referência eu indico docs antigos, como
as notas metalink "General Overview of Rollback Segments", doc
id=1011108.6 e "Creating, Optimizing, and Understanding Rollback
Segments", doc id=62005.1 .
Bem, vamos lá : creio que vc já sabe, mas o conceito básico de
consistência no bd Oracle é que para poder ser alterado
necessariamente o dado foi lido pro cache, e o que é liudo é o BLOCO
inteiro aonde o dado reside. Quando há a alteração, é feita uma CÓPIA
desse bloco antes da alteração , que é o UNDO (ou também chamado de
ROLLBACK). Ora, um bloco é bem pequeno, então vc normalmente tem **
montes ** deles, se o banco fosse ter uma lista de blocos de undo ia
ser enrome, além do que ia exigir montes e montes de I/Os
pequeninos,então ele ** agrupa ** isso num EXTENT, que é uma série de
blocos contíguos, aí esse I/O todo pode ser feito duma vez só. O
conjunto de extents de undo em uso é o chamado rollback segment. Notar
que cada transação só pode acessar um único rollback segment durante a
sua vida, MAS um rollback segment pode atender várias transações, um
extent por vez. Suponha que exista um segmento de rollback R1 online
numa dada tablespace, uma transação T1 inicia-se, ela aloca um extent
E1 nesse segmento, essa transação enquanto durar só poderá pedir por
mais extents nesse segmento R1. Se logo após uma transação T2 inicia,
ela pode alocar um extent E2 nesse mesmo segmento (e daí pra frente só
poderá pedir por mais extents nesse segmento), assim por diante.
Então, logicamente falando, em tese eu poderia ter só um único
segmento de rollback atendendo todo mundo ? Até poderia, mas :
- há limite na qtdade máxima de extents que um segmento pode ter
(bem alto nos releases mais recentes, mas há)
- há estruturas de controle no cabeçalho (header) dum segmento, cada
transação interessada em o usar/continuar usando um segmento precisa
aplicar/esperar por latches nesses caras
==> então poderia haver forte CONTENÇÃO (competição pela chance de
usar) se houvesse um só segmento, além da questão de limites de
extents. Assim, se deve trabalhar em esquema de round-robin, ie : vc
cria alguns segmentos de rollback, a primeira transação T1 vê que o
segmento R1 tá livre e aloca um extent nele, a T2 aloca extent no
segmento R2, assim por diante, até chegar um momento em que não há
segmentos livres, aí a transação Tn aloca um extent do R1, Tn+1 do R2,
aí vai. Com isso vc DIMINUI a taxa de interessados num único segmento,
portanto diminui a concorrência, essa é a idéia.
Aí vem as suas perguntas :
- qual o tamanho adequado pra extents dum segmento de rollback :
tem que ser um tamanho nem muito grande (pois se não uma transação que
altere poucos bytes vai causar um tamanhão de I/O), nem muito pequeno
senão sub-utiliza o hardware de I/O, normalmente 1 Mb é considerado
razoável
- qtdade de segmentos : tem que ser uma qtdade tal que não "force"
muitas transações a quererem usar o mesmo segmento ao mesmo tempo, mas
também não desperdice muito espaço em disco, normalmente se ter umas 3
ou 4 transações ativas pra cada segmento de rollback é ok.
==> essas recomendações vêm da aplicação do citado em
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:275215756923
, mas na época de rollback manual a gente tinha mesmo que fazer os
testes cfrme o link cita.
- quando vc seta undo_management para AUTO, o que ele faz é ir
criando/removendo/colocando ONLINE e OFFLINE os segmentos de rollback
conforme as transações vão chegando, ok ? Então SIM, a partir do
momento que vc desliga a feature com undo_management=MANUAL, fica POR
SUA CONTA não só criar como ativar/colocar ONLINE os segmentos, então
é natural que se vc não o fez levou erro....
- o erro da msg em questão : quando vc cria o banco de dados por
conta própria ele cria um segmento de rollback especial, chamado
SYSTEM, na tablespace de sistema também chamada SYSTEM : esse cara
porém só pode ser usada para as transações *** INTERNAS ***, feitas
nas tabelas INTERNAS do banco por ele próprio, se vc não tiver
segmentos de rollback de usuário criados, no caso de transação em
tabelas não-internas o banco vai olhar, só achará o SYSTEM, esse é
RESERVADO, pumba, levas o erro em questão, ok ? É como eu falei, a
partir do momento que vc desativa o undo automático, fica POR SUA
CONTA criar segmentos, os ter online, os ter offline quando não
estiverem sendo usados, definir o tamanho de extent, etc....
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "rei_do_delphi"
<[EMAIL PROTECTED]> escreveu
>
> Chiappa e Companhia, boa tarde,
> Gostaria de entender um conceito importante no Db Oracle. Estava
> lendo um material da sybex sobre Oracle e no capítulo de
> gerenciamento de undo, fui fazendo os exercícios. A versão do Oracle
> é a 10.2.0.1.0 - 64 bits, rodando em um Centos 5.0 64 bits por
> vmware. Quando alterei o parâmetro undo_management para manual (
> utilizando spfile) e iniciei novamente a instance, recebi o erro:
> ORA-01552: cannot use system rollback segment for non-system
> tablespace 'yyy' ao tentar fazer um update na base. Aí, voltei o
> parâmetro para auto e reiniciei a instância e tentei efetuar o mesmo
> update e ele deu certo. Voltei o parâmetro para o manual e voltou a
> dar o mesmo erro ( p.s: parâmetro undo_tablespace setado para uma
> tablespace de UNDO corretamente e undo_retention=900, para guardar
> por 15 minutos). aí dando uma olhada a mais no material que possuo,
> eu vi que aparentemente( digo isso, pois ainda não entendi o conceito
> de "segmento de rollback") "segmento de rollback" é como se fosse
> divisórias na tablespace de undo? Este erro me ocorreu porque? Quando
> consultei a v$undotbs ele havia me retornado que os segmentos de
> rollback estavam na system, seria por isso que estava dando o erro
> então?
> criei então um novo segmento de rollback através do dbconsole ( pois
> não conhecia esse conceito até então):
> create rollback segment "rollbs2" tablespace "undotbs1" storage (
> inicial 1M next 5M)/
> alter rollback segment "rollbs2" online;
>
> pelo que entendi, este comando me criou um "novo" segmento de
> rollback e o ativou em seguida correto?
>
> sendo assim, minhas perguntas são:
> O que é segmento de rollback? é como eu "presumi" agora pouco como
> sendo divisórias na tablespace de undo?
> quando o tamanho que devo definir em initial, next e optimal size ?
> é possível ter mais que 1 segmento de undo?
> Obrigado.
>
