Olá Silvio, Realmente você está preenchendo o service name incorreto na maquina cliente ou nem está passando. mande para gente o tnsname de um dos clientes e mande tb o listener.ora do servidor para agente bater as informações. Ou voce mesmo pode fazer isso. É só verificar se o servicename do ser tnsnames.ora está no listener.ora do servidor. Se isso não resolver, pode ser problema de rede. - Verifique se a máquina cliente enxerga a máquina servidora. - Verifique se o banco está ativo no servidor - Verifique se o listener está ativo no servidor. Bom... se não resolver, poste de novo para continuarmos as possibilidades. Abraços
-----Mensagem original----- De: oracle_br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Silvio Cesar Feitoza Enviada em: segunda-feira, 16 de abril de 2007 12:46 Para: oracle_br@yahoogrupos.com.br Assunto: [oracle_br] Conexão com o banco Caros amigos Estou com uma dificuldade que a seguinte... Tenho um banco que foi instalado em uma maquina servidora e outras maquinas prescisam acessar esse banco... A rede funciona normalmente e via acesso remoto eu consigo acessar o banco, porem não consigo efetuar a configuração da rede para que o acesso fique de cliente / servidor... Detalhe foi instalado nas maquinas o cleint e configurado o tnsname quanto tento logar via maquina aparece o erro --> ORA - 12514: TNS:listener não pode resolver o service name fornecido no descritor de conexão... Deve esta esquecendo de algum parametro - Alguem poderia ma ajudar... jlchiappa <HYPERLINK "mailto:jlchiappa%40yahoo.com.br"[EMAIL PROTECTED]> escreveu: Não é OLTP o meu banco, mas vamos ver até onde consigo te ajudar . Por partes : primeiro, embora a Oracle não tenha uma recomendação exata para isso, a documentação envolvida são os manuais de Concepts e de Tunning, e no metalink principalmente a nota nro 46757.1 "Notes on Choosing an Optimal DB BLOCK SIZE" . Depois, tendo os conceitos referentes à essa atividade bem claros (se não os tem, re-estudo das fontes citadas), vamos pensar juntos - a vantagem principal de um bloco maior é que vc popupa I/O, no seguinte esquema : suponha um banco (ou uma tablespace, no 9i) com blocksize de 8 Kb e uma aplicação que frequentemente necessita de dados de vários e vários blocos, se vc precisa (digamos) de dados de dois blocos o bd teve em tese (ignorando os casos de multiblock read) que fazer dois I/Os, e já que cada I/O implica (em tese) em espera por seek time, por rotação de disco, etc, se essa operação fosse feita com blocksize de 16 Kb vc fez um único I/O, poupou-se algum tempo, às vezes até coisa de alguns pontos percentuais. =====>>> PORÉM, notar que estamos falando de economia em cima duma operação que custa *** MILISEGUNDOS **, obviamente uma aplicação teria que fazer MUITO e MUITO I/O pra que essa "economia" seja notável, alguns % de uns tantos milisegundos normalmente é coisa ** DESPREZÌVEL ** ... O segundo efeito (também citado e deduzido das docs citadas) é que, como os caches do bd são criados/mantidos em RAM e controlados via latches e similares, certamente se vc tiver um bloco maior menos blocos serão necessários para se controlar a mesma qtdade de RAM, portanto menos listas de controles, menos latches, etc, seriam necessários em tese, MAS novamente só mesmo em caches ** enormes ** vc veria alguma diferença.... E não esquecendo que a cada release o bd se torna mais eficiente na administração desses caches, o algoritmo está constantemente melhorando, também.. Então, à vista do acima citado, eu penso que em sendo OLTP nada disso se aplicaria muito : em OLTP é bem menor que em DW a chance da aplicação precisar de infos que com bloco maior cairiam no mesmo bloco (oltp é tipicamente bem aleatória a recuperação de dados), e ainda por cima em oltp por maior que seja a base atual, tipicamente vão ser recuperados via índice relativamente POUCO disso, relativamente pequenas FRAÇõES do todo.... Óbvio ululante, vc VAI testar antes no seu banco de testes/homologaçã-o, principalmente a chance de se ter os índices em bloco maior, mas acho que muito provavelmente os seus testes aí serão negativos...-. Em sendo CPU o seu principal problema e sistema oltp (onde são queries relativamente simples, com poucos dados retornados MAS com enorme massa de usuários fazendo operações similares) , acho que a estratégia de ataque seria ** mesmo mesmo ** é na aplicação, se ASSEGURANDO que a aplicação faz 1 parse e vários executes, usa bind variables, NÃO faz context switch, NÃO usa & abusa de loops e cursores aonde o processamento poderia ser feito num SQL só, NÃO chama dentro do SQL functions PL/SQL... Via de regra essas coisas QUEIMAM CPU , detonam, comem-na no café da manhã, é a primeira coisa que teria que ser vista... []s Chiappa --- Em HYPERLINK "mailto:oracle_br%40yahoogrupos.com.br"[EMAIL PROTECTED], "logg" <[EMAIL PROTECTED]> escreveu > > blz, até aqui tudo bem, > já tinha visto isto, tanto é que minha suspeita é esta, pois meu storage é um cavalo e com isto não tenho problemas de I/O , tendo problemas sim de processamento da maquina, chegando a dar 100% dos 15 processadores.-.. > > > > > De:HYPERLINK "mailto:oracle_br%40yahoogrupos.com.br"[EMAIL PROTECTED] > > Para:HYPERLINK "mailto:oracle_br%40yahoogrupos.com.br"[EMAIL PROTECTED] > > Cópia: > > Data:Sun, 15 Apr 2007 11:05:06 -0300 > > Assunto:Re: [oracle_br] Blocagem diferente no Oracle > > Acho que este aqui pode ser interessante, > > HYPERLINK "http://www.dba-oracle.com/art_dbazine_9i_multiblock.htm"http://www.dba- -oracle.com/-art_dbazine_-9i_multiblock.-htm > > logg escreveu: > > > > Senhores, ja li muito a respeito disso no Oracle, agora oq peço é a > > experiência de vcs, alguém utiliza isto em ambiente OLTP?? > > Tenho um banco grande, coisa de uns 5TR, minhas tabelas estão > > desnormalizadas, tenho tabelas com coisa de 250 campos e tudo isto com > > blocagem default do oracle. A minha idéia seria criar uma tablespace > > com uma blocagem maior e mover estas minhas tabelas com grande > > quantidade de campos para lá para ver se consigo um aumento na > > performance e diminuindo assim a grande leitura de blocos . > > Alguém tem alguma documentação sobre este tipo de aplicação em > > ambiente OLTP ?? > > > > vlw > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > -- > Atenciosamente, > > Rodrigo Mufalani > OCA 10g > tel.: 91739169 > > > > > > [As partes desta mensagem que não continham texto foram removidas] > ____________-_________-_________-_________-_________-__ Fale com seus amigos de graça com o novo Yahoo! Messenger HYPERLINK "http://br.messenger.yahoo.com/"http://br.messenger-.yahoo.com/ [As partes desta mensagem que não continham texto foram removidas] -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/745 - Release Date: 3/4/2007 12:48 -- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.25/745 - Release Date: 3/4/2007 12:48 [As partes desta mensagem que não continham texto foram removidas]
