Cria um usuário e depois tenta dar grants para ele conectar o que
acontece? A sessão fica travada na hora do grant?
Att
Jonathan Barbosa
----- Mensagem de [EMAIL PROTECTED] ---------
Data: Tue, 18 Sep 2007 16:17:56 -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
> Sem chances, pra voce ter uma idéia, não tem como estar com lock se eu
> acabei de subir o banco e tentei conectar, não tem sessão travada.
>
>
> --- Em oracle_br@yahoogrupos.com.br, [EMAIL PROTECTED] escreveu
>>
>> 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 Barbosa
>>
>>
>> ----- Mensagem de [EMAIL PROTECTED] ---------
>> Data: Tue, 18 Sep 2007 16:00:38 -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
>>
>>
>> > Então, conectava normalmente, estou usando o oracle 10g no Windows
>> > 2000. O Estranho é que nem o console de administração que é em HTML
>> > não esta funcionando, dá erro de "A página não pode ser exibida" e
>> > antes conectava.
>> > O que não entende é porque o SYS e o SYSTEM conectam e os outros
>> > usuários não ? Mesmo eu criando um agora não vai funcionar. Testei
>> > tablespace, voltei backup via RMAN até um período, reiniciei o
>> > servidor e tentei conectar em seguida, aumentei várias coisas no
>> > arquivo de configuração, só faltou botar fogo.
>> >
>> >
>> >
>> > --- Em oracle_br@yahoogrupos.com.br, spark@ escreveu
>> >>
>> >>
>> >> Qual a versão do banco e do SO? Antes conectava numa boa ou este
> banco
>> >> foi criado e logo ja apresentou esse problema?
>> >>
>> >> Att
>> >> Jonathan Barbosa
>> >> ----- Mensagem de aleksandrosouza@ ---------
>> >> Data: Tue, 18 Sep 2007 15:29:40 -0000
>> >> De: Aleksandro <aleksandrosouza@>
>> >> 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, spark@ 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 aleksandrosouza@ ---------
>> >> >> Data: Tue, 18 Sep 2007 14:58:33 -0000
>> >> >> De: Aleksandro <aleksandrosouza@>
>> >> >> 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 spam@
>> >> >> >
>> >> >> > Chave de Identificação: 49321,46efe7b884205709612664
>> >> >> >
>> >> >>
>> >> >>
>> >> >> ----- Final da mensagem de aleksandrosouza@ -----
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --------------------------
>> >> > E-mail Seguro Vetorial.net
>> >> >
>> >> > Mensagem classificada como NÃO-SPAM. Para classificar como SPAM,
>> >> > encaminhe para spam@
>> >> >
>> >> > Chave de Identificação: 49321,46efef98136511741916316
>> >> >
>> >>
>> >>
>> >> ----- Final da mensagem de aleksandrosouza@ -----
>> >>
>> >
>> >
>> >
>> >
>> > --------------------------
>> > E-mail Seguro Vetorial.net
>> >
>> > Mensagem classificada como NÃO-SPAM. Para classificar como SPAM,
>> > encaminhe para [EMAIL PROTECTED]
>> >
>> > Chave de Identificação: 49321,46eff636202381854714530
>> >
>>
>>
>> ----- 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,46effa97202386814575248
>
----- Final da mensagem de [EMAIL PROTECTED] -----
