Chiapa,
Obrigado desde já pelas explanações todas, mas mesmo assim ainda não
consegui alterar a bendita tabela.
Outra opção que pensei, seria criar o campo na tabela sem valor default e
not null....gradativamente eu iria fazendo update nos registros até conseguir
colocar todos com um valor apropriado. No momento em que todos os
registros estivessem com valor, eu alteraria o campo da tabela para not null+
valor default, no caso 0 (zero).
Um alter table, depois que estiver tudo com valor acertado, via update, será
bem mais rápido, não será???
Tks
Sérgio
----- Original Message -----
From: jlchiappa
To: oracle_br@yahoogrupos.com.br
Sent: Friday, November 30, 2007 3:50 PM
Subject: [oracle_br] Re: Dúvida
Ah, alguns detalhes importantes :
1. vc diz que fez "alter system enable restricted" : alguns jobs (como
por exemplo os jobs de propagação via streams, entre outros, como é
dito no manual "Oracle® Streams Concepts and Administration")
continuam mesmo assim, para se obter o status de banco REALMENTE idle
eu sigiriria vc fazer um SHUTDOWN mesmo e um STARTUP RESTRICT
2. o ponto principal que paga na performance de DDLs do tipo em
ambientes Produção é que DDLs de ALTER TABLE normalmente não podem ser
paralelizados : CONSIDERE a possibilidade de se fazer um CREATE TABLE
nomeqqueer nologging etcetc as (select * from tabela where 1=2),
adicionar o campo novo nesse cara vazio, depois mandar um INSERT /*+
APPEND */ into tabelanova(lista de campos) (select * from tabela) -
que esse sim PODE ser paralelizado via ALTER SESSION ENABLE PARALLEL
DML, não consome quase nada de undo/redo, etc -, depois vc renomeia a
tabela atual, renomeia a nova pra atual e vai recriando os
índices/constraints/etc na tabela nova, com
NOVALIDATE/PARALLEL/NOLOGGING, tudo que puder...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu
>
> Bem, antes de qquer coisa, vc ** MONITOROU ** o consumo de UNDO antes,
> durante e depois da tentativa de ALTER TABLE, ** E ** verificou a
> possibilidade de eventual bug, tal como eu tinha dito ? Essás ações
> vão te dar subsídios, EM ESPECIAL se vc está num release antigo de 10g
> (vc não diz a versão exata.... ) com RAC, houveram mais de um bug nos
> releases iniciais de banco e de RAC 10g.
> De qquer maneira :
>
> 1. sobre o tamanho/retenção : como eu disse e repito, a partir do
> momento em que vc vá visitar uma enorme qtdade de blocos (já que a
> tabela tem milhões e milhões de linhas), não é NADA incomum vc
> precisar de undo na casa das dezenas de Gb, então SIM, pode ser que 6
> Gb não estejam dando conta.... Sobre a retenção, esse valor é em
> segundos, então 10800 segundos representam 180 minutos, ie, uma hora e
> meia, tranquilamente pode ser sim que um DDL numa tabela de não sei
> quantos milhões demore mais que isso, suba esse valor também
>
> 2. sobre dropar : sim, vc até pode dropar as
> triggers/índices/constraints, , mas aí vc ** tem ** que ter um step a
> mais de backup do DDL pra poder recriar depois, penso que
> DESABILITAR/DESLIGAR/DEIXAR INUSÁVEL é mais fácil, imho. Lembro também
> não ser possível dropar índice em uso por constraint, não ser possível
> dropar constraint PK/UK em uso por FK, etc, similar às referentes ao
> DISABLE, leve em conta se vc quiser dropar os índices
>
> 3. desabilitar : a sintaxe correta para se desabilitar/deixar
> inacessíveis índices/constraints/triggers (e portanto não sendo
> necessária alteração, não sendo disparadas triggers, etc, mostradas no
> manual "Oracle SQL Reference" e discutidas no "Oracle® Database
> Administrator's Guide", para índices é ALTER INDEX nnn UNUSABLE; ,
> para constraints é ALTER TABLE nomedatabela DISABLE CONSTRAINT
> nomedaconstraint, e para triggers é ALTER TRIGGER nnn DISABLE; -
> lembro que tanto podem existir trigger a nível de tabela amarradas na
> tabela que vc quer alterar, QUANTO podem haver triggers de DDL que
> estejam interferindo no seu comando ALTER, desabilite/desligue TODAS
> que encontrar!!
> As principais restrições (documentadas no manual de Admin citado)
são :
>
> - vc não pode desabilitar/desligar um índice que esteja sendo usado
> por uma constraint de PK/UK, então primeiro faça o desabilit das
> constraint, pra depois fazer dos índices
>
> - vc TEM que desabilitar primeiro as constraints de FK das outras
> tabelas todas que apontam pra tabela cuja PK ou UK vc quer desligar,
> para DEPOIS desligar as PKs e UKs, FKs e CHECKs da tabela-alvo
>
> ==>> aí sim, em resposta ao DDL de alter na dita tabela vc terá
> alterações (e portanto undo/redo) apenas nos objetos internos Oracle
> que "cuidam" de tabelas, não terá processamento a mais na transação,
> não terá triggers nem lock de tabela devido á FK sem índice ou coisas
> do tipo - está é a SUPOSIÇÃO que estou fazendo, que vc estava tendo
> muita geração e/ou leitura consistente em undo por causa desses
> "acessórios" da tabela, desabilitando geral tudo vc teria resultado
> melhor, essa é a minha suposição... E claro, feito o DDL, na hora de
> rehabilitar , logicamente vc ** VAI ** pedir um ENABLE NOVALIDATE nas
> constraints, REBUILD PARALLEL nn NOLOGGING nos índices (** se ** o seu
> banco/hardware suporta Paralelismo e modo nolog), vai ter várias
> sessões cada uma habilitando uma parte....
>
> 4. já que necessariamente um DDL tipo ALTER TABLE ** TEM QUE **
> varrer a tabela toda (lendo TODOS os registros em todos os blocos
> formatados de todos os extents, reservando/criando espaço em cada
> registro para os dados que virão na tal coluna), e vc está numa janela
> de manutenção (sem outros usuários concorrentes), sugiro também que :
>
> a) vc faça a operação via sqlplus , com conexão LOCAL NO SERVIDOR
> ORACLE, e não de máquina-cliente
>
> b) na sessão aonde vc vai fazer a operação, mande lá um ALTER SESSION
> SET DB_FILE_MULTIBLOCK_READ_COUNT=máximovalorpossívelnoseuhardware ; ,
> um WORKAREA_SIZE_POLICY=MANUAL e sete os valores de hash_area_size,
> sort_area_size, etc, lááá pro alto, já que haverá só as sessões
> internas do Oracle competindo por disco e RAM com vc
>
> []s
>
> Chiappa
> --- Em oracle_br@yahoogrupos.com.br, Sérgio <sergio@> escreveu
> >
> > Chiappa,
> >
> > Ainda tentei fazer alter index xx.xxxx disable, mas não é
possível,
> > dá ora-02243. Seria assim mesmo para desabilitar um índice???
> >
> > Tks
> >
> > Sérgio
> > ----- Original Message -----
> > From: Sérgio
> > To: oracle_br@yahoogrupos.com.br
> > Sent: Friday, November 30, 2007 2:49 PM
> > Subject: Re: [oracle_br] Re: Dúvida
> >
> >
> > Chiappa,
> >
> > Na verdade existem 6 Gb disponíveis para UNDO, e o
> undo_retention=10800.
> > Esse valor de undo_retention seria pequeno??
> > Durante a tentativa de fazer o alter table, o erro demorou 1:45 hs
> para acontecer.
> >
> > Se eu fizer um drop nos indices, isso ajudaria?? Depois eu poderia
> recriá-los...
> >
> > Obrigado.
> >
> > Sérgio
> >
> > Não sei se as informações sobre tamanho de tabela ajudam, mas...
> > Tabela 1 - 36.000.000 de registros
> > Tabela 2.543.616 Kb
> > Indice 1 - 1.840.128 Kb
> > Indice 2 - 1.904.640 Kb
> > Indice 3 - 1.310.720 Kb
> >
> > Tabela 2 - 68.000.000 de registros
> > Tabela 3.929.088 Kb
> > Indice 1 - 3.997.696 Kb
> > Indice 2 - 3.801.088 Kb
> > Indice 3 - 2.949.120 Kb
> >
> > ----- Original Message -----
> > From: jlchiappa
> > To: oracle_br@yahoogrupos.com.br
> > Sent: Tuesday, November 27, 2007 7:52 AM
> > Subject: [oracle_br] Re: Dúvida
> >
> > Ah, detalhes importantes :
> >
> > a) vc diz que é "grande" a sua undo tablespace, grande o QUANTO
???? A
> > partir do momento em que se tem que processar milhões e milhões de
> > linhas, undo tablespace na casa de DEZENAS de Gigabytes, é por
aí que
> > vc está ?
> >
> > b) vc não diz, mas assumo undo automático, ENTÂO vc tem que subir
> > TAMBÉM o undo_retention se não o fez, UNDO grande com retention
> > default não serve DE NADA...
> >
> > []s
> >
> > Chiappa
> > --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <jlchiappa@>
escreveu
> > >
> > > OK, erro 30036 já é alguma coisa - pra saber, exatamente O QUE
mudou
> > > na sua tentativa anterior, que não dava erro NENHUM, para essa
> que dá
> > > erro ? Vc mudou de tool, de tipo de conexão, o que exatamente ??
> > > Bem, sobre o erro, seguinte : é totalmente documentado, e nós
> aqui no
> > > fórum já falamos também, que a opção de NOLOGGING sozinha não
> serve de
> > > COISA NENHUMA, ela só funciona ** EM ALGUMAS POUCAS OPERAÇÔES
> **, tal
> > > como INSERT /*+ APPEND */ , DDLs do tipo ALTERs necessariamente
> SERÃO
> > > logados E exige também que não hajam índices habilitados
(alterações
> > > em índices SEMPRE SEMPRE são logadas)... No seu caso, o ALTER
em si
> > > gera muito pouco UNDO, e também muito pouco REDO LOG, não
> justificaria
> > > um consumo grande, então pra mim o que está acontecendo é que
vc tem
> > > ** ÍNDICES ** nessas tabelas, e talvez TRIGGERs e CONSTRAINTSs
> também,
> > > e são esses outros caras periféricos que estão gerando muita
> coisa....
> > > Eu recomendaria que antes dos ALTERs vc *** DESABILITASSE
TOTALMENTE
> > > ** as constraints, os índices e as eventuais triggers das
> tabelas que
> > > vão ser alteradas e das tabs á elas relacionadas (via FK ou
> > > assemelhado), E imediatamente antes, durante e depois do ALTER vc
> > > fosse consultando a geração de redo e de undo, pesquisando os
> > > registros apropriados nas v$%stat%, E também checasse a qtdade
> de regs
> > > de undo via uma query tipo :
> > >
> > > column sid format 999
> > > column segment_name format a15
> > > select b.segment_name, a.username, a.sid, a.serial#, c.used_ublk,
> > > c.used_urec,c.START_UBAFIL, c.START_UBABLK, c.START_UBAREC ,
> b.status,
> > > b.TABLESPACE_NAME, b.SEGMENT_ID, b.FILE_ID, b.BLOCK_ID
> > > from v$session a, dba_rollback_segs b, v$transaction c
> > > where b.segment_id = c.xidusn
> > > and a.taddr = c.addr
> > > /
> > >
> > > []s
> > >
> > > Chiappa
> > > --- Em oracle_br@yahoogrupos.com.br, Sérgio <sergio@> escreveu
> > > >
> > > > Chiappa, boa tarde.
> > > >
> > > > Na verdade eu utilizava um script, mas tentei fazer cada comando
> > > > manualmente e recebi ORA-30036-Unable to extend segment by 8
> > > > in Undo tablespace <tblspc>. Tive um problema parecido no 8i e
> > > > era bug mesmo, mas depois disso nunca mais vi algo parecido.
> > > > Minha tablespaces Undo já é enorme e estou sem espaço para
> > > > aumentar isso.
> > > > Para 'alter table....', a opção 'nologging' não irá fazer todo o
> > > 'trabalho'
> > > > sem 'encher' a Undo??? Seria uma opção???
> > > >
> > > > Obrigado.
> > > >
> > > > Sérgio
> > > >
> > > > ----- Original Message -----
> > > > From: jlchiappa
> > > > To: oracle_br@yahoogrupos.com.br
> > > > Sent: Tuesday, November 20, 2007 1:38 PM
> > > > Subject: [oracle_br] Re: Dúvida
> > > >
> > > >
> > > > Sérgio, isso realmente cheira a bug, pra vc comprovar isso com o
> > > > SUporte da Oracle (que é quem pode te orientar mais
> precisamente),eu
> > > > sugiro que vc , se não o fez, faça a operação diretamente no
> > sqlplus,
> > > > para evitar probs com utilitários "escondendo" msgs de erros, E
> > > > diretamente em SQL, sem qquer tipo de programação.
> > > >
> > > > []s
> > > >
> > > > Chiappa
> > > >
> > > > --- Em oracle_br@yahoogrupos.com.br, Sérgio <sergio@> escreveu
> > > > >
> > > > > Sim, a tabela está correta Gleyson.
> > > > > Não tenho sinônimos no meu banco.
> > > > > Eu fiz alter table em 2 outras tabelas, na mesma sessão,
> > logado com
> > > > o owner
> > > > > da tabela, sem problemas.
> > > > > Os comandos foram executados conforme especifiquei abaixo.
> > > > > - alter system enable restricted session
> > > > > - alter table tabela1
> > > > > - alter table tabela2
> > > > > - alter table tabela3
> > > > > - alter system disable restricted session
> > > > >
> > > > > As tabelas 1 e 2 foram alteradas, a 3 , não.
> > > > >
> > > > > Sérgio
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: Gleyson Melo
> > > > > To: oracle_br@yahoogrupos.com.br
> > > > > Sent: Monday, November 19, 2007 4:39 PM
> > > > > Subject: Re: [oracle_br] Dúvida
> > > > >
> > > > >
> > > > > Fala Sérgio!
> > > > >
> > > > > Antes de tudo... você verificou se você realmente está
fazendo a
> > > > modificação
> > > > > na tabela correta? Digo, voce nao verificou em uma outra com
> > > > sinonimo igual?
> > > > > Você está utilizando o owner no comando ALTER TABLE? Só
pra ter
> > > > certeza.
> > > > >
> > > > > Você pode gerar um script da sua operação e mandar pra lista o
> > > > resultado?
> > > > >
> > > > > Abração
> > > > >
> > > > > Em 19/11/07, Sérgio <sergio@> escreveu:
> > > > > >
> > > > > > Srs. boa tarde.
> > > > > >
> > > > > > Possuo uma tabela com 32.000.000 de registros e
> > > > > > precisei fazer um alter table xxx add(campo number(15,4)
> default
> > > > 0 not
> > > > > > null).
> > > > > > Após umas 2 horas de processamento, o comando termina
> > normalmente
> > > > > > mas nada foi feito.
> > > > > > Tentei fazer a mesma coisa novamente, mas não consegui
> > adicionar o
> > > > > > campo desejado. (tentei até commit após o comando...)
> > > > > > No alert nada de anormal aparece, apenas o arquivamento dos
> > > redos..
> > > > > >
> > > > > > Alguém tem alguma dica do que pode estar acontecendo??
> > > > > >
> > > > > > Obrigado desde já
> > > > > >
> > > > > > Sérgio
> > > > > >
> > > > > > Meu ambiente:
> > > > > > - Oracle 10g , Linux RHAS 4, 2 instancias (RAC) com storage,
> > > 64 bits
> > > > > > - Fiz alter system enable restricted session em ambas
> > instancias,
> > > > > > derrubei conexões remanescentes de usuarios (embora
inativos),
> > > > > > parei todos os job´s que estavam rodando, embora nenhuma
> tivesse
> > > > > > ligação com a tabela em questão,
> > > > > > executei o comando alter table xxx add........
> > > > > > --nesse ponto verifico objetos inválidos e recompilo-os, se
> > > > existirem
> > > > > > alter system disable restricted session em ambas novamente.
> > > > > >
> > > > > > Detalhe: havia feito alteração idêntica em 2 tabelas de
> > > > 300.000anteriormente,
> > > > > > e ocorreu tudo normalmente.
> > > > > >
> > > > > > ---
> > > > > > Esta mensagem não implica a assunção de obrigações em
nome da
> > > > > > empresa Irmãos Muffato e Cia Ltda, conforme Contrato
Social em
> > > > > > sua 3a. Cláusula da 56a. alteração. Qualquer uso não
> autorizado,
> > > > > > replicação ou disseminação desta mensagem ou parte dela é
> > > > > > expressamente proibido. A empresa Irmãos Muffato e Cia
> Ltda não
> > > > > > é responsável pelo conteúdo ou a veracidade desta
informação.
> > > > > >
> > > > > > [As partes desta mensagem que não continham texto foram
> > removidas]
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Atenciosamente,
> > > > > Gleyson Melo
> > > > > Oracle Database 10g Administrator Certified Professional
> > > > >
> > > > > [As partes desta mensagem que não continham texto foram
> removidas]
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---
> > > > > Esta mensagem não implica a assunção de obrigações em nome da
> > > > > empresa Irmãos Muffato e Cia Ltda, conforme Contrato Social em
> > > > > sua 3a. Cláusula da 56a. alteração. Qualquer uso não
autorizado,
> > > > > replicação ou disseminação desta mensagem ou parte dela é
> > > > > expressamente proibido. A empresa Irmãos Muffato e Cia
Ltda não
> > > > > é responsável pelo conteúdo ou a veracidade desta informação.
> > > > >
> > > > >
> > > > >
> > > > > [As partes desta mensagem que não continham texto foram
> removidas]
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > ---
> > > > Esta mensagem não implica a assunção de obrigações em nome da
> > > > empresa Irmãos Muffato e Cia Ltda, conforme Contrato Social em
> > > > sua 3a. Cláusula da 56a. alteração. Qualquer uso não autorizado,
> > > > replicação ou disseminação desta mensagem ou parte dela é
> > > > expressamente proibido. A empresa Irmãos Muffato e Cia Ltda não
> > > > é responsável pelo conteúdo ou a veracidade desta informação.
> > > >
> > > >
> > > >
> > > > [As partes desta mensagem que não continham texto foram
removidas]
> > > >
> > >
> >
> > ---
> > Esta mensagem não implica a assunção de obrigações em nome da
> > empresa Irmãos Muffato e Cia Ltda, conforme Contrato Social em
> > sua 3a. Cláusula da 56a. alteração. Qualquer uso não autorizado,
> > replicação ou disseminação desta mensagem ou parte dela é
> > expressamente proibido. A empresa Irmãos Muffato e Cia Ltda não
> > é responsável pelo conteúdo ou a veracidade desta informação.
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> >
> > ---
> > Esta mensagem não implica a assunção de obrigações em nome da
> > empresa Irmãos Muffato e Cia Ltda, conforme Contrato Social em
> > sua 3a. Cláusula da 56a. alteração. Qualquer uso não autorizado,
> > replicação ou disseminação desta mensagem ou parte dela é
> > expressamente proibido. A empresa Irmãos Muffato e Cia Ltda não
> > é responsável pelo conteúdo ou a veracidade desta informação.
> >
> >
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
---
Esta mensagem não implica a assunção de obrigações em nome da
empresa Irmãos Muffato e Cia Ltda, conforme Contrato Social em
sua 3a. Cláusula da 56a. alteração. Qualquer uso não autorizado,
replicação ou disseminação desta mensagem ou parte dela é
expressamente proibido. A empresa Irmãos Muffato e Cia Ltda não
é responsável pelo conteúdo ou a veracidade desta informação.
[As partes desta mensagem que não continham texto foram removidas]
