- Este tópico contém 22 respostas, 2 vozes e foi atualizado pela última vez 17 anos, 5 meses atrás por
Ricardo Portilho Proni.
-
AutorPosts
-
1 de outubro de 2008 às 7:04 pm #82967
mpvargas
ParticipanteNão consigo iniciar o banco.
SQL> startup
ORACLE instance started.Total System Global Area 4009754624 bytes
Fixed Size 1223128 bytes
Variable Size 1056966184 bytes
Database Buffers 2936012800 bytes
Redo Buffers 15552512 bytes
Database mounted.
ORA-03113: end-of-file on communication channelAlguém poderia me ajudar? Obrigado.
1 de outubro de 2008 às 9:45 pm #82968Ricardo Portilho Proni
ParticipanteVeja o que tem no alert log.
1 de outubro de 2008 às 10:16 pm #82969mpvargas
ParticipanteWed Oct 1 15:06:00 2008
starting up 1 dispatcher(s) for network address ‘(ADDRESS=(PARTIAL=YES)(PROTOCOL
=TCP))’…
MMNL started with pid=12, OS id=5389
Wed Oct 1 15:06:00 2008
starting up 1 shared server(s) …
Wed Oct 1 15:06:01 2008
ALTER DATABASE MOUNT
Wed Oct 1 15:06:07 2008
Setting recovery target incarnation to 2
Wed Oct 1 15:06:07 2008
Successful mount of redo thread 1, with mount id 4259728539
Wed Oct 1 15:06:07 2008
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Wed Oct 1 15:06:08 2008
ALTER DATABASE OPEN
Wed Oct 1 15:06:08 2008
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Wed Oct 1 15:06:09 2008
Started redo scan
Wed Oct 1 15:06:09 2008
Completed redo scan
115488 redo blocks read, 4867 data blocks need recovery
Wed Oct 1 15:06:10 2008
Hex dump of (file 2, block 5387) in trace file /u01/app/oracle/admin/teste/bdump
/teste_p001_5399.trc
Corrupt block relative dba: 0x0080150b (file 2, block 5387)
Bad check value found during crash/instance recovery
Data in bad block:
type: 0 format: 2 rdba: 0x0080150b
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000001
check value in block header: 0xb28b
computed block checksum: 0x573c
Reread of rdba: 0x0080150b (file 2, block 5387) found valid data
Hex dump of (file 2, block 5390) in trace file /u01/app/oracle/admin/teste/bdump
/teste_p001_5399.trc
Corrupt block relative dba: 0x0080150e (file 2, block 5390)
Bad check value found during crash/instance recovery
Data in bad block:
type: 0 format: 2 rdba: 0x0080150e
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000001
check value in block header: 0xb28e
computed block checksum: 0x573c
Reread of rdba: 0x0080150e (file 2, block 5390) found valid data
Wed Oct 1 15:06:10 2008
Hex dump of (file 2, block 4996) in trace file /u01/app/oracle/admin/teste/bdump
/teste_p002_5401.trc
Corrupt block relative dba: 0x00801384 (file 2, block 4996)
Bad check value found during crash/instance recovery
Data in bad block:
type: 0 format: 2 rdba: 0x00009642
last change scn: 0x0000.00000000 seq: 0x1 flg: 0x05
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00000001
check value in block header: 0x3142
computed block checksum: 0xa8d2
Reread of rdba: 0x00009642 (file 6, block 38466) found valid data
Wed Oct 1 15:06:10 2008
Started redo application at
Thread 1: logseq 6, block 50
Wed Oct 1 15:06:10 2008
Recovery of Online Redo Log: Thread 1 Group 2 Seq 6 Reading mem 0
Mem# 0 errs 0: /u01/app/oracle/oradata/teste/redo02.log
Wed Oct 1 15:06:11 2008
Errors in file /u01/app/oracle/admin/teste/bdump/teste_dbw0_5375.trc:
ORA-07445: exception encountered: core dump [kghlkaftf()+128] [SIGSEGV] [Address
not mapped to object] [0x95C73FBC] [] []
Wed Oct 1 15:06:12 2008
Errors in file /u01/app/oracle/admin/teste/bdump/teste_pmon_5369.trc:
ORA-00471: DBWR process terminated with error
Wed Oct 1 15:06:12 2008
PMON: terminating instance due to error 471
Instance terminated by PMON, pid = 53691 de outubro de 2008 às 10:30 pm #82970Ricardo Portilho Proni
ParticipanteCorrupcao dos dados.
Tem backup em RMAN, ou algum outro?1 de outubro de 2008 às 10:34 pm #82971mpvargas
ParticipanteNo caso é erro no disco?
Na verdade esse servidor é novo e estou criando a base para receber os dados via import.
Ainda bem que está em faze de testes.1 de outubro de 2008 às 10:44 pm #82972Ricardo Portilho Proni
ParticipanteSim, eh erro nos arquivos de dados.
Este banco foi desligado sem shutdown no Oracle.
Ele foi tentar fazer o recover no datafile 2 (provavelmente da tablespace SYSAUX) e nao conseguiu.
Ja que eh novo, se for 10g, remova o banco e crie novamente, via DBCA mesmo.
E veja se seu disco estah bem !1 de outubro de 2008 às 10:57 pm #82974mpvargas
ParticipanteOK. Vou fazer isso. Muito Obrigado.
Sem querer abusar, esse servidor é 32bits e tem 14Gb RAM, estou usando RedHat 4 Enterprise Linux. No nosso servidor antigo eu usava o SGA_TARGET = 2Gb pois ele tem 6Gb RAM, mas nesse estou tentando alocar mais memória… depois de algumas alterações no kernel, consegui colocar a SGA com 4Gb, mas não posso usar o SGA_TARGET. Então fiz uma configuração de acordo com os percentuais que tinha na SGA_TARGET e coloquei dessa forma:*.db_block_buffers=435200
*.db_block_size=8192
*.db_file_multiblock_read_count=16
*.java_pool_size=33554432
*.job_queue_processes=10
*.large_pool_size=33554432
*.open_cursors=300
*.pga_aggregate_target=629145600
*.processes=150
*.sga_max_size=4200000000
*.sga_target=0
*.shared_pool_size=637534208
*.streams_pool_size=33554432
*.use_indirect_data_buffers=trueSerá que a memória está bem distribuída… Obrigado.
1 de outubro de 2008 às 11:07 pm #82975Ricardo Portilho Proni
ParticipanteO pga_aggregate_target nao faz parte do SGA.
Coloque os 600M que colocou para ele no db_cache_size.
Pode colocar para o pga_aggregate_target uns 4 GB, veja se sobe.1 de outubro de 2008 às 11:18 pm #82976Ricardo Portilho Proni
ParticipanteOps, desculpe, vc nao pode usar db_cache_size e db_block_buffers ao mesmo tempo…
Entao distribua estes 600 MB entre shared_pool e db_block_buffers, sao as estruturas mais importantes.2 de outubro de 2008 às 12:04 am #82979mpvargas
ParticipanteOK Ricardo. Muito Obrigado.
Vou fazer os testes e depois retorno.
Trabalho a pouco tempo com Oracle e se tem uma coisa que acho complicada é o gerenciamento de memória.
A PGA por exemplo, influencia em que?2 de outubro de 2008 às 12:11 am #82981Ricardo Portilho Proni
ParticipantePGA eh a area utilizada pelos processos de usuario.
Nela fica, por exemplo, a area temporaria utilizada para ORDER BY. Se faltar PGA, o Oracle vai usar a TABLESPACE Temporaria.
Fique de olho na view V$PGASTAT… la vc vai saber se precisa de mais ou nao.2 de outubro de 2008 às 12:45 am #82982mpvargas
ParticipanteOK.
Só um último detalhe.
Com relação ao REDO LOG BUFFER também tenho dúvidas. Existe alguma regra para o tamanho desse parâmetro? Atualmente, no meu servidor de produção, o tamanho é 15MB, mas já li em alguns artigos que no caso de existir muitas consultas na base, o ideal é colocar de 50 à 100MB.
Mais uma vez muito obrigado pela ajuda.2 de outubro de 2008 às 12:54 am #82983Ricardo Portilho Proni
ParticipanteAcho este valor inutil. Tanto que o padrao eh 2M, se nao me engano, no 10g.
O LOG_BUFFER eh esvaziado a cada checkpoint para os arquivos de REDO.
Um Checkpoint ocorre no maximo a cada 3 segundos, ou quando o LOG_BUFFER esta pela metade, o que ocorrer primeiro. Um Checkpoint ocorre tb a cada LOG SWITCH.E se vc colocar este valor muito grande, teoricamente vc corre o risco de perder mais dados, pois sao mais dados que ainda nao foram para os arquivos de REDO, estao em uma memoria que sera perdida em um crash.
Deixe seus REDOs em discos separados e rapidos, e vc nao precisara pensar neste parametro.2 de outubro de 2008 às 12:57 am #82984Ricardo Portilho Proni
ParticipanteAh, esqueci de uma coisa, nao faz senntido “mais consultas” precisarem de mais LOG BUFFER.
LOG BUFFER eh pra REDO, gravacao, consultas nao usam ele. Usam o db_cache_size. Este sim, deve ser grande.2 de outubro de 2008 às 2:29 am #82988mpvargas
ParticipanteNo caso, em que momento ele cria efetivamente o arquivo de log, na flashback_recovery_area?
Tenho 1 grupo com 5 arquivos de 200Mb.
Como usamos RAID 5, resolvi não criar mais grupos porque na hora de gravar aponta sempre pro mesmo filesystem. -
AutorPosts
- Você deve fazer login para responder a este tópico.