[oracle_br] Re: ResultSet em UTF-8
Infos adicionais, que podem te ser úteis : 1. uma vez checado que a versão de tool cliente que vc tem Aceita/Suporta UTF-8, além de setar os parâmetros NLS no client Oracle (normalmente via variáveis de ambiente NLS_LANG), pode haver algum setting adicional a mais que vc necessite fazer na própria tool 2. se a tool for uma GUI, é ** Crítico ** que vc use uma Fonte Truetype *** compatível *** com UTF-8 : no Windows normalmente fontes como a Tahoma são 3. algumas tools só suportam UTF-8 ** sem ** o BOM (Byte Order Mark), ou seja, os 3 bytes iniciais (OPCIONAIS no caso de UTF-8, vide http://pt.wikipedia.org/wiki/Marca_de_ordem_de_byte para refs) que indicam a Codificação - *** CONFIRME *** se a tool que vc escolheu gera ou não o BOM e *** VERIFIQUE *** se a aplicação que vai receber teu arquivo UTF-8 exige ou não o BOM Caso a tool não gere o BOM mas a aplicação/ambiente que vai receber teu arquivo exija, talvez vc tenha que o inserir manualmente []s Chiappa
[oracle_br] Standard to Enterprise
Pessoal, Tenho um banco 10g (10.2.0.4) Standard e quero migrar para Enterprise (10.2.0.4) para outra maquina. Minha ideia seria fazer o shutdown immediate, e copiar os arquivos (datafiles, controlfile, etc...). A estrutura de diretório será a mesma. Minha duvida é, se preciso efetuar o startup de forma diferente, e depois executar algum script. Grato, Ednilson
[oracle_br] problema replicação goldengate
Boa Tarde a todos como verifico se a replicação do goldengate está ok e caso não esteja como reativa-la?? obrigado
[oracle_br] Re: Move de tabelas
Bom dia Chiappa! Valeu pelas dicas... Chiappa, vou te passar aqui o meu cenário para que você possar verificar: A tablespace xxx_dados, guarda as 5 tabelas grandes que eu necessito deletar, e mais 62 tabelas. Então como preciso deletar os dados das tabelas grandes e liberar o espaço em disco ocupado por elas, estou fazendo o seguinte procedimento: 1) criar uma tablespace nova xxx_dados_aud; 2) criar 5 tabelas novas na xxx_dados_aud idênticas as tabelas que eu preciso deletar(PK/FK/Index etc criados no final do processo de insert); 3) fazer insert nas tabelas novas a partir de um select nas tabelas antigas, copiando todos os dados que eu necessito manter no banco; 4) Após dados copiados para as novas tabelas, dar um truncate/drop nas tabelas antigas; 5) Renomear as novas tabelas, criadas no passo 2, para o mesmo nome das tabelas antigas, e todas as suas referencias, 5) Criar outra tablespace xxx_dados2; 6) Mover as outras 62 tabelas para a segunda tablespace criada xxx_dados2; 7) dropar a tablespace antiga, xxx_dados; 8) Renomear a tablespace xxx_dados2 e seus datafiles para o mesmo nome da tablespace antiga; Estou fazendo este procedimento, pois se eu apagar as tabelas antigas e não fazer o move, não consigo liberar todo o espaço em disco, mesmo utilizando o SHIRINK,COALERCE, DEALLOCATE, é retornado o erro ORA-03297: o arquivo contém dados usados além do valor solicitado de RESIZE. Isso se dá pois tenho dados nos datafiles que estão com o high water mark a frente dos dados que foram apagados, pois tenho os dados das outras 62 tabelas, que é atualizado constantemente. Com isso eu irei manter estas tabelas grandes e que tem um crescimento grande, na nova tablespace xxx_dados_aud, para não passar pelo trabalho de mover todos os demais objetos de um lado para outro, caso venha a ser necessário realizar este procedimento novamente. O que estou pensando em fazer, é realizar o move das tabelas de forma gradativa, sem parar as aplicações na madrugada. Pois na madrugada o acesso as aplicações são poucas e se a aplicação tentar acessar a tabela que esta sendo movida, a mesma ira estar locada. Desta forma meu dowtime seria menor. O meu medo é que corrompa algo no momento do move, com as aplicações tentando acessar a tabela em movimento, mesmo tendo o lock de DML quando se realiza o move da tabela. Porém para que eu faça isso com as aplicações no ar, tenho que ter a certeza de que a rotina da aplicação não ira perder nenhum dado, após tentar acessar a tabela em movimento e não conseguir.
[oracle_br] Re: Standard to Enterprise
Claro que sim, pois o dicionário/catálogo interno de um database possui colunas/tabelas diferentes de acordo com a Edição em uso, além da versão... Assim, seguindo a nota metalink How to Convert Database from Standard to Enterprise Edition ? (Doc ID 117048.1) é basicamente uma questão de se ter o software EE, subir o banco que era Standard com eles mas ainda indisponível, e então recriar o catálogo com os scripts da home EE... Mas eu pessoalmente, a não ser que a janela de manutenção exígua e/ou tamanho/complexidade do database impossibilitem, optaria mesmo é pelo método 100% seguro, ie : criar um novo database vazio com os binários EE e depois transferir os dados do Standard para o Enterprise , seja via export, INSERT append-mode com database link, arquivo-texto, o que puder... []s Chiappa
[oracle_br] Trigger de Logon.
Boa tarde! Meu oracle é: banner full_version version_bit ARQUIVAMENTO - -- - Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 10.2.0.3.0 10.2.0.3.0 - 64bi STARTED Caros amigos, estou precisando de uma trigger de logon que: A) permita acesso ao banco apenas do sistema web desenvolvido; B) permita acesso ao banco apenas dos form´s e report´s; C) que boqueie programas de desenvolvimento tais como: '%TOAD%'-- Toad; '%T.O.A.D%'-- Toad; '%SQLNAV%'-- SQL Navigator; '%PLSQLDEV%'-- PLSQL Developer; '%BUSOBJ%'-- Business Objects; '%EXCEL%'-- MS-Excel plug-in; '%SQLPLUS%'-- SQLPLUS; '%DEVELOPER%'-- Oracle SQL Developer; '%IFBLD%'-- Oracle Forms Developer Builder; '%RWBUILDER%'-- Oracle Reports Builder; '%RAPTOR%' entre outros; D) que permita acesso aos programas acima relacionados na alínea 'C' apenas para os usuários relacionados, ou ainda, máquinas relacionadas (IP´s). Caso alguns dos amigos possuam uma trigger do tipo ou mais estruturada ainda, caso possam ajudar-me, ficaria bastante grato. Tenho que implementar esta rotina na minha plataforma, já pesquisei algumas trigger´s de logon mas nenhuma que fosse completa ou que se adequasse ao meu cenário, assim, gostaria da ajuda dos amigos os quais possuem uma maior experiência com a administração do Oracle. Obrigado... Atenciosamente, [image: Foto Cristiano Vasconcelos Barbosa] *Cristiano Vasconcelos Barbosa.'.* * Analista de Sistemas Banco de Dados* | Cel: +55 (85) 9691.8331 -- http://br.linkedin.com/in/cristianovasconcelos *DEUS MEUMQUE JUS*.'. *DÓMINI SUMUS*.'. Contact me: [image: Google Talk] cvasconcel...@gmail.com [image: Skype] cvasconcelosb [image: MSN] cvasconcel...@hotmail.com [image: Y! Messenger] cvasconcel...@yahoo.com.br [image: My QR VCard] http://s.wisestamp.com/links?url=http%3A%2F%2Fbr.linkedin.com%2Fin%2Fcristianovasconcelossn=Y3Zhc2NvbmNlbG9zYkBnbWFpbC5jb20%3D
[oracle_br] Re: Move de tabelas
Ok... Bom, a primeira pergunta que te faço é : vc TEM CERTEZA que as tabelas que seguram o espaço que hoje está em branco/não está em uso mas reservado ** REALMENTE ** nunca mais vão sofrer carga de dados ??? O ponto aqui é que NATURALMENTE o espaço sem uso mas reservado VAI SIM ser reusado automagicamente nos próximos INSERTs (INSERTs normais, em não-append mode) : se depois de todo o trabalho acontecer de vc não sabia que semana que vem vai haver uma carga grande de dados aí as tabelas crescem tudo de novo, foi INÚTIL o seu trabalho todo ... Yep ?? Segunda pergunta : vc quer/precisa que esse espaço hoje sem uso mas reservado REALMENTE seja devolvido ao Sistema Operacional (para ser usado alhures) OU simplesmente ter esse espaço constando na DBA_FREE_SPACE dessa mesma tablespace (e portanto podendo ser reusado por qquer Segmento dessa tablespace) ?? Pois se for necessário devolver o espaço ao SO (via RESIZE do datafile, deleção do datafile, etc) realmente vc precisará MOVER os blocos, mas se vc ter esse espaço (ou a maior parte dele) disponível como FREE para essa tablespace já resolve, vc ** PODE SIM ** usar o SHRINK mas com a opção COMPACT depois de ter inserido nalgum outro lugar os dados que quer salvar e feito o TRUNCATE das tabelas envolvidas : veja https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:153612348067 como ref Esse link mostra SIM que é Totalmente possível se liberar espaço via SHRINK mesmo com blocos em branco no meio.. Só mesmo se REALMENTE vc precisa diminuir fisicamente os datafiles é que vc vai ter que apelar para o Procedimento que vc descreve, e com as seguintes ressalvas : 1) criar uma tablespace nova xxx_dados_aud; 2) criar 5 tabelas novas na xxx_dados_aud idênticas as tabelas que eu preciso deletar(PK/FK/Index etc criados no final do processo de insert); 3) fazer insert nas tabelas novas a partir de um select nas tabelas antigas, copiando todos os dados que eu necessito manter no banco; == iirc vc tá usando a Standard Edition, onde não há Parallel SQL, então esse INSERT não poderá ser paralelizado E a busca dos dados a serem salvos/inseridos nas tabs de trabalho também não poderá ser paralelizado: vc TEM que usar então INSERT em APPEND-MODE, BULK ARRAY, Paralelismo DIY e etc onde possível 4) Após dados copiados para as novas tabelas, dar um truncate/drop nas tabelas antigas; == Muito certamente TEM que ser TRUNCATE, pois como dito anteriormente com o DROP vc PERDE as contsraints, permissões/grants que haviam sido feitas anteriormente, perde os objetos secundários da tabela (como ÍNDICES) OK ? E muito provavelmente vc terá que DESABILITAR temporariamente as FKs relacionadas, pois o RDBMS não deixa vc fazer TRUNCATE com FKs habilitadas. Este último ponto é importante : enquanto vc estiver com as FKs desabilitadas, ÓBVIO que vc não vai deixar as aplicações fazerem DMLs, pois podem entrar dados inválidos : pra isso vc vai ter que aplicar manualmente um LOCK nas tabelas e/ou temporariamente revokar os privs de DMLs.. Tecnicamente pra consulta tudo bem (já que a ESTRUTURA das tabelas, ie, colunas/datatypes, não está mudando) - só o que vai acontecer é que os dados que foram Consultados antes do TRUNCATE ** obviamente ** não mais estarão presentes depois dele para serem localizados e alterados, mas a Query que estiver rodando não vai ter problemas... 5) Renomear as novas tabelas, criadas no passo 2, para o mesmo nome das tabelas antigas, e todas as suas referencias, = Não : justamente pra não ter que se preocupar com referências, a idéia é inserir (em append-mode e do jeito mais rápido possível) os dados que estão nas tabelas xxx_aud nas tabelas xxx originais que estão VAZIAS, e depois aí sim SE necessário mesmo o RESIZE, aí vc move essas tabelas que eram grandes mas que agora estão com POUCOS dados 5) Criar outra tablespace xxx_dados2; 6) Mover as outras 62 tabelas para a segunda tablespace criada xxx_dados2; 7) dropar a tablespace antiga, xxx_dados; 8) Renomear a tablespace xxx_dados2 e seus datafiles para o mesmo nome da tablespace antiga; = Aqui ficou uma dúvida : essas 62 tabelas (que são pequenas, pelo que entendi) não precisam sofrer qquer tipo de DELETE, correto ? Se sim OK, em sendo necessário o RESIZE do datafile vc as vai mover Observo apenas que, se for Enterprise Edition, o database já permite que essa movimentação seja feita ONLINE, mas se for Standard Edition aí não.. O que estou pensando em fazer, é realizar o move das tabelas de forma gradativa, sem parar as aplicações na madrugada. Pois na madrugada o acesso as aplicações são poucas e se a aplicação tentar acessar a tabela que esta sendo movida, a mesma ira estar locada. Desta forma meu dowtime seria menor. O meu medo é que corrompa algo no momento do move, com as aplicações tentando acessar a tabela em movimento, mesmo tendo o lock de DML quando se
