Blz, ficamos contentes por ter ajudado... Só um ponto final que eu tinha dito
anteriormente eu tenho que repetir : questões técnicas do tipo melhor config de
banco para performance, recursos presentes na versão x ou só na y, como se
adequar a diferentes setups de banco, estabelecer um mínimo
Muito obrigado à ajuda de vocês.
Foi interessante para aprender mais um pouco sobre o banco e ter subsídio
para falar com o meu gerente.
Abraço,
Roberto
Em 9 de fevereiro de 2017 18:45, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:
>
>
> Sim, mas olha o resto da
Sim, mas olha o resto da frase (ênfase com *s minha) :
"Earlier releases of Oracle Database default to manual undo management mode. To
change to automatic undo management, you must first create an undo tablespace
and then change the *** UNDO_MANAGEMENT initialization parameter *** to AUTO."
Chiappa,
Earlier releases of Oracle Database default to manual undo management mode.
Entendo que a frase se refere ao "Oracle Database" como um todo, e não só ao
parâmetro. Mas sinceramente não me lembro mais como isso ficava ao rodar o DBCA
da 10g, quanto mais da 9i...
E não tenho um
A sua interpretação tá errada, talvez o Inglês não tenha deixado Claro pra vc :
o que está sendo dito é que o *** PARÂMETRO ***, a CONFIG de UNDO_MANAGEMENT em
versões anteriores Não era AUTO, mas em *** LUGAR NENHUM ** ele diz que vc está
Proibido de colocar como AUTO, isso só não é o
Roberto,
Entendo que o que está dizendo ai é que na versão 9i e 10g o dbca não ativa o
automatic undo por padrão, sendo necessário fazer isso após a criação do banco
de dados. E ele está indicando que nesse manual de upgrade tem um procedimento
para se fazer isso.
E está alertando também
Retomando o assunto, sim, esse script é como se fosse a aplicação de um
PATCH. O nosso problema é que dizemos para os clientes como eles devem
proceder, mas eles fazem do jeito deles e quando algo dá errado, nós é que
temos que dar um jeito.
Estamos analisando de recomendar para os clientes que
Sim, certamente se vc está fazendo a leitura com COMMIT parcial (o melhor seria
COMMIT por *** TEMPO **, ie, COMMIT a cada X minutos cfrme
https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:4951966319022
mas enfim) sim, vc diminui Enormemente a chance de UNDO necessário para
Muito obrigado pelas respostas.
Esse script é utilizado para fazer a criação/alteração de colunas e popular
elas com os seus defaults. Como podemos somos uma desenvolvedora de
sistemas, as tabelas podem ter os seus mais variados tamanhos, desde
algumas linhas linhas até milhares de linhas. Posto
Bem, não sabemos se tem execução multi-usuário nessa parada, mas sim, é verdade
que no RDBMS Oracle a consistência de dados é feita com o SCN exato do instante
em que o SQL começou : então se o tal cursor C_TABLE foi aberto e começou a
processar em 06/02/2017 às 10h:15m:25s digamos,
Roberto,
Sem entrar no mérito se isso é adequado ou não, fechar e abrir o cursor
novamente deve causar dois efeitos:
- A "query" quando for executada novamente deve passar a enxergar registros
"comitados" por outras sessões nesse intervalo de tempo.
- Será gerado um novo "snapshot" da query,
Oi : não, não existe o *** menor sentido *** em se fazer isso : até existiria
algum sentindo em ** comitar ** a cada x registros - isso ** não é **
recomendado para a performance nem para a integridade de dados, cfrme
12 matches
Mail list logo
