Faz assim então, pode ser que esteja com lock na tabela de
privilégios(row cache lock). Conecta como sys e roda o script de lock
?/rdbms/admin/utllockt.sql. Se for isso mata a sessão que está
bloqueando e testa novamente. Pode usar a consulta abaixo para decobrir
o processo no servidor.
select v.spid, s.osuser, s.program from
v$process p, v$session s where p.addr=s.paddr
Att
Jonathan
----- Mensagem de [EMAIL PROTECTED] ---------
Data: Tue, 18 Sep 2007 15:29:40 -0000
De: Aleksandro <[EMAIL PROTECTED]>
Endereço para Resposta (Reply-To): oracle_br@yahoogrupos.com.br
Assunto: [oracle_br] Re: Banco travando ao se conectar em usuário não
SYS (HELP, HELP) !!!!!!!!
Para: oracle_br@yahoogrupos.com.br
> Boa tarde,
>
> Tentei remotamente e não consegui, então fui até o servidor e também
> trava.
>
> To quase apelando fazendo um dumping e reinstalando o software pra
> testar, mas vou dar um tempo ainda nisso.
>
> --- Em oracle_br@yahoogrupos.com.br, [EMAIL PROTECTED] escreveu
>>
>>
>> Outra coisa, se estiveres tentando conectar remotamente faça um teste.
>> Exporta a variável oracle_sid no servidor e tenta conectar com outro
>> usuário sem o serviço de rede(sem o @banco). Ve se funciona, se
>> funcionar pode ser algum problema na configuração dos serviços de rede.
>>
>>
>> Att
>> Jonathan Barbosa
>>
>> ----- Mensagem de [EMAIL PROTECTED] ---------
>> Data: Tue, 18 Sep 2007 14:58:33 -0000
>> De: Aleksandro <[EMAIL PROTECTED]>
>> Endereço para Resposta (Reply-To): oracle_br@yahoogrupos.com.br
>> Assunto: [oracle_br] Re: Banco travando ao se conectar em usuário não
>> SYS (HELP, HELP) !!!!!!!!
>> Para: oracle_br@yahoogrupos.com.br
>>
>>
>> > Já estou quase apelando para a desinstalação
>> >
>> > --- Em oracle_br@yahoogrupos.com.br, "Aleksandro"
>> > <aleksandrosouza@> escreveu
>> >>
>> >> Olhei e não encontrei nada de errado, o valor do parametro processes,
>> >> eu aumentei mais não deu resultado.
>> >> No cdump, bdump, udump também não encontrei nada de errado nem no
>> >> alert, o alert não diz nenhuma mensagem de erro.
>> >>
>> >> O que achei estranho porém nunca testei conectando e ao mesmo
>> >> derrubando o banco é a mensagem que aparece abaixo quando derrubo o
>> >> banco enquanto esses usuários estão travados.
>> >>
>> >> Erro de acesso a PRODUCT_USER_PROFILE
>> >> Advertência: Info. de perfil do usuário do produto não carregadas!
>> >> Talvez seja necessário executar PUPBLD.SQL como SYSTEM
>> >> ERROR:
>> >> ORA-03114: não conectado ao ORACLE
>> >>
>> >> Se esse for o problema eu rodei o sql e não adiantou nada.
>> >> Quanto a tablespace da AUD$, é a system que tem espaço.
>> >>
>> >> Colei abaixo o alert.log do oracle, se alguem souber por favor me
> ajude:
>> >>
>> >> Tue Sep 18 09:27:57 2007
>> >> Starting ORACLE instance (normal)
>> >> LICENSE_MAX_SESSION = 0
>> >> LICENSE_SESSIONS_WARNING = 0
>> >> Picked latch-free SCN scheme 2
>> >> Using LOG_ARCHIVE_DEST_10 parameter default value as
>> >> USE_DB_RECOVERY_FILE_DEST
>> >> Autotune of undo retention is turned on.
>> >> IMODE=BR
>> >> ILAT =42
>> >> LICENSE_MAX_USERS = 0
>> >> SYS auditing is disabled
>> >> ksdpec: called for event 13740 prior to event group initialization
>> >> Starting up ORACLE RDBMS Version: 10.2.0.1.0.
>> >> System parameters with non-default values:
>> >> processes = 350
>> >> __shared_pool_size = 92274688
>> >> __large_pool_size = 4194304
>> >> __java_pool_size = 4194304
>> >> __streams_pool_size = 4194304
>> >> nls_language = BRAZILIAN PORTUGUESE
>> >> nls_territory = BRAZIL
>> >> resource_manager_plan = INTERNAL_QUIESCE
>> >> sga_target = 285212672
>> >> control_files = D:\ORADATA\TESTAR\CONTROL01.CTL,
>> >> D:\ORADATA\TESTAR\CONTROL02.CTL, D:\ORADATA\TESTAR\CONTROL03.CTL
>> >> db_block_size = 8192
>> >> __db_cache_size = 176160768
>> >> compatible = 10.2.0.1.0
>> >> log_archive_format = ARC%S_%R.%T
>> >> db_file_multiblock_read_count= 16
>> >> db_recovery_file_dest = D:\ORACLE\FLASH_RECOVERY
>> >> db_recovery_file_dest_size= 9999999999
>> >> undo_management = AUTO
>> >> undo_tablespace = UNDOTBS1
>> >> remote_login_passwordfile= EXCLUSIVE
>> >> db_domain =
>> >> dispatchers = (PROTOCOL=TCP) (SERVICE=TESTARXDB)
>> >> job_queue_processes = 10
>> >> audit_file_dest = D:\ADMIN\TESTAR\ADUMP
>> >> background_dump_dest = D:\ADMIN\TESTAR\BDUMP
>> >> user_dump_dest = D:\ADMIN\TESTAR\UDUMP
>> >> core_dump_dest = D:\ADMIN\TESTAR\CDUMP
>> >> db_name = TESTAR
>> >> open_cursors = 300
>> >> pga_aggregate_target = 94371840
>> >> PMON started with pid=2, OS id=2000
>> >> PSP0 started with pid=3, OS id=4596
>> >> MMAN started with pid=4, OS id=1460
>> >> DBW0 started with pid=5, OS id=4672
>> >> LGWR started with pid=6, OS id=316
>> >> CKPT started with pid=7, OS id=1476
>> >> SMON started with pid=8, OS id=4652
>> >> RECO started with pid=9, OS id=1676
>> >> CJQ0 started with pid=10, OS id=2128
>> >> MMON started with pid=11, OS id=1988
>> >> Tue Sep 18 09:27:57 2007
>> >> starting up 1 dispatcher(s) for network address
>> >> '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
>> >> MMNL started with pid=12, OS id=1880
>> >> Tue Sep 18 09:27:57 2007
>> >> starting up 1 shared server(s) ...
>> >> Tue Sep 18 09:27:57 2007
>> >> ALTER DATABASE MOUNT
>> >> Tue Sep 18 09:28:01 2007
>> >> Setting recovery target incarnation to 2
>> >> Tue Sep 18 09:28:01 2007
>> >> Successful mount of redo thread 1, with mount id 2914163613
>> >> Tue Sep 18 09:28:01 2007
>> >> Database mounted in Exclusive Mode
>> >> Completed: ALTER DATABASE MOUNT
>> >> Tue Sep 18 09:28:01 2007
>> >> ALTER DATABASE OPEN
>> >> Tue Sep 18 09:28:01 2007
>> >> Beginning crash recovery of 1 threads
>> >> Tue Sep 18 09:28:01 2007
>> >> Started redo scan
>> >> Tue Sep 18 09:28:02 2007
>> >> Completed redo scan
>> >> 0 redo blocks read, 0 data blocks need recovery
>> >> Tue Sep 18 09:28:02 2007
>> >> Started redo application at
>> >> Thread 1: logseq 109, block 1535, scn 3816088
>> >> Tue Sep 18 09:28:02 2007
>> >> Recovery of Online Redo Log: Thread 1 Group 3 Seq 109 Reading mem 0
>> >> Mem# 0 errs 0: D:\ORADATA\TESTAR\REDO03.LOG
>> >> Tue Sep 18 09:28:02 2007
>> >> Completed redo application
>> >> Tue Sep 18 09:28:02 2007
>> >> Completed crash recovery at
>> >> Thread 1: logseq 109, block 1535, scn 3836089
>> >> 0 data blocks read, 0 data blocks written, 0 redo blocks read
>> >> Tue Sep 18 09:28:02 2007
>> >> LGWR: STARTING ARCH PROCESSES
>> >> ARC0 started with pid=15, OS id=900
>> >> Tue Sep 18 09:28:02 2007
>> >> ARC0: Archival started
>> >> ARC1: Archival started
>> >> LGWR: STARTING ARCH PROCESSES COMPLETE
>> >> ARC1 started with pid=17, OS id=4572
>> >> Tue Sep 18 09:28:02 2007
>> >> Thread 1 advanced to log sequence 110
>> >> Tue Sep 18 09:28:02 2007
>> >> ARC0: STARTING ARCH PROCESSES
>> >> Tue Sep 18 09:28:02 2007
>> >> ARC1: Becoming the 'no FAL' ARCH
>> >> ARC1: Becoming the 'no SRL' ARCH
>> >> Tue Sep 18 09:28:02 2007
>> >> Thread 1 opened at log sequence 110
>> >> Current log# 1 seq# 110 mem# 0: D:\ORADATA\TESTAR\REDO01.LOG
>> >> Successful open of redo thread 1
>> >> Tue Sep 18 09:28:02 2007
>> >> MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
>> >> Tue Sep 18 09:28:02 2007
>> >> ARC2: Archival started
>> >> ARC0: STARTING ARCH PROCESSES COMPLETE
>> >> ARC0: Becoming the heartbeat ARCH
>> >> ARC2 started with pid=18, OS id=980
>> >> Tue Sep 18 09:28:02 2007
>> >> SMON: enabling cache recovery
>> >> Tue Sep 18 09:28:02 2007
>> >> db_recovery_file_dest_size of 9536 MB is 51.26% used. This is a
>> >> user-specified limit on the amount of space that will be used by this
>> >> database for recovery-related files, and does not reflect the
> amount of
>> >> space available in the underlying filesystem or ASM diskgroup.
>> >> Tue Sep 18 09:28:02 2007
>> >> Successfully onlined Undo Tablespace 1.
>> >> Tue Sep 18 09:28:02 2007
>> >> SMON: enabling tx recovery
>> >> Tue Sep 18 09:28:03 2007
>> >> Database Characterset is WE8MSWIN1252
>> >> replication_dependency_tracking turned off (no async multimaster
>> >> replication found)
>> >> Starting background process QMNC
>> >> QMNC started with pid=19, OS id=1468
>> >> Tue Sep 18 09:28:04 2007
>> >> Completed: ALTER DATABASE OPEN
>> >>
>> >>
>> >>
>> >>
>> >> --- Em oracle_br@yahoogrupos.com.br, "Orlando Martins" <olmartins@>
>> >> escreveu
>> >> >
>> >> > De bate-pronto, sem msg de erro nem nada ...
>> >> > De uma olhada se a tablespace da AUD$ está cheia, e tambem se
>> > estourou o
>> >> > valor do parametro PROCESSES.
>> >> > Verifique traces em udump, bdump e cdump.
>> >> >
>> >> >
>> >> > [As partes desta mensagem que não continham texto foram removidas]
>> >> >
>> >>
>> >
>> >
>> >
>> >
>> > --------------------------
>> > E-mail Seguro Vetorial.net
>> >
>> > Mensagem classificada como NÃO-SPAM. Para classificar como SPAM,
>> > encaminhe para [EMAIL PROTECTED]
>> >
>> > Chave de Identificação: 49321,46efe7b884205709612664
>> >
>>
>>
>> ----- Final da mensagem de [EMAIL PROTECTED] -----
>>
>
>
>
>
> --------------------------
> E-mail Seguro Vetorial.net
>
> Mensagem classificada como NÃO-SPAM. Para classificar como SPAM,
> encaminhe para [EMAIL PROTECTED]
>
> Chave de Identificação: 49321,46efef98136511741916316
>
----- Final da mensagem de [EMAIL PROTECTED] -----
