Pessoal Só uma pequena observação: 180 minutos = 3 horas.
[ ] André Em 30/11/07, 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(R) 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 <oracle_br%40yahoogrupos.com.br>, > Sérgio <[EMAIL PROTECTED]> 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 <oracle_br%40yahoogrupos.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 <oracle_br%40yahoogrupos.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 <oracle_br%40yahoogrupos.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 <oracle_br%40yahoogrupos.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 <oracle_br%40yahoogrupos.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 <oracle_br%40yahoogrupos.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 <oracle_br%40yahoogrupos.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] > > > > > [As partes desta mensagem que não continham texto foram removidas]
