Re: [oracle_br] Re: enq: HW - contention
A questão dos LOBs é que embora eles realmente tenham limites máximos altíssimos, as linguagens utilizadas no RDBMS (ie, SQL e PL/SQL) possuem limites menores para o tanto de informação que conseguem enviar/receber do database de uma só vez (varia de acordo com a versão, mas normalmente é de 4000 bytes para SQL e 32767 para PL/SQL) : assim sendo, vc tem que ** quebrar ** a informação a receber/enviar de/para os seus LOBs em pedaços de tamanho adequado, okdoc ? Portanto sim, vc pode ter trocentros gigabytes no teu LOB no total, mas lidos/gravados de 4000 em 4000 bytes de cada vez (ou de 32767 em 32767 bytes de cada vez, se for PL/SQL) certo ? Em cima disso, o que o Analista está supondo pelo que entendi é que a tua aplicação está usando as APIs da linguagem SQL e por falha de programação em alguns casos ao invés de enviar pro banco pedaços de 4000 bytes está enviando pedaços de 4001 bytes, E por bug do RDBMS ao invés de rejeitar o pedaço de comprimento inválido ele está dando ORA-600, é isso Se for uma aplicação desenvolvida in-house, Confirme com os programadores se eles estão usando a metodologia apropriada ao trabalhar com LOBs, enviando um pedaço de cada vez da informação, E se for aplicação de fornecedor, acione o Suporte do fornecedor para verificar se eles tem notícia de bug desse tipo na Aplicação Outra ação que pode ser MUITO esclarecedora é vc pedir um TRACE (sem tkprof, só o trace bruto) de uma execução e enviar isso pro Suporte - lá fica registrado direitinho cada operação que a aplicação fez no banco - , ou mesmo (com a Ajuda do Suporte Oracle) ativar um evento que gere dump na inserção de um LOB Com essas ações vc Comprova ou Rejeita a Suposição do analista da Oracle... []s Chiappa OBS : outra coisa que vc pode fazer é testar por corrupção nesses LOBs - procure no metalink por LOB CORRUPTION que vc acha algumas notas com procedimentos para isso. ---Em oracle_br@yahoogrupos.com.br, raffaell.t...@yahoo.com escreveu: Chiappa, obrigado pelas ficas, ja homologuei o procedimento no database de homologação do SECURE FILES, enquanto isso recebi uma resposta do Suporte da Oracle no qual fiquei sem entender, poderia me ajudar? Eles falaram o seguinte: From the supplied trace files here, this looks to be a problem in the application code, in that it is attempting to update a column with a value greater than the maximum defined length of the column. For example, we see the failing statement as: UPDATE TABELA_XUXA SET DTEXP = :DTEXP , DTIMP = :DTIMP , INDEXP = :INDEXP , INDIMP = :INDIMP , TXT = :TXT , TXTWORD = :TXTWORD , TXTPDF = :TXTPDF WHERE CODDOC = :CODDOC AND NUMSEQ = :NUMSEQ AND CODLOCALRESP = :CODLOCALRESP In the bind values for this we see bind number 4 which equates to the 'TXT' column as being defined as a VARCHAR2 of length 4000 bytes, but the actual bind variable length is 4001 bytes, and so this overflows the column and hence corrupts the subsequent lob column. Therefore you need to correct the application code so that it uses a character value of 4000 bytes or less. Eu dei um desc na tabela_XUXA e a mesma me trouxe o seguinte: Name Null?Type - CODDOCNOT NULL NUMBER(10) NUMSEQNOT NULL NUMBER(4) TXTCLOB TXTWORDBLOB CODLOCALRESP NOT NULL NUMBER(4) DTEXP DATE DTIMP DATE INDEXP VARCHAR2(1) INDIMP VARCHAR2(1) TXTPDF BLOB INDVOTOVISTA VARCHAR2(1) INDVOTOCONDUTORVARCHAR2(1) O campo TXT é CLOB, e não VARCHAR2 como o atendente da Oracle falou acima, e o tamanho máximo suportado por uma coluna do tipo CLOB e BLOB é de 8TB, me corrijam se estiver errado. Não sei se esse exemplo que o rapaz deu, é um exemplo fictício para tentar demonstrar o que está ocorrendo, mas se tratando de um campo LOB, acho difícil alguém conseguir atualizar um dado maior do que uma coluna do tipo LOB suporta. Em Quarta-feira, 7 de Maio de 2014 14:14, jlchia...@yahoo.com.br jlchia...@yahoo.com.br escreveu: Bom, eu acho que vc tem duas questões diferentes em mãos - causalmente aconteceram no mesmo timeframe, mas pode muito bem ser que não estejam relacionadas com causa e efeito, ie : que o ORA-600 foi foi causado por
Re: [oracle_br] Re: Preço Rotina de backup
Marcelo, funciona assim : na nossa área de TI, o balizador principal de preço ainda é mesmo o valor-hora do trabalho, ok ? No caso, ao que entendo é um ambiente simples, com demanda de média pra menos, e sem complexidades, então acho que vc deveria usar o valor-hora de DBA Pleno : querer cobrar valor-hora de DBA Sênior para uma atividade que não demanda conhecimentos avançados é esfolar o cliente, não é um procedimento profissional, tanto quanto querer cobrar um preço vil, certo ?? veja na sua região, mas aqui em SP tenho visto como custo para DBA Pleno algo em volta de R$50 a R$60, pouco mais pouco menos Encontrado o valor-hora apropriado, é somar a quantidade de horas que vc gastou no levantamento do ambiente deles, a qtdade de horas que gastou no desenho da solução, a quantidade de horas que gastou no treinamento (já que são eles que vão executar/monitorar a rotina e os resultados, ao que entendi) E a quantidade de horas que vc gastou no teste de backup E no de restore (backup sem um teste de restore que seja sorry, não é backup imho) E um ponto adicional : tem experts que acham que não se deve, mas eu gosto de jogar bem aberto com meus clientes, então eu mostro pra eles a lista detalhada de quantas horas serão/foram gastas em cada item, além do preço geral que é a soma de cada uma delas, okdoc ??? []s Chiappa
Re: [oracle_br] Troca de idéias: Alguém par ou de usar AWR e passou a usar STATSPACK em 1 0g/11g ?
Roland, a minha experiência em substituir o AWR (e seus amigos, como ASH e Advisors) pelo statspack está um tanto defasada (já há alguns anos eu não mexo com ele, então pode ser que algumas das obs que vou fazer mudaram) , mas foi bem diferente do que vc fala : existem Sim diferenças gritantes entre AWR/ASH x Statspack... O busílis é que PODE SER que vc não esteja usando as features/recursos/tools que o AWR/ASH dão e o statspack não dá (aó Óbvio que a transição vai ser suave) mas se estiver fique sabendo que VAI SIM haver problemas, e que provavelmente vc (ou o DBA do cliente, enfim, alguém) ** VAI ** ter que escrever algo para satisfazer, esteja certo de contabilizar esse tempo/esforço De modo geral : a) o statspack não é habilitado por default, nem tem as coletas agendadas automaticamente, requerendo ação do DBA para setup E para agendar as coletas b) statspack não armazena históricos, é por sua conta criar uma rotina de arquivamento de históricos, no estilo de http://www.oraclerealworld.com/ash-masters/ : isso implica também que sem essa customização adicional, análises do tipo comparar planos de execução anteriores com boa performance versus plano atual que piorou, ou impacto no database depois da nova versão x da aplicação não são viáveis... c) statspack só faz coletas ONLINE e não sobrevive a reboots/restarts do banco, Exigindo que o banco absolutamente não tenha sido parado no intervalo entre dois snapshots d) afaik statspack basicamente *** parou no tempo *** na versão 9ir2, a esmagadora maioria das novas estatísticas de performance introduzidas no 10g (como por exemplo a informação de I/Os extraída do SO, o plano de xecução Extendido - ie, colas A-ROWs e E-ROWS, por exemplo -, as estatísticas de SQl adicionadas ás views relacionadas à V$SQL, etc), e das novas técnicas de análise (como TIME MODEL, por exemplo) NÂO SÃO SUPORTADAS no statspack... Deixo sem comentar as capacidades do 11gr2 que o statspack não suporta, já que não tive a chance de comprovar num banco 11g , mas certamente imagino que devem ser basicamente todas e) statspack basicamente desconsidera as estatísticas de performance/waits referentes a RAC, e é single-instance : em caso de RAC é por sua conta rodar um report de statspack em cada nó f) afaik o statspack não permite análise a nível de SQL, ao contrário do AWR que o permite via e o mais impactante : ao não licenciar o diag pack, além de perder o AWR/ASH vc perder também os ADVISORS : ok que nem sempre eles te salvam a cara mas algumas vezes dão sim recomendações eventualmente úteis, e coisas que vc não tinha pensado Neste último caso, aí não há outra solução que não implementar manualmente a expertise do DBA nalguma rotina escrita por vc (ou pelo DBA do cliente, enfim) que Simule ações do tipo das que os Advisors fazem... []s Chiappa
Re: [oracle_br] Troca de idéias: Alguém par ou de usar AWR e passou a usar STATSPACK em 1 0g/11g ?
Só adicionando, algunmas refs que reportam mais ou menos isso que eu disse, e dão alguma visão histórica do que veio de novo no AWR 10g e 11g (e que afaik o statspack não cobre, já que como eu disse iirc ele + ou - tá parado no 9ir2, logicamente falando) são : http://arjudba.blogspot.com.br/2008/08/difference-or-advantage-between-awr-and.html , http://www.remote-dba.net/oracle_10g_tuning/t_awr_statspack_statistics_comparison.htm , http://www.databasejournal.com/features/oracle/article.php/3861876/When-Tuning-Oracle-is-not-an-Option.htm e http://www.oracle-base.com/articles/10g/automatic-workload-repository-10g.php []s Chiappa
[oracle_br] Re: Dúvidas sobre concessão de privilégios
Opa, seguinte :
para 1), pode consultar os manuais de Administração que vc vai ver que não
existe não um GRANT com um SCHEMA como recebedor... O que vc faria, se não
quisesse ter uma ROLE como recebedora (e aí todos os usuários interessados
teriam acesso via role) é realmente executar os comandos todos necessários uma
um, provavelmente com um script tipo :
select 'GRANT ' || case when object_type = 'SEQUENCE' then 'SELECT'
when object_type = 'TABLE' then
'lista_de_privs_para_tabelas'
when object_type = 'VIEW' then
'lista_de_privs_para_views'
when object_type = 'DIRECTORY' then 'READ,WRITE'
when object_type in ('PROCEDURE', 'FUNCTION',
'PACKAGE') then 'EXECUTE'
end
|| ' ON '
|| owner || '.' || object_name
|| ' TO usuario_destino'
|| ';'
from dba_objects where owner=upper('usuario_modelo')
and OBJECT_TYPE in ('TABLE', 'VIEW', 'SEQUENCE', 'PROCEDURE', 'FUNCTION',
'PACKAGE', 'DIRECTORY');
select 'CREATE SYNONYM user_destino' || '.' || object_name || ' FOR ' || owner
|| '.' || object_name || ';'
from dba_objects where owner=upper('usuario_modelo')
and OBJECT_TYPE in ('TABLE', 'VIEW', 'SEQUENCE', 'PROCEDURE', 'FUNCTION',
'PACKAGE', 'DIRECTORY');
para a pegunta 2), vc não diz mas entendo que vc quer conceder para um usuário
qualquer compilar objetos PL/SQL que ** não pertencem ** a ele, correto ? Sendo
isso, é necessariamente conceder os privs de ANY , ou (muito melhor) criar um
stored procedure no schema dono dos PL/SQLs que faça o DDL desejado (** E **
também faça alguma auditoria/grave algum log/faça as necessárias verifs de
segurança), e depois conceder priv de EXECUTE nessa procedure a quem dele
precisa...
[]s
Chiappa
[oracle_br] Exemplo de abuso de segurança usando privilégios ANY
Pessoal, eu pensei bastante antes de disponibilizar publicamente mas como a informação já anda nas interwebs já há bastante tempo (e aqui no Fórum já malhamos *** INSISTENTEMENTE *** , muitas e muitas vezes, que privilégios ANY são um rombo horrível, terrível e pavoroso de segurança - e além disso com o poder de des-estabilizar um database num micro-segundo, já que ANY quer dizer qualquer um, INCLUSIVE o schema SYS , o SYSTEM ou um dos schemas usandos internamente, como o DBSNMP, digamos) , achei que era positivo e que quem está vulnerável já foi avisado há muuuito tempo muuuitas vezes, então segue o link de um artigo interessante que recebi hoje exemplificando alguns hacks via privilégios ANY : http://www.red-database-security.com/wp/best_of_oracle_security_2013.pdf []s Chiappa
[oracle_br] Re: Erro intermitente na execução de PL/SQL
Eu penso que as 3 infos Críticas e necessárias para palpitar em cima e que vc não dá seriam : a) as mensagens EXATAS e o Comportamentos de erro que acontecem b) confirmar se a conexão que o aplicativo abre é DEDICADA ou SHARED, e se há algum tipo de pool de conexão envolvido c) detalhamento do middleware e do método de conexão ao banco envolvido, incluindo versões (do middleware, dos drivers, etc) E um curtíssimo exemplo de conexão tal como a que o programa faz Com esse retorno dá pra dizer algo mais concreto, mas de cara posso dizer que se é um erro que só ocorre fora da aplicação, pra mim : OU existe alguma tela da aplicação que faz algo (exemplo, sinalizar uma variável global) que força a lógica a cair num IF que quando vc executa pela tool cliente não é ativado, OU alguma tela anterior da aplicação tá fazendo alguma coisa errada e o erro tá estourando na tela que chama a tal rotina, (aí tal erro não ocorre quando vc chama a rotina numa tool cliente), OU há algum bug no middleware e/ou nos drivers/código da Aplicação (digamos, incompatibilidade de tratamento/datatypes,retorno, etc que a tool cliente não tem mas a aplicação tem), ou derivações... Manda a informação, e depois se ninguém que programe/conheça vb puder dizer nada, aí é mesmo um trabalho de DEBUG, mesmo... []s Chiappa
[oracle_br] Re: replicação x licenciamento
Eu te daria duas dicas : a. se a replicação dessa tal tool é por blocos em disco, obtenha ** POR ESCRITO ** do fornecedor da ferramenta que ela ** REALMENTE ** controle / locka os discos, que ela garante integridade dos blocos replicados, esteja o database primário/principal ONLINE ou OFFLINE, em archivemode ou não, não importando se não hora da réplica houve ou não checkpoint e b. já que vc usa VMWARE, muito certamente não deve estar usando o Suporte da Oracle, usando ao invés o Suporte da vmware ou de algum parceiro : CERTIFIQUE com seja quem for que está Suportando o ambiente que essa tal tool é Homologada Quanto à questões de licenciamento, não vejo problema nenhum SE o ambiente de standby em operação normal está down (não é read-only, não é idle, é DOWN mesmo, desligado, totalmente inacessível, banco fechado e instãncia fora do ar e/ou não abrindo database nenhum), só realmente subindo quando o primário parar : já que a licença de uso não é amarrada por servidor, sem probs nesse cenário acima... []s Chiappa
[oracle_br] Re: Patch number - Oracle 12c
Complementando : no seu caso do 12c, aonde vc só tem a base version, se vc quiser baixar essa versão-base em pacotes/pedaços separados (por exemplo, apenas os arquivos do client, ou apenas os arquivos do core do RDBMS, etc) não há problema : tanto o technet (use o link See all na página de download) quanto o e-delivery (escolhendo o Product Pack Oracle Database e a sua plataforma em uso) permitem isso... []s Chiappa
[oracle_br] Re: ORA-01555: snapshot too old: rollback segment number with name too small
Tudo jóia ? Então, primeiro sobre o tipo e detecção da corrupção, é isso mesmo : o backup (full ou não, mas backup real, envolvendo cópia de arquivos do database) somente lê blocos do disco, portanto só detecta corrupção FÍSICA, aonde vc recebe um erro unable to read ou unable to write bloco tal - erros aonde a gravação/leitura do bloco foi feita sem erros de disco mas o dado gravado está inválido são os Lógicos, e isso somente tools que interpretam os dados podem detactar, tal como o export... Assim sendo, no seu checklist/procedimentos para detectar corrupção, vc TEM que ter além do backup um VALIDATE DATABASE pelo RMAN, um DBVerify , um export, sim. E claro, dentro do viável/possível um IMPORT de vez em quando dos dados exportados é Excelente adição no procedimento... Antes de mudar de assunto, adicionalmente se o seu database é crítico e não está com gargalo de performance insuportável (ie, vc tem ainda alguma capacidade de processamento a alocar) a Sugestão é vc ativar os checksums de bloco : isso Implica em overhead mas te dá Muito mais capacidade de detectar corrupções de qquer tipo o mais cedo possível... Isso posto, o teu primeiro passo deveria ser achar QUEM está causando essa corrupção lógica : a nota metalink que vc cita dá uma possibilidade, mas a nota Master Note - RDBMS Large Objects (LOBs) (Doc ID 1268771.1) lista na seção ORA-1555 on LOBs / LOB Corruption mais algumas possíveis, vc TEM que abrir um Chamado no Suporte Oracle e passar essas refs para o Analista da Oracle - só ele pode dizer qual delas se encaixa , ou mesmo se nenhuma se encaixa... E é Claro, se vc tá usando LOB de qualquer tipo no 11gr2 vc DEVERIA estar usando SECUREFILES, eles apresentam diversas vantagens sobre os BASICFILES, até pode ser que a tua situação não esteja mais ocorrendo com SECUREFILES, veja lá... Sobre recuperação do registro corrompido, isso depende : primeiro, fosse um volume que justificasse , a Oracle (e alguns parceiros) oferecem serviços de consultoria em recuperação de dados aonde eles usam tools capazes de extrair informação diretamente dos datafiles - porém, julgo que isso não é viável em termos de Custo dado que é tão pouca informação Assim, penso que a sua alternativa (SE for um CLOB, contendo caracteres, E SE vc não tiver nenhum tipo de encriptação envolvido) seria vc identificar quais bloocos podem conter a informação e pedir um DUMP desses blocos Afora isso, não vejo outra opção que não seja volta de backup antes da corrupção... []s Chiappa
[oracle_br] Re: Job não executa
E uma perguntinha adicional : vc tem ABSOLUTA e TOTAL CERTEZA que a rotina a ser executada pelo JOB é mesmo (e vai SEMPRE ser, independente do crescimento de dados) tão simples e rápida que REALMENTE vai terminar sempre em poucos segundos ? Pois os jobs são controlados por um QUEUE, que tem um número Máximo de execuções simultâneas , no instante que começar a demorar mais as execuções vão se encavalar e rapidinho vc esgota o queue, aí cada vez mais execuções vão ficar pendentes , vai acumulando Eu realmente diria para vc QUESTIONAR SERIAMENTE esse schedule de 30 segundos - pra mim, de modo a se ter folga suficiente para o queue de jobs poder ser atendido seguramente, eu consideraria NO MÁXIMO execução a cada minuto, ou (melhor) a cada 5 minutos, e isso SE realmente for algo simplíssimo []s Chiappa
Re: [oracle_br] Re: Bigfile Tablespace
Fabio, o Aviso sobre a necessidade de somente usar BIGFILE em ambientes que disponham de algum tipo de distribuição de I/O / balanceamento é real e muito oportuno - até eu, quando falei na minha msg anterior que independe a performance, me esqueci desse caso, que não é comum em produção mas vale a pena citar Edilson, imagine por exemplo que ao invés de LUNs vc usa discos separados e independentes : com smallfile tablespace, vc pode criar um datafile da tablespace no disco D: , um no disco E: , um no disco F: (digamos), assim distribuindo o seu I/O ... Nesse cenário, se vc fosse usar BIGFILE como eu disse uma tablespace bigfile só pode ter UM e apenas UM datafiole, e um datafile só pode ficar num só disco Eu não tinha avisado sobre isso porque sempre penso em produção, e em produção com certeza o mais comum é juntar todas as LUNs/discos num só volume, num só I/O device que é controlado por um software capaz de espalhar o conteúdo, ie, de automaticamente gravar cada pedacinho deo datafile em uma parte diferente dum disco/LUN diferente : isso pode ser feito pelo Oracle ASM, pode ser feito pelo software que controla o storage, pelo filesystem que contém os LUNs/discos físicos, etc Agora, Edilson : algumas coisas que a Oracle fala a gente confia desconfiando , vc TEm que filtrar o exagero, yes ?? Por exemplo, quando ela diz que é mais fácil gerenciar um arquivo do que 10 na tablespace - bancando um pouco o advogado do diabo, quando que vc tem que trabalhar diretamente com datafiles ? É quando vc vai fazer operações que interferem diretamente nele (digamos, resize, ou alteração de característica física) : ora, se ao invés de 10 comandos alter vc escreveu um só ok, vc poupou, mas poupou SEGUNDOS de digitação, e isso numa operação não tão comum e rotineira, algo que não se faz todos os dias Valeu a pena, foi lucro ?? Só vc pode dizer... Outra coisa é a questão de limites maiores do DB ao se usar BIGFILES : isso existe, claro, mas é algo que só vai entrar no seu escopo quando o seu DB chegar na casa dos TERABYTES, não me parece ser o caso... Sobre a possível redução de tempo de checkpoint por ter menos datafiles , é algo possível mas não tão provável : afinal, menos datafiles significam menos blocos de cabeçalho para sincronizar, ok, mas o GROSSO de um database absolutamente não são os blocos de cabeçalho (que são POUCOS, no início de cada arquivo) mas sim os blocos de dados, e desses a quantidade de blocos absolutamente não se altera, estejam eles numa bigfile ou espalhados por vários datafiles, sim ? E é auqle coisa : atualizar um muitos milhares de blocos vai DEMORAR PRACAS, estejam esses blocos dentro de um ou dentro de x datafiles A quantidade de I/Os single-block vai ser RIGOROSAMENTE A MESMA, yes ?? Então novamente : com a BIGFILE vc poupou alguns file handlers (já que só terá um arquivo aberto) e poupou o I/O num punhadinho de blocos de cabeçalho, ok, mas o trabalho grosso continuará Rigorosamente o mesmo, ok ?? Não pense que vai ser uma hipermaster vantagem, que não deve ser ... Outra coisa é que apesar de já não ser to recente assim (foi introduzida no 10g) nós ** ainda ** temos na sua versão 11.2.0.3 uns tantos quantos bugs danados para BIGFILES, como o Bug 1409 - System hang due to TT enqueue contention with BIGFILE tablespace resize (Doc ID 1409.8) e o Bug 14510149 - enq: CT - reading during bigfile tablespace backup (Doc ID 14510149.8), por exemplo... Rumine bastante essas infos , esses prós e contras e analise aí []s Chiappa
[oracle_br] Re: PL/SQL - trigger
Sim, é totalmente Possível vc saber qual valor está sendo inserido, provavelmente numa variável dentro da trigger : uma opção é a cláusula RETURNING , que desde há muito tempo existe e faz exatamente isso, veja http://stackoverflow.com/questions/361304/oracle-how-do-i-get-the-sequence-number-of-the-row-just-inserted para um Exemplo Ou até mesmo vc pode fazer o que se fazia antes , ie : alterar o que vc deve estar fazendo hoje, que certamente é INSERT INTO tabela ... VALUES (..., nomedasequence.nexval) para um V_SEQ := nomedasequence.nextval; INSERT INTO tabela VALUES (..., :V_SEQ, ...) Agora : uma vez que a informação está numa variável da trigger, como fazer para passar para a rotina que precisará disso para outro insert ?? O ** ideal ** seria que vc não tivesse que passar esse valor, fazendo com que o INSERT na outra tabela que usa o valor gerado pela sequence aconteça nesse mesma trigger, mas SE isso não for possível, vc terá que ter uma tabela de trabalho com essa informação : outras opções como GTT, contexts e variáveis globais servem para um caso único, uma ocorrência do valor, o que Imagino que não é o seu caso, vc pode ter Múltiplas sessões fazendo INSERTs e disparando a trigger, o que invalida outra coisa que não seja uma tabela de banco, mesmo, eu acho... []s Chiappa
Re: [oracle_br] Re: Melhor alternativa para leitura de arquivo e atualiz ação em tabela
Então : veja que tanto a EXTERNAL TABLE quanto a operação de MERGE que eu recomendo como sendo (e na Esmagadora maioria das vezes é MESMO) mais Rápida são built-ins, nativos DO DATABASE, então por isso se por um lado te dão a performance TOP (internamente elas são código C , ** compilado ** dentro do database, e que usa abusa dos hooks internos do database, coisas essas inerentemente VEDADAS ao teu código Pl/SQL coitadinho INTERPRETADO e EXTERNO), por Outro lado são fechados e algo inflexíveis, fazem o que fazem e cabou Veja em https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:6618304976523#6623196184466 um pouco sobre as questões de performance, em https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:150047150034606 a opção de log de erros e em https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:35615502072484#35632246331433 os detalhes sobre qtdade de registros processados , e decida se essas coisas te atendem OU se realmente vc quer trocar performance e eficiência por controle e log detalhado... SE quiser/precisar optar pela opção menos performática porém mais controlada de fazer o processamento EXTERNAMENTE ao database, sem ser por um só comando SQL, AUTOMATICAMENTE vc vai ter que escrever mais código e VAI ter que se preocupar com limites dos resultados E que fique CLARO, esses limites (que incluiriam o LIMIT da cláusula de COLLECT, e tamanhos de arrays) não são GENÉRICOS, eles dependem fundamentalmente do SEU ambiente, de quanta RAM vc tem livre, da capacidade/poder de processamento... É TOTALMENTE POR SUA CONTA, portanto, testar no SEU ambiente e ver até onde vc pode chegar sem queda de performance e sem erros ORA-40xxx de falta de recursos : os valores de 100 registros coletados por vez que vc vai encontrar tanto na documentação quanto (principalmente) na maioria dos links que goolglar e/ou que vou indicar) são simplesmente um valor TÍPICO, mas nem de longe isso vai ser Ótimo no seu ambiente... Eu ** IMAGINO ** que a opção menos ruim de processamento PL/SQL aonde vc teria a opção de controle detalhado/log detalhado de cada registro seja a external table sendo joineada num cursor PL/SQL com a tabela a atualizar, sendo lida com BULK e o UPDATE é em múltiplos registros de uma vez com FORALL - veja http://www.morganslibrary.org/reference/plsql/array_processing.html , http://ksadba.wordpress.com/2008/06/16/updating-millions-of-rows-merge-vs-bulk-collect/ , http://www.oracle-base.com/articles/9i/bulk-binds-and-record-processing-9i.php (e seus links do 10g) e http://psoug.org/reference/array_processing.html para refs/exemplos, BEM COMO os manuais Oracle correspondentes REPITO, o que não faz sentido é vc ler 2x o arquivo de texto, sendo uma vez pra carregar na GTT e Outra vez para processar a GTT - talvez a exceção seja se vc quiser ter o log detalhado da leitura do arquivo-texto (digamos, log dos registros inválidos) : como vc aprendeu, o log da external table em si é o que é, no formato e na localização que é : CASO realmente precise muito de algo diferente E não seja viável ler/transformar o log da external, não tem jeito é engolir o sapo e a GTT sem tempero, sim ... Aí o BULK/FOR ALL vai usar a GTT ao invés da external... []s Chiappa
Re: [oracle_br] Re: Melhor alternativa para leitura de arquivo e atualiz ação em tabela
Bem, imho a pessoa ** não ** vai ter que usuário vai ter que analisar o log do concurrent e depois o log do LOADER/external table, pois os logs detalhados que são gerados para a external table são em caso de EXCEÇÕES (ie, o BADFILE eo DISCARDFILE), enquanto o LOGFILE propriamente dito tem poucas e curtas msgs ...Por exemplo, veja abaixo o logfile de uma query bem-sucedida (sem exceções) numa external table : /tmp$ cat POP_EXT_3688.log LOG file opened at 04/17/14 13:08:54 Field Definitions for table POP_EXT Record format DELIMITED BY NEWLINE Data in file has same endianness as the platform Rows with all null fields are accepted Fields in Data Source: CITYCHAR (255) Terminated by , Trim whitespace same as SQL Loader COUNTRY CHAR (255) Terminated by , Trim whitespace same as SQL Loader POPULATION CHAR (255) Terminated by , Trim whitespace same as SQL Loader /tmp$ == é informação técnica INTERNA, absolutamente Não Interessante para o usuário-final, yep ?? Então imho vc simplesmente teria uma tela customizada aonde, SE / QUANDO o usuário precisar, ele lê o BADFILE e o DISCARDFILE, Acho que é isso que o usuário precisaria ter... Já sobre o ponto de verificar se o registro que está vindo existe, e gerar uma mensagem se não existir : não sei se o MERGE aceita, mas veja lá se vc não poderia simplesmente pedir pro MERGE fazer o INSERT duma string numa tabela de erros, que depois vc apresentaria na tela de log pro usuário... Eu ACHO que não daria, mas veja lá... Sobre a questão de leitura dos dados e comparação, sim : para evitar o trabalho de carregar o arquivo-texto pra uma GTT antes de poder acessar, é o que vc falou, seria um OUTER JOIN, sim: for r in (SELECT dadosdesejados FROM tabelareal A, externaltable B WHERE A.colunachave (+) = B.colunachave loop IF r.colunachave IS NULL then -- não houve match gera uma mensagem... claro, o PL/SQL sempre trabalha logicamente registro-a-registro mas OBVIAMENTE vc colocaria os registros lidos e a updatear/inserir num ARRAY, é isso que faz a cláusula de BULK COLLECT e o FORALL yes ?? Se REALMENTE vc precisa gerar uma ação espeífica para cada registro processado, aí a solução de apenas SQL (que sria o MERGE) não atende, aí toca a aceitar a performance provavelmente inferior e programar em PL/SQL, sim E o último ponto, sobre a falta de índice na external table - veja, eu entendo que a. a tabela real vai ser ** muito MAIOR ** que o arquivo-texto com os dados a carregar E QUE necessariamente os dados TODOS que estarão no arquivo-texto TEM QUE SER PROCESSADOS do primeiro ao último, Integralmente, sim ??? Notar que o índice só é positivo para a performance quando vc quer recuperar UM, ou no máximo uma pequena FRAÇÃO do todos, aí o fato de vc precisar ler o arquivo-texto TODINHO inviabilizaria o uso de índice, okdoc ??? Por isso que a Oracle não colocou ainda a opção de indexação em external tables, tipicamente esses caras são dados a carregar/procesar, TEM que ser lidos integralmente, não compensaria para a performance. E o fato da tabela real de destino ser (imagino) MUITO MUITO maior e o fato de que é nela que vc tem que procurar para ver se o valor lido da external existe ou não indicaria que o índice útil aí seria é na TABELA REAL, que é Muito maior E é onde queremos pesquisar apenas uma linha, yep ?? []s Chiappa
[oracle_br] Re: Melhor alternativa para leitura de arquivo e atualiz ação em tabela
Blz ? Então, a opção de carregar os dados do arquivo pra GTT (seja como for, com SQL ou PL/SQL, bulk ou não, etc), simplesmente ** NÃO FAZ SENTIDO ** frente à opção de EXTERNAL TABLE - não sei se vc a conmhece, mas é uma feature relativamente antiga que permite que vc use o arquivo-texto DIRETAMENTE NUM SQL, como se ele fosse uma tabela , SEM a necessidade de carregar os dados pra dentro do banco, okdoc ?? veja vc, com GTT vc iar fazer ** DUAS ** (2) leituras completas no arquivo-texto, UMA para carregar o texto pra dentro da GTT e OUTRA para ir lendo os dados da GTT, com EXTERNAL TABLE vc simplesmente faria um JOIN (ou mesmo um MERGE - veja http://www.akadia.com/services/ora_etl.html#The%20MERGE%20Statement para um exemplo, e o manual de SQL Reference e o de DW Oracle para mais detalhes) !! Com isso num ÚNICO SQL vc já lê os dados do arquivo-texto e faz a comparação com os dados da tabela, SEM precisar se preocupar com limites de arrays, SEM precisar se preocupar com tamanhos de resultsets (pois COMO SABEMOS um SQL pode manipular Qualquer Quantidade de registros num database Oracle através do mecanismo de FETCH automático que possui), e ainda por cima via de regra vc obtém a melhor performance (pois um único SQL significa menos código Pl/SQL a analisar, um SQL puro pode se beneficiar das transformações/otimizações que o RDBMS pode fazer, o que um cursor PL/SQL ** TOTALMNENTE nÃO CONSEGUE **), é tudo de bom... []s Chiappa
Re: RES: [oracle_br] Re: Problema ao Acessar ASMCDM
Só confirma que *** realmente ** vc está logado como o usuário local, que instalou e roda o software (tipicamente usuário de domínio, mesmo administrador de domínio, não funciona, tem que ser usuário LOCAL), e plz confirma EXATAMENTE os valores que vc digitou : isso estando certo, não tem porque não funcionar, veja o meu caso : = os settings estão como : H:\set ORACLE ORACLE_BASE=H:\orainfra\app\oracle ORACLE_HOME=H:\orainfra\app\11.2.0\grid ORACLE_SID=+ASM = veja que no PATH está em primeiro lugar o sub-diretório BIN da HOME do ASM : H:\echo %PATH% H:\orainfra\app\11.2.0\grid\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\EMC\SYMCLI\bin = estou conectado como o usuário *** local *** que instalou e roda o software : H:\echo %username% oracle = taí : H:\asmcmd ASMCMD ls DLLTXOCRGRP/ DLLTXPRARCGRP/ DLLTXPRDATGRP/ DLLTXPRLOG1GRP/ DLLTXPRLOG2GRP/ DLLTXPRVTDOCRGRP/ ASMCMD []s Chiappa
Re: RES: RES: [oracle_br] Re: Problema ao Acessar ASMCDM
Se vc realmente está digitando os comandos no prompt DOS (e ** não ** no powershell!!), com a opção de Run as Administrator, está logado com o usuário correto (ie, o mesmo usuário admin local que instalou e roda o software), já conferiu e os Valores estão corretos (ie, seu sid é REALMENTE +ASM - isso pode mudar), vc tá respeitando eventuais maiúsculas/minúsculas, o caminho do PATH está correto, e não tem caracteres especiais nem espaços em branco no comando SET e/ou nos valores, aí realmente não vejo o que mais poderia estar errado, seria mesmo caso de Chamado no Suporte Oracle... []s Chiappa
Re: [oracle_br] ORA-609
Além de um especialista AIX, penso que vc CERTAMENTE precisará de um especialista em RDBMS Oracle , que deverá verificar : - se o tamanho dos redo log files está apropriado (na casa dos GBs, provavelmente, se a geração de redo é intensa) para evitar log file switch ou (ainda pior) espera por archive/limpeza se os redo log files todos já foram usados ? Na mesma toada, EM ALGUNS CASOS um leve aumento do log buffer possa ser viável, DEPENDENDO do tamanho atual - se a configuração / distribuição de I/O está adequada : os /u05 e /u06 parecem indicar que vc está usando FILESYSTEM, e nem todos os tipos de filesystem permitem I/o ASÍNCRONO e em DIRECT MODE, coisas muitas vezes Vitais para a performance ... Em especial, via de regra é Inútil e Contra-produtivo se ter CACHEs nos filesystem usados pelo Oracle, pois ele Já Mantém seus próprios caches internos : cachear um cahe Não É recomendado na maioria dos cenários - se a configuração do dataguard está ok , com a presença de STANDBY LOGFILES, archives (já que deve ser dataguard físico) sendo enviados por uma rede DEDICADA entre os servidores (não faz o menor sentido o envio de archives concorrer com os usuários finais na rede Pública) - ainda sobre o dataguard, vc diz que os redos são recebidos de forma síncrona : o dg está operando em zero data-loss mode ?? Se sim, tranquilamente PODE SER que o hardware (principalmente a infra de rede) não esteja suportando a carga inerente a esse modo, aí OU se passa a trabalhar em maximum performance OU se melhora a infra - se a distribuição de RAM está OK : fiquei principalmente encafifado quando vc diz que dos 36gb de memória ram, 20gb para a instancia principal, 5gb para uma outra instancia - vc estava falando de que, SGA ?? Se sim, vc Sabe que também é CRUCIAL se reservar memória para PGA e para os processos locais ?? A regra de dedão de algo em torno de 20% a 40% (máximo) da RAM para a SGA visa justamente ter uma segura margem de folga de RAM para os usos AFORA a SGA , a SGA ** não é ** de forma nenhuma toda a RAM que o RDBMS precisa. O especialista em RDBMS deveria SIM considerar muito seriamente a possibilidade de diminuir severamente esses 20 GB se isso é o sizing da SGA - o Planejamento para aplicação dos PATCHES : 11.2.0.3.0 indica que vc IGNOROU TOTALMENTE PSUs/CPUs do 11.2.0.3, e também não aplicou o patchset 11.2.0.4 Com isso feito, aí sim especialista em RDBMS poderia usar as tools de análise cabíveis (AWR/ASH/Statspack, Trace, Consulta Periódica com Histórico das V$ de estatísticas de uso e execução de SQLs) para produzir um healthcheck desse banco, tendo assim subsídios para demandar eventuais alterações na Aplicação (principalmente por causa dos sintomas de grande número de commit wait e concorrência que vc diz ter encontrado). []s Chiappa
Re: [oracle_br] ORA-609
Obs importante : o especialista AIX deverá trabalhar ** muito próximo ** ao especialista em RDBMs para implantar as best practices, cfrme o PDF linkado em http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100883 (as recomendações nele sobre DIO/Direct I/O e AIO/Asynchronous I/O são Cruciais em muitos casos, junto com as de caches do SO, que como eu disse em princípio não são usados pelo RDBMS, e as de config do kernel)... http://www.oracle.com/technetwork/products/clusterware/overview/rac-aix-system-stability-131022.pdf , apesar de falar sobre RAC também tem algumas boas dicas, e a nota metalink AIX: Top Things to DO NOW to Stabilize 11gR2 GI/RAC Cluster (Doc ID 1427855.1) lista alguns patches de Sistema Operacional ultra-importantes, o especialista em AIX ** tem ** que estar Ciente desses caras... []s Chiappa
Re: [oracle_br] ORA-609
Bem, não esqueça de repassar os docs que citei no meu último email antes desse pro teu especialista AIX , E as considerações sobre RDBMS para o especialista em RDBMS, mas observarei em cima da sua msg : Os 20gb para instnacia principal, e 5GB da instancia secundaria me refiro ao memory_target (SGA e PGA). Hmmm, se não há nenhum processo extra (de aplicação, ou algum webserver, ou o que for) rodando nesse servidor do RDBMS, realmente só SGA+PGA não justificaria... É checar as configs de vmm nos docs que citei antes (principalmente pra ver se casualmente o AIX não tá querendo usar parte da memória como cache do SO), e confirmar que Realmente nenhuma sessão tá super-alocando PGA (pois tanto PGA_TARGET quanto MEMORY_MAX_TARGET não são hard-limited, são ALVOS, são IDEAIS mas que PODEM ser ultrapassados eventualmente , principalmente PGA cfrme https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:17748700346068277#30479600346715456 mostra ... Especificamente para PGA, vc poderia fazer (REPETIDAS vezes, em Diferentes períodos!) uma consulta tipo : select s.inst_id, s.sid, s.username, s.logon_time, s.program, PGA_USED_MEM/1024/1024 PGA_USED_MEM, PGA_ALLOC_MEM/1024/1024 PGA_ALLOC_MEM from gv$session s , gv$process p Where s.paddr = p.addr and s.inst_id = p.inst_id and PGA_USED_MEM/1024/1024 10 -- pga_used memory over 10mb order by PGA_USED_MEM; e ver se detecta alguma super-utilização SGA é mais fácil, é consultar as V$SGAxxx . = Não deixe de referenciar para o seu especialista AIX os artigos referentes á alocação/controle de memória no AIX em http://intermediatesql.com/ , principalmente a série How ORACLE Uses Memory on AIX e o artigo How AIX Paging Space works : use no site os marcadores AIX e MEMORY... Sim, é filesystem e permitem I/O assincrono. ok, ele permite, mas o AIO *** está *** sendo efetivamente usado Eis a pergunta que o seu especialista em AIX irá responder, provavelmente via TOPAS_nmon ... Da parte do banco de dados, já que é 11g, só confirmar que FILESYSTEMIO_OPTIONS está como SETALL e DISK_ASYNC_IO está TRUE ... Agora : POR QUE filesystem ??? Se os devices estão num storage (é o mínimo esperado num ambiente Produtivo, disquinho local com braço de leitura único não é profissional) porque não usar raw devices com ASM, que já é algo setado especificamente para RDBMSs Oracle ? O dataguard está trabalhando em zero data-loss mode, maximum availability. Não tem choro nem vela : DG em zero data loss ** IMPLICA ** que o database primário só pode contionuar a trabalhar quando o log foi SEGURAMENTE não só transferido como Aplicado no DB standby , então SE vc não tiver uma infra-estrutura de primeira (entre outras coisas como eu disse, rede DEDICADA e de ALTA-PERFORMANCE entre os servers) é Ululantemente Óbvio que a performance vai cair no chão, os WAITs vão se acumular, sim ??? Como eu disse, tem que ser Avaliado in-loco e com vagar se é tecnicamente viável com esse hardware um DG ZDL, se for concluído que não é, OU upgrade OU DG maximum performance... São 2 dataguards que essa instancia principal possui, um dg fisico e outro snapshot, com 12 STANDBY LOGFILES para os 2 dg's. Idem acima : há indicadores que o ambiente não está suportando um DG physical, e ainda por cima neguim quer ter SNAPSHOTs junto ??? não sei, não, a avaliar... Os redos possuem 200MB de tamanho. Isso é um tamanho MINÚSCULO na maioria dos ambientes produtivos de alta demanda : eu RECOMENDO que o especialista RDBMS considere SERIAMENTE a possibilidade de colocar pra 1 GB , que é um valor mais comumente visto E via de regra não onera tanto assim nem espaço em disco nem a banda de rede para transmissão de archives (e o I/O lá no standby para aplicar o archive recebido). A release é a 11.2.0.3.6 Menos mal, o .6 indica que não está tão atrasado - achoq ue é avaliar, junto com o Suporte Oracle, a aplicabilidade de PSUs mais recentes (o mais recente é .8, iirc) Sobre o log buffer, a ausência de espera para gravação no log buffer é um bom indicador mas não é isso que eu pensava : a questão é que (além de outros gatilhos, inclusive por tempo) o log buffer pode ser esvaziado para o log file ao atingir um percentual do tamanho total do buffer, e elgumas vezes aumentar o log buffer para alguns (POUCOS!!) MBs diminui ess frequência... Então, veja lá como está o size do teu log buffer, se estiver abaixo da casa dos MBs considere/avalie a possibilidade de o aumentar, um pouco... []s Chiappa
[oracle_br] Re: ORA-31655: no data or metadata
Isso Pode ser um simples WARNING , por vc não ter segmentos acessíveis na tablespace especificada (https://community.oracle.com/thread/1016661?tstart=0 é um exemplo), OU pode ser questão de permissões (http://oraclehandson.wordpress.com/2011/09/26/ora-31655-no-data-or-metadata-objects-selected-for-job/ exemplifica no caso de um impdp mas em tese coisas do tipo PODEM ocorrer também para expdp) Assim, veja lá SE vc tem segmentos acessíveis para o usuário em questão na tablespace especificada E confirme que ele tem os privilégios necessários para o expdp, ** E ** tambpem no DIRECTORY especificado... []s Chiappa
[oracle_br] Re: ORA-31655: no data or metadata
Isso Pode ser um simples WARNING , por vc não ter segmentos acessíveis na tablespace especificada (https://community.oracle.com/thread/1016661?tstart=0 é um exemplo), OU pode ser questão de permissões (http://oraclehandson.wordpress.com/2011/09/26/ora-31655-no-data-or-metadata-objects-selected-for-job/ exemplifica no caso de um impdp mas em tese coisas do tipo PODEM ocorrer também para expdp) Assim, veja lá SE vc tem segmentos acessíveis para o usuário em questão na tablespace especificada E confirme que ele tem os privilégios necessários para o expdp, ** E ** tambpem no DIRECTORY especificado... []s Chiappa
[oracle_br] Re: Capacity Planning
OBS : - sobre CPU, é claro que embora o database não tenha como calcular percentual de uso (e por isso só registre tempo de CPU consumindo), o Sistema Operacional tem pleno controle e ciência de CPUs e runqueue, então ele sim tem como calcular % de uso - assim, além de mensurar consumo e capacidade no database, é Imperativo se calcular também (frequentemente e repetidas vezes, sempre no pico de uso para atender ao pior caso) o % de uso de CPUs no ambiente corrente e no POC - sobre espaço em disco, talvez seja mais relevante ao invés de levantar espaço médio gasto por sessão, se obter o espaço gasto por transação lógica : digamos, se é um sistema comercial, cada Venda completa utiliza x bytes para NF em média, y bytes para dados de Produto e z bytes para estoque e controladoria , aí multiplicando-se a soma desses bytes pela quantidade de vendas esperada por dia, vc teria a estimativa de espaço necessário []s Chiappa
Re: RES: [oracle_br] Re: ORA-31655: no data or metadata
É ** CONCEITUAL ** a sua questão, colega : a questão é que o export só exporta os DADOS, de tabelas - os índices, sinônimos e demais objetos que não contém dados na forma de tabelas relacionais Não São exportados, só o DDL é gerado no dumpfile : vc pode confirmar isso fazendo um export de teste de uma tabela gigantesca , que possua x GBs de dados e y GBs de índices, vc verá que o tamanho do dumpfile vai ser próximo de x... Outro teste é usar a opção SQLFILE no impdp, que ao invés de importar só mostra o conteúdo, vc vai ver que há INSERTs para cada dado a inserir mas APENAS UM CREATE INDEX para o índice como um todo Essa é a causa do warning de no segments, o índice não tem dados a exportar... Isso é TOTALMENTE DOCUMENTADO no manual do datapump, que nos diz diretamente (ênfase com *s minha) : Tablespace Mode A tablespace export is specified using the TABLESPACES parameter. In tablespace mode, *** only the tables *** contained in a specified set of tablespaces are unloaded. é SÒ AS TABELAS, okdoc ?? Exemplo comprovando : SYS:AS SYSDBA@xe:SQLcreate tablespace TS_TEST datafile 'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\TS_TEST_01.DBF' size 100M; Tablespace criado. SYS:AS SYSDBA@xe:SQLcreate table HR.TABTEST (c1 number); Tabela criada. SYS:AS SYSDBA@xe:SQLcreate index hr.indtest on hr.tabtest(c1) tablespace TS_TEST; ??ndice criado. SYS:AS SYSDBA@xe:SQLselect owner, segment_type, segment_name, tablespace_name from dba_segments where segment_name like '%TEST%'; OWNERSEGMENT_TYPE SEGMENT_NAME --- TABLESPACE_NAME -- HR TABLE TABTEST USERS HR INDEX INDTEST TS_TEST SYS:AS SYSDBA@xe:SQLexit C:\Users\p0623080expdp system/oracle DUMPFILE=TS_TEST.dmp LOGFILE=TS_TEST.log TABLESPACES=TS_TEST Conectado a: Oracle Database 11g Express Edition Release 11.2.0.2.0 - Production Iniciando SYSTEM.SYS_EXPORT_TABLESPACE_01: system/ DUMPFILE=TS_TEST.dmp LOGFILE=TS_TEST.log TABLESPACES=TS_TEST Estimativa em andamento com o método BLOCKS... Processando o tipo de objeto TABLE_EXPORT/TABLE/TABLE_DATA Estimativa total usando o método de BLOCKS: 0 KB ORA-31655: não há dados ou objetos de metadados selecionados para o objetoO job SYSTEM.SYS_EXPORT_TABLESPACE_01 foi concluído com 1 erro(s) em 14:02:01 []s Chiappa
Re: [oracle_br] Pergunta rápida sobre option s de se gurança
okdoc - apenas aviso que o principal fator que vc tem que pesar no julgamento entre VPD x OLS são Custo, Tempo de Implementação e Adequação a Políticas Complexas. Veja vc, VPD é a tecnologia básica, embutida no RDBMS Oracle (e portanto sem custo) que permite que automaticamente uma condição a mais seja incluída nos WHERE de todos os SQLs com uma programação sua, adicional, que vc vai escrever, enquanto o OLS é um produto que usa o VPD para criar automaticamente as regras/condições que serão adicionadas no WHERE... Por exemplo, digamos que seus requisitos de acesso sejam bem simples, baseada em um id do grupo de trabalho (ie, algumas linhas da tabela só podem ser enxergadas por quem está no grupo CONTADORES, outras só pelos usuários que estão no grupo DIRETORIA, e assim por diante) : com OLS vc simplesmente teria uma coluna LABEL_DE_ACESSO escondida na tabela (atributo hidden) e a indicaria no setup do OLS como a fonte, só... Já com VPD vc Teria que escrever cada IF, cada SELECT para buscar os dados de acesso, enfim, teria que programar cada detalhe Obviamente, isso que em tese é desvantagem do VPD ** RAPIDAMENTE ** pode ser transformar numa Vantagem : digamos que a sua política de acesso é mais complexa, que vc tem que levar em conta elementos dinâmicos não-presentes na tabela, como IP, usuário de rede, dia da semana/hora, ou coisas do tipo : isso é Facilmente programado com VPD, enquanto o OLS, como não é muito programável e é focado em LABELS, em informação já constante na tabela a ser protegida, seria bem mais trabalhoso/difícil de fazer algo ... Claro, não é que não faça, mas é que o OLS é um pacote pronto, onde vc não programa quase nada : quando os defaults dele se encaixam maravilha, vc POUPOU um montão de trabalho e isso em tese já justificou o custo dele, mas para situações mais complexas não é tão simples de o ajustar, aí imho passa a ser vantajoso o VPD, se for o caso combinando OLS com o VPD se possível... De referências, além da documentação (principalmente o capítulo do VPD no Oracle® Database Security Guide e o manual do OLS) veja http://www.orafaq.com/wiki/Oracle_database_Security_FAQ , http://www.oracle-base.com/articles/9i/oracle-label-security-9i.php (a versão do exemplo é antiga mas os conceitos básicos permaneceram), http://www.oracle-base.com/articles/10g/database-security-enhancements-10g.php#vpd (equivalente para o VPD), http://www.oracle.com/br/products/database/options/label-security/overview/index.html (aqui vc acha links para os foruns especializados e alguns artigos técnicos e cases), http://www.oracle.com/technetwork/database/security/ols-faq-088171.html e http://www.oracle.com/technetwork/tutorials/index.html (procurando por LABEL SECURITY e por VIRTUAL PRIVATE DATABASE vc encontra vários OBEs e Tutoriais). []s Chiappa
[oracle_br] Re: View Materializada gerando Archives
Veja lá que CONCEITUALMENTE no RDBMS Oracle é virtualmente IMPOSSÍVEL vc não gerar redo algum pois, como sabemos, além de servir para a recuperação em caso de falha, o undo gerado para consistência de leitura - o RDBMS Oracle ** nunca faz leitura suja, então Qualquer DML gera UNDO - implica em geração de redo para as estruturas internas do RDBMS que controlam transações... Da mesma forma, o refresh de uma mv Necessariamente implica em geração de redo para as tabelas/índices internos que controlam a mv em si Assim, o que o atributo de NOLOGGING faz é DIMINUIR o redo - impossibilitar geração de redo é como eu disse IMPOSSìVEL, ok ? Isso posto, PROVAVELMENTE o que deve estar pegando no seu caso pode ser que : OU a mv em si está LOGGING (de repente a tablespace está com NOLOGGING mas a mv não foi criada assim), e/ou vc deve estar pedindo um REFRESH completo (o que implica em montes de dados a transacionar) , E/OU vc está usando grupo de refresh E/OU vc não está setando o atomic_refresh=false Assim, EXTRAIA o DDL da m para ter certeza que ela está como nologging, analise se é viável/possível refresh incremental , E veja (vide https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:15695764787749#7066764400346113957 para um exemplo) se é o caso de setar atomic_refresh Adicionalmente, não se aceita achismo, esse seu APARENTEMENTE não tá legal : eu diria para vc, como parte da investigação, colocar na rotina que refresha a mv (vc não diz mas ao que entendo é isso que vc tem, é um job que faz refresh a cada 6 minutos) uma instrumentação , gravando/registrando o valor da estatística REDO SIZE antes e depois do refresh (assim vc saberá EXATAMENTE quanto redo está sendo gerado) []s Chiappa OBS : a) SE vc tiver índices na mv o nologging não vai funcionar adequadamente (índices SEMPRE são atualizados linha-a-linha, gerando redo) e b) se vc estiver usando standby físico, CERTAMENTE o database deve estar em modo de FORCE LOGGING, aí Também o NOLOGGING não irá funcionar adequadamente
[oracle_br] Re: Capacity Planning
Bem, primeiro fique Claro que NENHUM software te dá toda a informação prontinha e mastigada - vou citar alguns comuns aqui mas SEMPRE algum trabalho de sua parte vai ter SIM, ok ? Muito bem, o primeiro passo para capacity é mensurar a capacidade máxima do teu hardware, começando pelo que é compartilhável, ie, I/O e rede (depois vc foca no que é usado por um só requisitante de cada vez, que é CPU, memória e espaço em disco... Esse primeiro passo seria : 1. levantar a quantidade máxima teórica de I/Os e e de blocos transferidos pela rede num intervalo fixo de tempo (um segundo é o intervalo típico escolhido) - isso é algo que o fornecedor do teu hardware Deveria ser capaz de fornecer, e depende DRASTICAMENTE dos detalhes específicos do seu hardware, é particular pro teu hardware, não é algo que vc possa copiar/obter de outra pessoa... 2. mensurar quanto Efetivamente o hardware é capaz de te dar : isso se faz (num intervalo SEM usuários, SEM nada rodando, é Óbvio!) preferencialmente com softwares de medição (como IOZONE, FIO, ORION, IOMETER, etc), ou (não preferevelmente, pois são MUITO menos exatas) com tools do SO, como iostat, netstat, etc, medindo scripts seus que façam I/O e transferência via rede OBS : é Absolutamente Normal 1 e 2 terem alguma discrepância (já que o Fornecedor sempre te dá o melhor dos melhores cenários possíveis, com dados artificiais que se aproveitam quase Sempre dos caches, que sempre cabem num bloco/página de rede, e sem concorrência de nenhum tipo, etc, etc), mas se for algo escandaloso essa diferença CERTAMENTE algum problema de setup vc tem aí nesse hardware 3. mensurar quanto está sendo usado hoje pelo database hoje existente (SEMPRE supondo que apenas o RDBMS Oracle roda nesse servidor, como deveria ser) : SE vc tiver licença para consultar/usar o AWR, vc pode usar a dba_hist_sysmetric_summary, se não vc terá que fazer consultas às views de performance/estatísticas de sistema repetidas e repetidas vezes, em diferentes períodos, e armazenar os dados nalgum lugar para consulta posterior SABENDO o quanto o hardware é capaz de dar e o quanto está sendo usado, vc chega na margem de quanto sobra para a nova aplicação... O segundo passo é mensurar o consumo dos itens não-compartilhados, ie, espaço em disco e memória (a CPU falaremos mais abaixo) : como esses caras só podem atender um requisitante de cada vez em tese (quem pediu pra usar uma posição de memória e/ou um espaço no disco em tese só quando o liberar é que o recurso fica disponível aos outros), o procedimento é basicamente mensurar quanto está sendo usado repetidas vezes, em dias/intervalos diferentes, pra chegar num valor máximo que o ambiente atual precisa, aí vc compara com quanto tem... Novamente, SE vc tiver histórico mantido pelo AWR use-o, senão crie e mantenha o seu...E claro, coisas como o swapping de memória relativizam isso, mas vamos pensar numa utilização SADIA, sem swapping, que é uma coisa EMERGENCIAL, não algo rotineiro, em tese... Com os dois passos feitos e as infos em mão, é AÍ que vem o mais difícil, não tecnicamente mas politicamente : o fornecedor da Aplicação (ou os desenvolvedores/Analistas, se for aplicação interna) TEM que te dar um valor médio/esperado de memória/disco/transfer de rede/I/Os para cada sessão na nova aplicação, permitindo que vc multiplique isso pelo número de sessões esperado e possa comparar se a sobra citada acima atende à esse cálculo ou não... Isso é difícil porque em 99,99% dos casos o fornecedor NÂO mede coisíssima alguma, ele parece considerar que memória/rede/I/O são INFINITOS :^; O que já vi muitas vezes é, na Ausência desses números/valores por parte do Fornecedor, a Empresa monta um ambiente POC com a aplicação novata e levanta os números, é isso... Blz ? Agora sobre a CPU : o caso da CPU é um pouquinho diferente, não há um valor fixo máximo - o caso é que se vc não tiver poder de CPU para atender a todos os requisitantes, as requisições não-atendidas deles *** NÂO VAI FALHAR ***, ao contrário de espaço em disco e RAM : o que vai acontecer aí é que elas ficam numa FILA DE ESPERA Então absolutamente não adianta vc medir só e apenas os segundos de CPU que o database precisou dentro do seu intervalo de medida, vc TEM que medir também no SO o quanto a fila de espera por CPU (o runqueue) cresceu []s Chiappa
Re: RES: [oracle_br] funcionamento do segmento de LOB
Colega, vamos tentar te dar alguns elementos mais : 1. pra variar vc Não Diz se está usando 11g ou não, e se for 11g se está usando SECURE FILES ou não : o fato porém é que além da questão da possibilidade de compactação, SECURE FILES são uma opção mais refinada/moderna de controle de espaço - entre outras coisas, não precisam de PCTVERSION declarado no LOB para controlar versionamento/percentual de reuso, por exemplo Então considere SERIAMENTE a possibilidade de os usar se vc tá na versão 11g 2. é Evidente que um CLOB pode possuir *** muito mais ** dados, muito mais caracteres do que todo o resto do seu registro lógico (composto por escalares de pequeno tamanho, como DATE, NUMBER e VARCHAR2), então Totalmente Não faz sentido a comparação que vc faz , tipo ah, tenho 300 GB de CLOB contra um número muito menor de espaço ocupado por outros dados : o que vc tem que analisar é a QUANTIDADE DE CARACTERES armazenados versus esses 300 GB, okdoc ?? Digamos que vc tem no total duzentos e muitos GBs de informação gravados nesses LOBs, aí ocupar 300 GB em disco é Totalmente o esperado, sim ?/ Sempre há algum overhead... A questão é que no RDBMS Oracle, por questão de performance, ele NUNCA aloca/grava/usa o espaço em disco byte-a-byte : ele sempre lê/usa/grava uma quantidade fixa de kbytes cahamado BLOCO, e ao pedir espaço em disco pro SO ** nunca ** pede um bloco por vez, mas sim uma quantidade de blocos sequencias/juntinhos, o chamado EXTENT... Assim, mesmo que vc for gravar uma linha que seja de informação, ao menos um extent já terá sido alocado, yep ?? E na hora de gravar a informação em cada bloco dentro de cada extent, o comportamento normal é mesmo deixar um pouco de espaço reservado para futuros UPDATEs... E ** NUNCA ** esqueça, necessariamente o LOB não armazena Só e Apenas o dado : vc vai ter também que manter um segmento de LOB INDEX, vc vai ter estruturas de controle Então NUNCA gravar x bytes no LOB significa que vc gastou x bytes em discos, é x bytes + o overhead... Para comparar dados x espaço gasto (se vc não já tiver essa informação) vc pode fazer algo tipo : select sum(dbms_lob.getlength(colunalob)) from tabelaquecontémolob; e comparar contra um SELECT sum(bytes) from DBA_EXTENTS WHERE tablespace_name = nomedatablespacequesócontémLOBsque vc diz que tem == Então, ** SE ** vc já pediu um SHRINK da coluna CLOB (*** Não É *** shrink da tabela, é DA COLUNA CLOB!!) e não teve grande alteração, eu Suponho que a qunatidade de dados deve ser muito grande, justificando os 300 GB Se vc ainda julgar o overhead grande, vc até PODE diminuir isso alterando o porcentual de espaço reservado, o CHUNKSIZE, etc : e como isso não funciona para o passado (o que já está alocado, está alocado), vc pode considerar,depois de ter alterado os parâmetros em questão, criar uma NOVA tablespace (sempre LMT e AutoAllocate, já que vc não sabe o tamanho que o dado LOB terá) e mover os lob segments/lobindexes para ela... 3. Ainda por questão de performance, quando vc deleta os dados (sejam em LOBs ou não) o comportamento do RDBMS é ** deixar ** esse espaço ainda alocado para o mesmo segmento que os usou, pois ele pensa que os segmentos são dinãmicos, que brevemente o mesmo segmento que sofreu a deleção VAI sofrer novos INSERTs, e aí esse espaço VAi ser reusado, e o fato dele já estar pré-alocado acelerará EM MUITO essa entrada de dados, sim E isso nem é FRAGMENTAÇÂO propriamente dita, pois esse espaço em branco, REPITO, vai SIM ser reutilizado nos próximos INSERTs, ele Absolutamente não está perdido, não é impossível de ser usado, como ocorre na fragmentação REAL, okdoc ?? O shrink de lob e a movimentação (principalmente esta última) vão ser efetivos também neste caso de reuso de espaço deletado, se for o caso : leia http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:7246820117571 (é uma thread longa mas Absolutamente informativa e importante), http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3084920323218 , http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3998444100346949788 e http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:3679447698936 para refs e exemplos... []s Chiappa
Re: RES: [oracle_br] funcionamento do segmento de LOB
Um exemplo para mostrar em ação o overhead do LOB (que, COMO EU DISSE, em
muitos casos pode ser Sensivelmente Diminuído alterando-se os params de
controle de alocação E usando sercurefiles, mas SEMPRE vai existir) :
- crio a tablespace LMT autoallocate :
SYSTEM:@xe:SQLcreate tablespace TS_LOB datafile
'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\TS_LOB_01.DBF' size 1G extent management
local autoallocate;
Tablespace criado.
= crio a tabela que contém um LOB (CLOB no caso) , desabilitando storage in
row (para que a alocação só ocorra na tablespace dedicada a LOBs ainda que os
dados a inserir sejam pequenos : não é uma boa idéia sempre, mas para fins
didáticos/de exibição vamos fazer assim) :
SYSTEM:@xe:SQLcreate table T_LOB (c1 number, c2 varchar2(4000), c3 clob)
2 lob (C3) STORE AS ( TABLESPACE TS_LOB DISABLE STORAGE IN ROW NOCACHE
CHUNK 8192);
Tabela criada.
= insiro uma linha só :
SYSTEM:@xe:SQLinsert into T_LOB values (1, 'Linha 1', 'primeira linha inserida
no CLOB');
1 linha criada.
SYSTEM:@xe:SQLcommit;
Commit concluÝdo.
= veja que já alocou um EXTENT inteiro para cada tipo de segmento que um LOB
exige, como eu disse antes :
SYSTEM:@xe:SQLselect segment_name, segment_type, extent_id, bytes, blocks from
dba_extents where tablespace_name='TS_LOB';
SEGMENT_NAMESEGMENT_TYPEEXTENT_ID BYTES
BLOCKS
--- -- -- --
--
SYS_LOB020052C3$$ LOBSEGMENT 0 65536
8
SYS_IL020052C3$$LOBINDEX0 65536
8
= vou inserir mais algumas linhas :
SYSTEM:@xe:SQLed
Gravou file afiedt.buf
1 DECLARE
2 l_clob clob := empty_clob();
3 BEGIN
4 FOR i IN 1..10 LOOP
5INSERT INTO T_LOB (c1, c2, c3) VALUES (i+1, 'Linha:'|| to_char(i+1),
empty_clob()) RETURNING c3 INTO l_clob;
6-- create a 400,000 bytes clob
7--FOR i IN 1..100 LOOP
8-- dbms_lob.append(l_clob, rpad ('*',4000,'*'));
9--END LOOP;
10 END LOOP;
11* END;
SYSTEM:@xe:SQL/
Procedimento PL/SQL concluÝdo com sucesso.
SYSTEM:@xe:SQLcommit;
Commit concluÝdo.
== Como os CLObs vazios que inseri couberam , não houveram novas alocações :
SYSTEM:@xe:SQLselect segment_name, segment_type, extent_id, bytes, blocks from
dba_extents where tablespace_name='TS_LOB';
SEGMENT_NAMESEGMENT_TYPEEXTENT_ID BYTES
BLOCKS
--- -- -- --
--
SYS_LOB020052C3$$ LOBSEGMENT 0 65536
8
SYS_IL020052C3$$LOBINDEX0 65536
8
= agora vou inserir novas linhas na tabela Mas com informação nos CLOBs :
SYSTEM:@xe:SQLDECLARE
2 l_clob clob := empty_clob();
3 BEGIN
4 FOR i IN 1..10 LOOP
5INSERT INTO T_LOB (c1, c2, c3) VALUES (i+1, 'Linha:'|| to_char(i+1),
empty_clob()) RETURNING c3 INTO l_clob;
6-- create a 400,000 bytes clob
7FOR i IN 1..100 LOOP
8 dbms_lob.append(l_clob, rpad ('*',4000,'*'));
9END LOOP;
10commit;
11 END LOOP;
12* END;
Procedimento PL/SQL concluÝdo com sucesso.
= veja que cfrme os dados foram crescendo e novo espaço foi necessário, novos
extents foram alocados :
SYSTEM:@xe:SQLselect segment_name, segment_type, extent_id, bytes, blocks from
dba_extents where tablespace_name='TS_LOB';
SEGMENT_NAMESEGMENT_TYPEEXTENT_ID BYTES
BLOCKS
--- -- -- --
--
SYS_LOB020052C3$$ LOBSEGMENT 0 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 1 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 2 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 3 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 4 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 5 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 6 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 7 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 8 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 9 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 10 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 11 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 12 65536
8
SYS_LOB020052C3$$ LOBSEGMENT 13 65536
8
Re: RES: [oracle_br] funcionamento do segmento de LOB
Obs complementar : sobre CACHEs, tenha em mente que eles ABSOLUTAMENTE não fazem sentido SEMPRE e em Qualquer caso : qualquer tipo de CACHE só é efetivo SE (além de vc ter memória SUFICIENTE sobrando pra ele, não tendo que tirar de áreas mais nobres), os dados são lidos Constantemente - óbvio Ululante que se vc subiu os dados lidos para um cache mas depois ninguém mais precisou consultar esses mesmos dados, vc só desperdiçou espaço VERIFIQUE se a sua Aplicação realmente consulta repetidamente esses LOBs, sim ?? Tipicamente LOBs são dados não-estruturados, descrições complementares / detalhes de algo, então não é comum que sejam lidos e relidos constantemente : Até por isso o RDBMS não implementava por default CACHING de LOBs em algumas versões, yep ?? É uma escolha LOCAL, sua, mas BASEADA no que vc conhece do comportamente DA APLICAÇÃO, sim ?? No seu caso só vc sabe dizer, mas NF é o tipo do documento que nromalmente NÂO é consultado frequentemente : o usuário quer saber é o total de vendas no dia, a movimentação de estoque, etc, coisas essas que (ESPERO!!) o teu sistema não te obriga a varrer um LONGO e DESESTRUTURADO LOB para se obter, né não ?? []s Chiappa
Re: [oracle_br] Pergunta rápida sobre options de se gurança
Roland, Adicionalmente, notar que desconheço a sigla OSL nesse contexto de produto de Segurança : será que vc não quis dizer OSB (Oracle Secure Backup), OLS (Oracle Label Security, provável) ou OAS (Oracle Advanced Security) ?? []s Chiappa
[oracle_br] Re:
Bom, eu não usei ainda em Forms web (como é o caso do Forms 10g) essas built-in de OLE, mas sei que essa rotina pertence ao pacote webutil : se com a sua máquina de mesa atuando como webserver (creio que é isso que vc quer dizer quando fala Localmente) a função roda ok mas não quando o Forms roda a partir de outra máquina remota atuando como webserver a gente pensa que : a. pode haver alguma restrição (ie, firewall, bloqueios no plugin java - o Firefox é notório por os aplicar -, UAC, algo do tipo) impedindo o acesso pelo webserver ao java da máquina-cliente : junto com os sysadmins verifique Todas as possibilidades nesse sentido ou b. vc pode estar caindo em bugs (afaik essa conexão envolve odbc, pode ser drivers desatualizados) , ou mesmo bug na webutil em si ou mesmo no Forms Experimente atualizar a versão da webutil, do plugin java E do Forms 10g para os últimos patchsets/patches disponíveis ou c. vc pode estar simplesmente com má-configuração nos arquivos de config e/ou nas variáveis de ambiente : Compare cuidadosamente como estão os arquivos .conf e as variáveis de ambiente na sua máquina E lá na webserver... []s Chiappa
[oracle_br] Re:
Dicas Adicionais : - as versões mais recentes do java endureceram a segurança : não deixe de comparara exatamente a versão de java que vc tem na máquina-cliente que funciona com a webserver, E também de ** abrir o java Console ** e olhar detalhadamente os eventuais logs gerados quando for executar na webserver - vc não diz mas IMAGINO que está usando o OAS, já que é Forms 10g : sendo isso, veja a nota metalink How To Install Webutil on 10.1.2.x Oracle Application Server (Doc ID 566628.1) para um passo-a-passo de instal e config da webutil no webserver, E não deixe de instalar/rodar o demo do webutil para confirmar que tá tudo bem por esse lado - a nota metalink Master Note - Oracle Forms WebUtil Technical FAQ (Doc ID 270940.1) centraliza os reports de jar files expirados e quetais, Não Deixe de a ler também - pode ser interessante, DEPOIS que vc verificou tudo, tentar (ou ao menos comparar com o seu) os exemplos das notas How to Read Data from an EXCEL Spreadsheet into a Form Using Webutil Client_OLE2 (Doc ID 813535.1) e How to Copy Records From Form Into MS Excel Using WebUtil (Doc ID 247606.1) []s Chiappa
[oracle_br] Re: RMAN as copy
Tudo jóia ? Então, ao que entendi o que vc quer é duplexar os arquivos de backup, mas em devices diferentes (disco e fita, no caso) - o procedimento built-in para se obter isso já na hora que se faz o backup é a opção COPIES do comando BACKUP (ou pode setar via SET/CONFIGURE), mas o documento correspondente (manual Oracle® Database Backup and Recovery Reference 11g Release 2 (11.2) no item sobre o comando BACKUP nos diz : COPIES integer Sets the number of identical backups (1 - 4) that RMAN creates. The default value is 1. You can use multiple format strings to specify different names and locations for the copies. Example 2-22 illustrates a duplexed backup to different locations on disk. RMAN can duplex backups to either disk or tape, but *** cannot duplex backups to tape and disk simultaneously *** . You can specify duplexing in multiple commands. ou seja, com a opção específica de duplex vc não consegue o que quer Vc teria as seguintes opções, então : 1. realmente passar a fazer o backup em disco, e posteriormente copiar (não mover, copiar) os arquivos do backup para fita, ** por fora do RMAN **, usando a opção apropriada do teu software de backupgerenciamento de fita : isso vai te dar a vantagem da performance (já que backup para disco é via de regra mais rápido que para fita) E a vantagem de liberar a fita durante a janela de backup (essa cópia dos arqs de backup pode Inclusive ser feita durante o dia, período em que normalmente não há backups)... As desvantagens são : vc vai ter que mudar as suas rotinas de backup atuais E o gerenciamento do conteúdo da fita vai ser feito por fora do RMAN, o RMAN nem imagina que existe essa cópia do backup em fita... ou 2. para vc obter o mesmo efeito que 1. acima mas com algum controle/registro por parte do RMAN, vc pode usar o comando BACKUP BACKUPSET (não confundir com o BACKUP databaseouqueobjetofor AS BACKUPSET, que vc usa para backupear o objeto/database em formato de backupset) : com esse comando BACKUP BACKUPSET (sem o AS) vc está mandando o RMAN fazer uma cópia (em fita, presumivelmente) do teu backupset... No mesmo manual acima citado, veja o item Backups of Backup Sets ou 3. se for imperativo vc manter o backup principal indo para a fita, a opção seria vc trazer da fita os arquivos do backup recém-feito : vc até poderia usar as opções de restore do RMAN só trocando o local de destino e o id do database, mas imho o mais simples seria fazer por fora do RMAN, ie, apenas lançar mão dos comandos de leitura e gravação dos arquivos em fita do teu gerenciador de fitas/backups (Tivoli, NetBackup, seja qual for) e ler da fita e gravar em disco os arquivos correspondentes ao último backup - em caso de necessidade depois vc cataloga esses arqs em disco para o RMAN tomar conhecimento deles A vantagem é que vc está testando o que foi gravado na fita, em tese pegando erros de gravação pouco tempo depois, e a desvantagem principal é que vc VAI estar usando o hardware de fita por muito mais tempo, facilmente isso pode interferir no schedule de backup/restore de Outros ambientes que queiram usar o mesmo hardware... ou 4. manda um backup que não seja as backupset (um image/as copy, como vc sugere) para disco : faz mito tempo que eu não faço isso, mas iirc sim, um backup do tipo cópia integral do database não interferiria no sequenciamento dos seus backups as backupset Testa aí no seu ambiente de testes/homologação mas afaik é isso mesmo Blz ? De recomendações, se eu fosse vc ia de 1 ou 2, mas em tese qquer uma das opções funcionaria : analise todas e veja qual a melhor pro seu caso... []s Chiappa
[oracle_br] Re: Qual a melhor forma implementar Pl/sql com Shell Script ?
Do ponto de vista do DBA, com CERTEZA ele nem sequer deveria estar envolvido nisso : pra começo de conversa, o DBA só atua no banco de dados (e com restrições no servidor de banco de dados) e normalmente nem o banco em si nem o servidor tem acesso à impressoras, nem á outros elementos da rede - banco de dados via de regra é um elemento passivo, que é conectado/acessado por muitos mas Não conecta nem acessa ninguém... Então imho quem tem que escrever um programa-cliente que conecte no banco, recupere a informação, gere um arquivo e conecte na impressora pra descarregar o tal arquivo é a equipe de DESENVOLVIMENTO, usando a tool/linguagem de programação que conheça/tenha : não caberia apito NENHUM para o DBA nesse caso EM ESPECIAL se for dentro de um pacote extensível tipo o Oracle EBS, neles já há toda uma riqueza de tools de extensão programáticas... CASO realmente um DBA seja encarregado de uma tarefa do tipo (não deveria a meu ver, mas enfim), no banco de dados não há muitas opções : primeiro, para gerar o arquivo-texto com dados, é OU usar SPOOL num script sqlplus OU gerar o arquivo numa rotina PL/SQL via utl_file OU acionar (via scheduler ou java ou daemon) um executável externo (script shell ou programa externo,adquirido ou escriot numa tool que exista no servidor Oracle) que gere o tal arquivo... Depois de gerado o arquivo, para enviar para outro local/dispositivo PRIMEIRO vc tem que se assegurar que haja conectividade entre o servidor de banco e o destino (como eu disse antes isso Não É comum, via de regra o servidor e/ou o database não acessam ninguém, só são acessados) , e SEGUNDO , já que no RDBMS não há em princípio uma rotina para transferência de arquivos/conexão em devices, vc terá que implementar algo : poderia ser a nível de SO (tipo NFS ou compartilhamento Samba), poderia ser sum shell script acionado pelo database via java ou scheduler ou daemon, OU mesmo poderia ser escrito em PL/SQL (usando os comandos tipo UTL_TCP e quetais)... Como Não É algo que um DBA faça rotineiramente, não há imho nenhuma Recomendação especial preferindo um ou outro . []s Chiappa
[oracle_br] Re: Large Pages no Windows
Eu ainda não tive ocasião de fazer isso nas máquinas Windows daqui, mas algumas obs adicionais pra vc pensar : a. é verdade que com memória alocada em páginas maiores, a quantidade de acessos necessária deverá diminuir, E também que dividindo a RAm em áreas maiores logicamente menos latches/controles internos vão ser necessários para o SO a controlar, mas a meu ver o nenefício principal é outro : a área alocada em huge pages normalmente é LOCKADA, ie, vc não tem nenhum tipo de page steal, o SO ** não vai ** ficar tirando páginas no momento não-usadas ou com pouco uso dessa área lockada para atender outros processos que demandem memória : isso é Excelente nos casos em que vc efetivamente quer que a SGA não seja tocada/mexida/acessada por ninguém de fora do RDBMS, poupando muitas operações lógicas e latching por parte do SO... A desvantagem é uma decorrência Óbvia desse lock : a memória que vc indicou como a ser controlada por huge pages fica permanentemente alocada e servidndo apenas a SGA : se houver um processo necessitando dessesperadamente de memória comum para a PGA, ou se o So precisar de memória para os fins internos dele, não tem como alocar nada dentro dessa área marcada como huge page area... b. a nota de huge pages para Windows (Using Large Memory Pages on 64-Bit Windows Systems (Doc ID 422844.1) no metalink) não cita, mas em outros ambientes é diretamente declarada a Incompatibilidade entre huge pages e AMM (Automatic Memory Management) : isso faz todo o sentido, já que a memória alocada em huge pages VAI estar lockada não tem como se ficar aumentando/diminuindo ela, nem re-alocando-se pools , ela é um bloco único alocado de uma vez Confirme que o seu ambiente Windows não está usando nenhum tipo de AMM, preferencialmente... []s Chiappa
Re: [oracle_br] Large Pages no Windows
okdoc - apenas, como eu disse, antes de pensar em implementar huge pages, além de desabilitar AMM, tenha certeza que : - vc TEM memória suficiente para atender aos demais requisitantes descontando a SGA que vai ficar lockada, fixa e inacessível para eles - vc historicamente NUNCA chegou numa situação de memory pressure, aonde parte da RAM vai pro swap file para poder atender solicitações extraordinárias - vai seguir as obs reportadas na nota metalink que citei, EM ESPECIAL o reboot antes de implementar huge pages e nem preciso dizer, vc vai implementar isso Primeiro em desenv, depois em HOMO e só depois em prod... []s Chiappa
Re: RES: [oracle_br] Large Pages no Windows
dado o fato que hugepages atende apenas SGA, na verdade a sua pergunta deveria ser diferente, e seria : quanto reservar para a SGA, de forma que sobre espaço pras OUTRAS alocações do RDBMS (como PGA) E para as necessidades do SO ?? A resposta só pode ser DEPENDE : só vc sabe o quanto o teu database (as tuas aplicações, na verdade) se beneficiariam ou não de caches maiores (na verdade, SGA pode ser entendida como área de CACHEs, não só cache de dados mas caches de internos do RDBMS de um modo geral) Algumas regras de dedão falam em coisa de 30% para SGA (e portanto 30% como huge pages), mas isso pode variar Enormemente : eu recomendaria vc começar MODESTAMENTE, com algo entre 20% a 25%, e ir aos poucos aumentando, sempre COLETANDO evidências diretas, como WAITs diminuídos - DESCONSIDERE cache hit ratios e quetais, imho a ** única ** maneira Confiável de saber se teus caches estão sendo efetivos é vc mensurar que a MESMA EXATA quantidade de blocos lidos, com a MESMA carga de trabalho, mesmo latching, tudo igual, quando o cache era de tamanho x demorava n segundos e com cache aumentado para y caiu para n-m segundos []s Chiappa
Re: [oracle_br] Remover Datafiles
Eu penso cá com meus botões que mais TENSO ainda é se esse ambiente com não-sei-quanto clientes importantes dependendo dele não tiver nem um raio de um standby (bem provável, pelo jeito) , se esse hardware aí crashar sem recuperação possível (como TODO e QUALQUER hardware, isso não é uma questão de SE, mas de QUANDO) aí que neguim vai ver o que é bom pra tosse sem ser xarope melagrião... Isso sem contar que não havendo um segundo hardware COM CERTEZA a política de backup Não foi testada NUNCA, absolutamente NUNCA foi feito um restore de produção pra se criar um ambiente Homologação (Homologação esse que Serviria também pra pré-teste de patchsets e patches), tá tudo só pra Inglês ver... Com a minha sorte de aranha eu é que nunca nem tento fazer algo do tipo... []s Chiappa
Re: [oracle_br] IMP-00016 Required Character Set Conversion Not Supported Error when Import to Oracle Database
Na verdade, se vc tivesse Consultado a documentação, vc teria encontrado : Oracle Error: IMP-00016 Error Description: Required character set conversion (type number to number) not supported Error Cause: Import could not convert the character format of the export file into the native character format. Action: Change the user character set by setting the NLS_LANG environment variable to match the character set of the export file. == OU SEJA, poderia ter sido uma simples questão de ajustar o ambiente - SE e APENAS SE esse procedimento não tivesse funcionado, Aí SIM vc partiria para alteração no database, sim ??? E SE fosse necessária a alteração, ABSOLUTAMENTE não seria feita se fazendo DML nos objetos internos do database, isso é garantia quase CERTA de deixar um database não-suportado em caso de problemas, Não pe documentado nem Recomendado o procedimento que vc fez... Neste cenário, o que eu diria então (já que esse database tá Incerto, sabe-se lá se tá funcionando ou não, a partir do momento que vc faz DML no schema SYS) é simplesmente DROPAR esse database e RECRIAR um novo, desta vez com o cahracterset apropriado... []s Chiappa
[oracle_br] Re: monitoramento de suporte
Bem, eu realmente não me lembro de ter visto uma thread assim aqui no Grupo, então vou responder diretamente : penso que o mais prático seria ou vc ter uma stored procedure dentro do banco ou vc ter um shell script no SO, e o tal DBA executaria é a procedure/shell de uma vez só (por mais que seja um Estagiário, Júnior ou coisa assim não faz o Menor Sentido desperdiçar o tempo dele exigindo que ele faça uma por uma as consultas, centralize todas as consultas num só programa, numa só coisa que ele executa de uma vez) - aí a própria coisa (procedure/shell/o que for) já gera um log ou criando um arquivo-texto ou inserindo numa tabela de log... ok ? INCLUSIVE, o log poderia ser já num formato mais caprichado (tabela HTML gerado pelo sql*plus, por exemplo) , que aí já serviria INCLUSIVE de report para a gerência/administradores (tipicamente esse pessoal Gosta de receber um report mostrando que foi feita a monitoração/checklist/whatever)... []s Chiappa
Re: [oracle_br] Re: Sessão imortal
Só uma obs : se Fosse realmente 24x7 a sério, crítico de verdade, vc necessariamente TERIA aí OU alguma solução de alta-disponibilidade com disaster recover (ie, standby ou réplica para um outro local) OU pelo menos um solução de aumento de resiliência contra falha de servidor (ie, RAC) - aí não teria NENHUMA emoção envolvida no shutdwon/startup, se ele demorasse ou desse qquer problema vc simplesmente ativaria a solução de HA (que tipicamente leva menos de um minuto, ou nem isso) e o usuário-final nem saberia do problema, ENQUANTo vc discute opções com o Suporte Oracle... []s Chiappa
[oracle_br] Re: Remover Datafiles
O que acontece no Windows é que muitas vezes mesmo quando o arquivo é fechado, o file handle não é liberado enquanto o processo que criou/solicitou/usou ele não for encerrado : isso é comum de se observar por exemplo quando vc abre uma arquivo num editor de texto, aí mesmo depois de fechar o arquivo no editor ele continua lockado enquanto o editor não for encerrado Com o utilitário file handle lá do pacote Sysinternals vc vê direitinho isso... Em alguns casos vc até consegue 'deletar'/liberar esse file handle com um utilitário específico (google por windows file unlocker que vc acha uns tantos quantos), mas não é garantido em 100% dos casos - aí, se vc não conseguir , o que vc pode fazer é OU apenas DIMINUIR esse datafile para o mínimo possível, OU colocar o datafile como offline OU mover os dados pra outra tablespace e colocar a tablespace offline, ou coisas assim, enquanto não chega na janela de manuteção desse db... []s Chiappa
Re: [oracle_br] Re: Sessão imortal
Eu há muuuito tempo aprendi que esse pessoal : a. só entende NÚMEROS e b. só leva em consideração o que tá escrito e assinado Assim, enquanto técnicos a nossa Obrigação é produzir um documento que mostre a (normalmente alta!) chance de um equipamento falhar, que liste o TEMPO necessário para se comprar outra máquina e reinstalar tudo/voltar backup após um crash (DIAS, pelo menos), o CUSTO para o negócio da indisponibilidade do database em questão (exemplo, multa NFs não emitidas, vendas não concretizadas , processos judiciais abertos por pacientes, enfim) versus o CUSTO de uma mínima infra de disponibilidade (se não tem $$ para RAC nem para disaster recover, ao menos um segundo servidor e um segundo storage), e demandar assinatura de ciência de quem de direitoSó isso : com esse doc na mão Ninguém pode alegar ignorância de custos , é isso O que é uma posição Arriscada é vc não fazer nada, não tem nada em mãos, aí quando acontecer um crash (não é SE, mas QUANDO) neguim vim te cobrar milagre, sim ? Inclusive, cabe uma outra obs : é verdade que ninguém pode te assegurar que a nova versão de database (ou que um eventual patch/patchset) não vai causar problemas com a Aplicação, mas é JUSTAMENTE PARA ISSO que existe o ambiente de Homologação - simplesmente se testa, testa E RETESTA o patch/patchset/upgrade na máquina homologação, que é IGUALZINHA à Prod, contra um servidor homologação da aplicação, é isso... E esse servidor standby/disponibilidade que citei acima Tranquilamente poderia serveir Também como ambiente de Homologação, yes ?? E esse servidor servirá tambpem para vc TESTAR efetivamente a sua política de backup/restore de prod... []s Chiappa
[oracle_br] Re: Remover Datafiles
Uma opção adicional ao utilitários específicos de unlock é a opção de Close Handle do Process Explorer, cfrme mostrada em http://www.howtogeek.com/128680/how-to-delete-move-or-rename-locked-files-in-windows/ : como já sabemos que vc tem o Process Explorer instalado da outra thread, tenta com ele também []s Chiappa
[oracle_br] Re: Sessão imortal
Bom, antes de tudo necessariamente se observa que banco de dados extremamente crítico (para o negócio) e 24x7 mas em 10.2.0.3.0 (com o .0 indicando que NENHUM patch foi Aplicado, E sendo 10gr2 absolutamente sem bugfix e PROVAVELMENTE sem Suporte nenhum, já que dificilmente alguém se coça a pagar Suporte Extendido), é uma Contradição em termos - sorry, mas não parece ser tão crítico assim, se neguim se habilita a rodar na bamba, sem Suporte algum se der pau Isso posto, a resposta : primeira coisa, não sei se vc sabe quando vc faz um ALTER SYSTEM KILL SESSION vc ** não ** está matando a sessão, e sim está mandando ela se matar - assim que puder, ela se matará cfrme vc mandou... A questão é que o KILL foi designado para ser graceful, ie, AVISAR gentilmente o usuário, dando uma mensagem Clara e Auditável para ele tipo ORA-xxx your session was killed, e para isso ele só encerra efetivamente quando o processo do usuário responde que recebeu e exibiu pro usuário final a mensagem - o problema é quando, por qualquer exceção/problema imprevisto o processo que atendia o usuário morreu/ficou bloqueado/ficou irresponsivo : nesse cenário logicamente o RDBMS vai ficar Eternamente esperando a resposta que nunca vai vir... É por isso que se vc ** não tem certeza ** se está tudo OK, o ideal via de regra é pedir um ALTER SYSTEM DISCONNECT SESSION , esse cara não fica esperando por resposta nenhuma, sim ?? Pra este caso que vc já usou o KILL não adianta mais, mas fique sabendo para os próximos... Outra coisa a Avaliar para o futuro é vc avaliar a viabilidade de diminuir o timeout de TCP (que normalmente é longuíssimo no Windows), e no banco implantar DCD e via profile um LIMIT máximo de x horas para as sessões - muitas vezes isso melhora Muitíssimo o tempo que o RDBMS leva para 'perceber' que uma sessão/processo está zumbizando... Continuando : antes de discutirmos , sobre as suas opções ANTES do recycle do database, primeiro de tudo veja em http://www.oracle-base.com/articles/misc/killing-oracle-sessions.php como identificar a sessão e o processo envolvidos. Feito isso, consulte repetidas vezes (com vários minutos de intervalo) a GV$SESSION (veja as colunas de waits/eventos), GV$SESSION_LONGOPS (com um WHERE TIME_REMAINING 0) e a GV$TRANSACTION para ver se está havando algum progresso no rollback ou seja no que for que a sessão a ser morta tá fazendo... Vale também ver GV$TRANSACTION_ENQUEUE, DBA_PENDING_TRANSACTIONS (se vc usa transações remotas) e GV$LOGSTDBY_TRANSACTION/GV$LOGSTDBY_TRANSACTION/GV$XSTREAM_TRANSACTION se vc usa tais features... Com essa informação na mão : SE não está havendo progresso nenhum, acho que a opção que te resta é tentar matar a task diretamente no SO, sem confiar no ORAKILL : o busílis é que o ORAKILL apenas sinaliza para o process ORACLE.EXE no Windows eliminar a thread especificada... A idéia é (** JUNTO COM SEU SYSADMIN!! **) tentar matar diretamente a thread em questão via Process Explorer : esse cara é um utilitário Externo que a m$soft comprou, veja em http://technet.microsoft.com/en-us/sysinternals//bb545021.aspx ... Eu só não sei se eu Arriscaria meu pescoço fazendo coisas do tipo num ambiente sem Suporte nenhum, como Creio que deve ser o caso : pensa aí se é viável ... []s Chiappa
Re: [oracle_br] Alteração no formato de data do ba nco.
Eduardo, não adianta muito procurar pelo em ovo, o que é, é... Está MAIS que documentado (vide manual Oracle SQl Reference) que ALTER SESSION altera apenas e tão somente a sessão corrente - desconectando da sessão vc Rigorosamente Não TEM como ver nenhum efeito do ALTER SESSION executado na sessão que se encerrou, okdoc ?? Isso é CONCEITUAL, Documentado até o extremo, não tem como se aceitar NENHUMA alegação sobre isso... O que ** PODE ** ter acontecido é algo na linha do que o André sugeriu, ie : na sessão que vc fez o ALTER SESSION vc (ou o sistema via trigger ou assemelhados) alterou alguma tabela interna do sistema, aonde a Aplicação mantém o formato de datas que quer usar, okdoc ?? Então o negócio é não aceitar qquer alegação, não aceitar o migué que o pessoal pode estar querendo te dar, e vc (junto com um DBA, se vc não for DBA) ** e ** junto com uma Analista/alguém que conheça a Aplicação : - consultar a v$nls_parameters, principalmente NLS_DATE_FORMAT e NLS_DATE_LANGUAGE - consultar os TRIGGERS que possam estar ativos nesse database - levantar aonde a Aplicação guarda exatamente os parãmetros tipo formato de data, se ficar Comprovado que ela não usa o default do banco mostrado na v$nls_parameters []s Chiappa
Re: RES: [oracle_br] Function SUBSTR
Explica melhor : ao invés de vir 10 caracteres o substr(USERNAME,1,10) tá trazendo mais ou menos caracteres que isso ?? Se sim, Possibilidades : - o banco 11g tá usando a completa inhaca do CURSOR_SHARING : há Dúzias de bugs com esse cara, inclusive de wrong results ou - vc tá usando no banco 11g um characterset double-byte, aonda são usados dois bytes para cada caracter representado : o manual mesmo nos diz : SUBSTR functions The SUBSTR functions (SUBSTR, SUBSTRB, SUBSTRC, SUBSTR2, and SUBSTR4) return a portion of string, beginning at a specified position in the string. The functions vary in how they calculate the length of the substring to return. SUBSTR calculates lengths using characters as defined by the input character set. ou - vc tem algum caracter especial, high-ascii sendo retornado MAS o seu programa-cliente não os interpreta corretamente : DIFICILMENTE se usam caracteres especiais em identificadores internos do database JUSTAMENTE por questões do tipo, mas sabe-se lá... Eu digo pra vc CONSULTAR as propriedades desse database, CONSULTAR os parâmetros não-default setados, CONSULTAR os eventos setados E mandar um : select USERNAME, dump(username), OSUSER,SID,SERIAL#,LAST_CALL_ET ELAPSED,MACHINE FROM V$SESSION WHERE (TYPE 'BACKGROUND') AND (STATUS = 'SNIPED'); e veja o que vc vai ver []s Chiappa
Re: RES: [oracle_br] Function SUBSTR
Acho que entendi a questão, não tem nada a ver com o SUBSTR : pelo que entendo, o SUBSTR está funcionando 100%, trazendo apenas os 10 primeiros caracteres (ou os que existam, se a coluna for menor que 10 cacarcteres), MAS o que ocorre é que no sqlplus se vc não formatar ele assume como largura da coluna na tabela , tipo (num banco 11g) : = veja que ** não tenho ** formato definido para a coluna : 12:24:33 SYSTEM:@sdpr:SQLcolumn username SP2-0046: COLUMN 'username' nÒo definido = faço a consulta : 12:26:06 SYSTEM:@sdpr:SQLl 1 select substrb(USERNAME,1,10) USERNAME,OSUSER,SID,SERIAL#,LAST_CALL_ET ELAPSED,MACHINE 2 FROM V$SESSION 3 WHERE (TYPE 'BACKGROUND') 4 AND (STATUS = 'ACTIVE') 5* ORDER BY ELAPSED DESC 12:26:09 SYSTEM:@sdpr:SQL/ USERNAME OSUSERSID SERIAL# ELAPSED MACHINE -- -- -- -- SIST# CHIAPPA1967\X5001129 208721091 9643 CHIAPPA1967\WIN24 SIST# DCSYSTEMINT 251422683 654 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 174643987 105 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 270727473 94 CHIAPPA1967\WIN0 SYSTEM 137238497 55 WIN72 SIST# DCSYSTEMINT 62929395 54 CHIAPPA1967\WIN0 SYSTEM 137439589 30 WIN72 SYSTEM 194142845 24 WIN72 SIST# CHIAPPA1967\F2200237 172443379 10 CHIAPPA1967\NT937 SIST# CHIAPPA1967\X5000799 232726699 7 CHIAPPA1967\NT937 SIST# CHIAPPA1967\X5000506 99620817 3 CHIAPPA1967\NT1147 SIST# CHIAPPA1967\F4402849 269845645 1 CHIAPPA1967\NT1150 SIST# CHIAPPA1967\X5000735 41613491 0 CHIAPPA1967\NT1147 SYSTEM Y0623080 190911409 0 CHIAPPA1967\01-14207D311327 14 linhas selecionadas. == acima, o SUBSTR ** FUNCIONOU 100% CORRETO **, mas o sqlplus, POR CONTA PRÓPRIA, sem formatação assumiu uma largura para a coluna... Agora VOU indicar que quero para a coluna uma largura de 10 : 12:26:15 SYSTEM:@sdpr:SQLcolumn username format a10 12:26:29 SYSTEM:@sdpr:SQLl 1 select substrb(USERNAME,1,10) USERNAME,OSUSER,SID,SERIAL#,LAST_CALL_ET ELAPSED,MACHINE 2 FROM V$SESSION 3 WHERE (TYPE 'BACKGROUND') 4 AND (STATUS = 'ACTIVE') 5* ORDER BY ELAPSED DESC 12:26:32 SYSTEM:@sdpr:SQL/ USERNAME OSUSERSID SERIAL#ELAPSED MACHINE -- -- -- -- SIST# CHIAPPA1967\X5001129 208721091 9660 CHIAPPA1967\WIN24 SIST# DCSYSTEMINT 251422683671 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 174643987122 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 270727473111 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 62929395 71 CHIAPPA1967\WIN0 SIST# CHIAPPA1967\X5000799 232726699 24 CHIAPPA1967\NT937 SIST# CHIAPPA1967\X5000506 99620817 20 CHIAPPA1967\NT1147 SIST# DCSYSTEMINT 192933667 5 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 229448935 1 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 151929621 0 CHIAPPA1967\WIN0 SIST# DCSYSTEMINT 58250161 0 CHIAPPA1967\WIN0 SYSTEM Y0623080 190911409 0 CHIAPPA1967\01-14207D311327 12 linhas selecionadas. == TÁ VENDO (se a formatação do yahoo!groups deixar:) como está com 10 caracteres de largura a coluna ??? Pra mim é ISSO que vc está vendo aí : SUBSTR funcionando 100% certo mas sqlplus ASSUMINDO uma largura para a coluna e portando mostrado brancos na tela, yes ?? []s Chiappa
Re: [oracle_br] UTL_FILE
Pode ser, né André ? Alessandro, a ** primeira ** coisa que se faz ao debugar uma rotina PL/SQL é, se possível/viável, justamente se desativar temporariamente, comentando) as EXCEPTIONS pra vc receber o erro puro, sem tratamente de nenhum tipo... Outra possibilidade é que o tal banco novo 11g esteja num novo servidor, e nesse novo servidor o path C:\ não esteja Autorizado para o usuário do Sistema Operacional que instalou e roda o RDBMS Oracle, e/ou o arquivo LISTA.TXT já exista e o usuário em questão não tenha acesso á ele, sim ? Ao colocar * no UTL_FILE_DIR, vc diz PARA O RDBMS que qquer path é válido, mas AINDA CONTINUA sendo preciso Autorização no Sistema Operacional... INCLUSIVE, vc não diz mas o C:\ indica que o servidor do RDBMS é Windows : vc ** sabe ** que nos Windows mais recentes (de Win7 para cima) nós temos a figura do UAC, ** e ** neles as pastas-ráiz dos drives via de regra Não São mais liberadas pra todo mundo, okdoc ? Veja isso também... []s Chiappa
[oracle_br] Re: APEX
Embora eu já não desenvolva, alguns clientes meus estão com muito interesse no APEX e participei (como Suporte de banco) de uns aconselhamentos pra eles, então até conheço um bom tanto da teoria e fas funcionalidades básicas do sujeito... De modo geral, as coisas positivas do APEX são : - ele roda dentro do database Oracle, em PL/SQL, então utiliza naturalmente e de forma transparente todas as vantagens do PL/SQL, tais como cache próprio do p-code pl/sql, encapsulamento em packages, bind variables automáticas e transparentes, variáveis do tipo ROWTYPE para vc receber registros de dados, versionamento de seus programas com Editions, e todas aqueleas que já discutimos tantas vezes aqui no Fórum e a documentação do PL/SQL e o site http://www.oracle.com/technetwork/database/features/plsql/index.html discutem/mostram - aproveita transparentemente todas as opções de escalonamento/HA/segurança/performance do database (de RAC à DG, de result cachesets a pool de conexões nativo do database, e etc, etc, o APEX pode se beneficiar de modo transparente e natural, sem absolutamente nenhuma necessidade de re-escrita, add-ons ou quetais, já que ele roda dentro do database E é um produto criado pela mesma empresa do database - curva de aprendizado MUITO menor que alghumas outras alternativas : principalmente comparando com o mundo de programação Java, onde além da linguagem (que já não é nem simples nem focada em processamento de dados, ao contrário do PL/SQL) vc TEM que dominar um sem-número de outras APis/add-ons/complementos (se começa a falar rapidamente em JPA, JSP, beans, JADE, a sopa de letrinhas e de softwares vai longe), o APEX é consideravelmente mais simples... Foi exatamente essa simplicidade e leveza que levou as empresas que citei / atendi a desconsiderar outras opções, além do fato de que eles não dispunham de pessoal especializado em desenvolvimento WEB... O ponto principal negativo do APEX, porém, é bem importante : ele tem ** limitações **, tem máximos de recursos/componentes que vc pode usar numa página web : há máximo de regiões atualizáveis/dinãmicas na página, máximo de backgrouns, máximo de colunas a recuperar do database por página, máximo de itens que vc pode ter numa página A cada release esses máximos vem subindo mas de forma geral eles Existem : assim, se a sua aplicação é um dasboard, com ** centenas ** de colunas/itens, com dezenas de painéis, etc, PROVAVELMENTE o APEX não vai te satisfazer/atender Alguns recursos bons para vc tomar conhecimento na tecnologia : http://www.enkitec.com/arc (um Portal de uma consultoria gringa com montes de exemplos, demos e artigos especificamente sobre o APEX), http://www.inside-oracle-apex.com/ , http://www.apex-at-work.com/ , http://apex2rule-the-world.blogspot.com.br/, http://discoverapex.com/ , https://cdivilly.wordpress.com/ , http://apexresource.wordpress.com/ , http://joelkallman.blogspot.com.br/ , http://www.apex-home.com , http://www.easyapex.com/index.php , http://dgielis.blogspot.com.br/, http://sysdba.wordpress.com/ e http://apex-evangelists.com/index.html (este é um concentrador de blogs e artigos, e não casualmente vc verá que quase TODOS os autores dos blogs/portais que citei tão lá)... Outro recurso muuuito legal é http://www.oracle.com/technetwork/tutorials/index.html : como a Oracle tá incentivando bastante o APEX, nesse portal de demos , cursos e tutoriais/how-tos da Oracle se vc procurar por APEX ou por Application Express vc acha Toneladas []s Chiappa
Re: [oracle_br] APEX
Tudo jóia ? Então, é absolutamente válido o cenário que vc propõe : a página do APEX (e a de download) no technet Oracle diretamente explicita que o APEX é grátis em qualquer ambiente E roda inclusive no XE, e como o database XE/Express Edition é grátis para usar aonde quiser, com quantos usuários quiser conectando nele (veja no Contrato na hora do download que em nenhum momento se toca em qtdade de usuário, ambiente web ou nçao, nada), em hardware de produção ou não, e usar como quiser com o que já vem nele, DESDE que seja uma instãncia só no servidor (as opções/add-ons que demandam Licença paga, como os packs, RAC, dataguard avançado, etc, simplesmente Não Existem no instalador dele e não tem como vc as instalar depois) SIM, vc pode usar o APEX livremente no XE até os limites do XE inclusive para aplicações que vá vender, para processar dados reais de produção, como desejar OBVIAMENTE as limitações de tamanho máximo/capacidade do XE são ** severas **, até para não canibalizar mercado dos RDBMSs de entrada da Oracle (como o Standard Edition), mas para uma aplicação de pequeno porte, não vejo nenhum issue ... Um dos meus antigos clientes na última vez que ouvi falar estava na reta final de implementar um módulo do sistema de frente de caixa com XE e APEX, sem problema algum, a não ser justamente a questão dos limites impostos ao XE... []s Chiappa
Re: [oracle_br] APEX
Na verdade nem é especificamente (ou somente) javascript, alguns os templates normalmente são custom stylesheets descritas em html, cfrme http://www.apexninjas.com/blog/2011/03/customizing-report-templates/ por exemplo exemplifica - mas realmente é como eu disse em outras msgs de outras threads, a principal dificuldade de quem vem do Forms é que lá vc tinha built-ins prontas e documentadas para mudar comportamento de tela, de navegação, de quase tudo, e nas tools web (já que vc está executando a aplicação em web browsers, que só entendem ou html ou alguma forma de java, principalmente) vc acaba tendo que escrever alguma coisa extra... Essa realmente é uma vantagem do formspyder, e é mais por isso, penso eu, que ele é cobrado : vc está pagando o custo dos desenvolvedores lá deles terem escrito as tais rotinas todas para vc... E óbvio, Nem Sempre seja qual for a tool vai ter Todas as rotinas que vc possa precisar para customizar comportamento de telas/navegação/etc no browser prontinhas - as mais comuns vão estar lá, ok, mas não confiemos que toda e qualquer necessidade vão ser sempre supridas pelas rotinas já desenvolvidas/fornecidas, Pode bem Ser que em algum momento ainda se precise escrever algo... []s Chiappa
Re: [oracle_br] APEX
Só pra deixar Escrupulosamente Claro pra quem for ler essa thread no futuro : os limites do APEX Absolutamente Não são a quantidade de páginas na aplicação , não são a quantidade de dados processados... VC pode ter milhares e milhares de páginas, como vc testemunha, sem prob algum, a questão é por página... O manual mesmo (Oracle® Application Express Application Builder User's Guide Release 4.0, apendix B : Oracle Application Express Limits) entre outros cita : One interactive report per page 100 columns can be seen using report columns. You can edit additional columns using Tree view or paginating through Report Column Attributes. 999 rows per column heading filter (if no custom LOV is specified in the column attributes) Forms 100 enterable items per page 32767 bytes for a text area or rich text editor item Two columns for primary key (when using built in DML processes) See Also: Creating Forms Tabular Forms 1 wizard-generated tabular form per page (using built-in DML) 50 editable tabular form columns (apex_application.g_f01-apex_application.g_f50), generated with apex_item or the built-in tabular form display types == OU SEJA, é limites POR PÁGINA como eu disse : vc pode ter quantas páginas quiser (ou quase isso) mas em UMA página só pode ter as x coluns acima, a PK deve ser de no máximo 2 colunas para Forms, no máximo 50 tabular columns Como eu falei, se a aplicação DEMANDA que numa única página vc tenha trocentos itens, centenas de colunas, etc (é um dashboard, digamos) aó é que se cai nos limites, se não, não se aplicam []s Chiappa
[oracle_br] Re: ORA-00904: TESTE_TESTE: invalid identifier
Pelo jeito parece ser é erro de digitação, ao invés de TESTE.TESTE, separada por PONTO (para indicar view TESTE que pertence schema TESTE) talvez vc tenha escrito TESTE_TESTE, TESTE_TESTE ou outra combinação parecida, separa por UNDERSCORE, o que não faz sentido... Isso explicaria a msg de erro que se refere à TESTE_TESTE ... Mostra pra gente o comando Completo que de cara a gente já vê se é isso ou não... []s Chiappa
Re: [oracle_br] Re: ORA-00904: TESTE_TESTE: invalid identifier
Ah, agora tá clara a mensagem : esse objeto TEXTO_FASE (deve ser uma função, pelo jeito) simplesmente não está acessível (vc tem que dar o privilégio de EXECUTE nela) e/ou está criada num schema diferente (aí OU vc indica o owner especificando nomedoowner.TEXTO_FASE(, OU vc cria um sinônimo TEXTO_FASE apontando para nomedowoner.TEXTOFASE), é isso E a pergunta importante : na sessão que está tentando fazer o DDDL, vc está conectado como TESTE ou como TESTE2 ?? Se possível, para facilitar o debug, eu sugiro que essa sessão que está tentando criar a view TESTE2.MV_PRODIST_MEDIDOR esteja conectada como TESTE2 mesmo, okdoc ?? []s Chiappa
[oracle_br] Re: Problema EXPDP...
Então : ** primeira ** coisa que vc tem que saber é que para limpar jobs perdidos do datapump ABSOLUTAMENTE Não basta vc matar a sessão - vc PODE ter que limpar a master table, PODE ter que liberar o job... Veja http://arjudba.blogspot.com.br/2009/05/how-to-cleanup-orphaned-datapump-jobs.html como exemplo e siga os procedimentos lá DEPOIS que vc tiver feito os passos mostrados no link, aí sim vc vai re-executar , mas tomando antes o Cuidado de confirmar que : não existem sessões longas ativas na gv$session_longops (para isso vc faz um SELECT * FROM GV$SESSION_LONGOPS WHERE TIME_REMAINING 0 numa tool GUI, que permita exibir linhas longas sem quebra), que NÂO há outras sessões usando a API do datapump (SELECT DISTINCT PROGRAM, MODULE, CLIENT_INFO,PROGRAM, PROCESS, MACHINE, TERMINAL FROM GV$SESSION), E (além das views de jobs do datapumpt que vc verificou no link) veja que não há outros JOBs quebrados/conflitantes na DBA_JOBS e/ou na DBA_SCHEDULER_JOBS []s Chiappa
Re: [oracle_br] Re: Problema EXPDP...
Na verdade não é que segure - se vc não remover a master table E limpar as entradas dos jobs datapump perdidos, a re-execução vai criar outra master table, outro job datapump, ok, não ficando bloqueda, MAS o scheduler interno do datapump vai continuar tentando executar aquele job que ele acha que está presente, e não vai conseguir , e aí vai tentar de novo e de novo, isso vai comendo e comendo recursos, pode facilmente interferir na performance a ponto de a re-execução aparentar estar bloqueada, sim... []s Chiappa
Re: [oracle_br] Problema EXPDP...
Muito bem lembrada, essa sempre é uma possibilidade : no caso acho que não se aplica, já que (iirc) o RDBMS adiciona uma entrada no alert.log quando uma sessão entra em resumable state e o colega lá disse que não tinha nenhuma msg disso no alerta, mas taí a obs, não custa ele verificar []s Chiappa
[oracle_br] Re: Como obter a linha que ocorreu um exception
Sendo banco 10g ou superior (vc Não nos diz essa crucial info) vc pode usar a DBMS_UTILITY.FORMAT_ERROR_BACKTRACE , cfrme http://www.oracle-developer.net/display.php?id=318 exemplifica : no caso ele exibe via DBMS_OUTPUT, mas claro que vc pode gravar numa tabela sua... Só uma obs : vc pode gravar a exception numa tabela, serve inclusive para log, legal, mas vc ** TEM ** que sinalizar o consumidor da tua procedure que algo falhou, provavelmente com algum RAISE, ou mesmo com RAISE_APPLICATION_ERROR - se vc apenas logar e nada mais, o COnsumidor da tua procedure simplesmente NÂO TEM como saber que algo deu errado, aí vc estaria simplesmente MASCARANDO, ENGOLINDO o erro... Via de regra isso Não É uma Boa coisa []s Chiappa
[oracle_br] Re: Formatar null
Dá um bico na documentação Oracle (nos itens sobre NLS e number format masks) que vc verá que o caracter 9 na máscara só exibe dígitos significativos, para exibir zeros à esquerda vc usa o caracter 0 na máscara , exemplo : SYSTEM@O10GR2:SQLcreate table T(c1 number); Tabela criada. SYSTEM@O10GR2:SQLinsert into T values (123.45); 1 linha criada. SYSTEM@O10GR2:SQLinsert into T values (null); 1 linha criada. SYSTEM@O10GR2:SQLselect to_char (nvl(c1,0), 'FM099G999G999D90', 'nls_numeric_characters='',.''') from t; TO_CHAR(NVL(C1, --- 000.000.123,45 000.000.000,00 SYSTEM@O10GR2:SQL []s Chiappa
[oracle_br] Conectar como usuário sem saber a senha
Pessoal, para uma determinada atividade que precisei executar, eu tive a
necessidade de conectar como um determinado usuário da Aplicação no banco ,
usuário esse que desconhecia a senha, E um simples ALTER SESSION SET
CURRENT_SCHEMA não funcionaria (princiopalmente por ter que executar stored
PL/SQLs) : não é nada tão incomum, às vezes acontece...
Nesses casos o procedimento comum é conectar como DBA no banco, consultar a
senha do usuário desejado criptografada na DBA_USERS (ou na USER$ se for banco
11g), pedir um ALTER USER nomedousuario IDENTIFIED BY senhatemporariaqualquer;
conectar no usuário desejado e imediatamente voltar a senha ao que estava antes
com um ALTER USER nomedousuario IDENTIFIED BY VALUES
('stringdasenhacriptografada').
Essa técnica funciona desde sempre mas tem a desvantagem de, por uns segundos
que seja, o usuário desejado ficar com a senha alterada, o que pode facilmente
causar interrupção na aplicação, além de ser um tanto complexo de se fazer .
Hoje porém eu encontrei a referência em
http://www.dbsnaps.com/oracle/connect-as-an-oracle-user-without-knowing-the-password/
que na versão 10g, que é o que temos aqui em produção (o recurso existe no
sqlplus de 10gr2 em diante, iirc) o sqlplus já aceita conexão por proxy, aí
botei a mão na consciência e me perguntei porque não usar o recurso, né ? Dãã
pra mim... Então fiz assim :
a. conectei no banco como SYSDBA
b. temporariamente dei para um outro usuário que nós tinhamos a senha a
permissão de conectar como se fosse o usuário desejado :
SYS:AS SYSDBA:SQLalter user USER_APLIC grant connect through
USER_COM_SENHA_CONHECIDA;
User altered.
c. conectei num outra sqlplus como o usuário que temos a senha mas fazendo
proxy no usuário realmente desejado :
USER_COM_SENHA_CONHECIDA::SQLconn
USER_COM_SENHA_CONHECIDA[USER_APLIC]/senhaconhecida
Connected.
USER_APLIC::SQLshow user
USER is USER_APLIC
d. no sqlplus original removi do usuário que conhecemos a senha a permissão de
conectar via proxy :
SYS:AS SYSDBA:SQLalter user USER_APLIC revoke connect through
USER_COM_SENHA_CONHECIDA;
User altered.
e é isso... Achei mais simples de fazer e absolutamente não perturba a
Aplicação nem o pool de conexões nem nada, fikadika ...
Abraços,
José Laurindo Chiappa
OBS :
a. o link não fala, mas por segurança o RDBMS exige que o usuário com a senha
já conhecida e que vai receber o GRANT ** não seja ** um usuário privilegiado,
senão ele rejeita a operação com ORA-28150 :
:@:SQLconn system[userdestino]/senhadosystem
ERROR:
ORA-28150: proxy not authorized to connect as client
b. DE FORMA ALGUMA isso que eu disse é um hack, um 'segredo interno' : essa
técnica está Plenamente Documentada nos manuais Oracle, então não temos por que
não divulgar...
c. Falando sobre segurança, ela nos lembra o QUANTO é ultra-mega-poderoso o
privilégio de ALTER USER, e o perigo que é dar esse privilégio para qualquer um
que não é DBA... É um pouco parecido com o privilégio de ALTER SESSION, que
muita gente pede e recebe sem pensar duas vezes mas que dá pra fazer muuuito
estrago, principalmente ativando eventos na sessão
Re: [oracle_br] Oracle Database 7 e 8i
VC pode tentar o Oracle SQL Developer mesmo, que é bem simples de configurar, OU o Console OEM do Oracle 9i (se vc tiver os DVDs do 9i em mãos, essa pode ser uma Excelente opção), pois esse console é em Java e iirc pode conectar via jdbc thin, sem client, OU o SQL Workbench em http://www.sql-workbench.net/ Mas atente que : a. como eu disse antes, PODE SER que vc precise baixar uma versão mais antiga do aplicativo (o SQL Developer iirc vc acha as versões antigas no technet da Oracle, mesmo) e/ou precise de um driver jdbc mais antigo que 10g (vc normalmente os scha no mesmo disco que o client Oracle, nos pacotes de instalação dos databases antigos) b. vc TEM que se assegurar que os bancos 7 e o banco 8.x estejam sendo servidor por um Listener ** anterior ** ao 10g , E QUE a conexão seja por SID, definido no LISTENER.ORA okdoc ?? E isso falando de conexão java - vc ** TEM ** que tentar Também a opção de instalar numa ORACLE_HOME à parte um client mais antigo que 10g E com esse client (atenção à configuração da tool escolhida para que ela use ESSE CLIENT ANTIGO) tentar conectar nos bancos v7 e 8.x, o que normalmente vai exigir uma versão antiga tambpem do programa de administração : caso vc não tenha/não encontre versões antigas do TOAD e do PL/SQL Developer, outras tools clientes que vc pode tentar com o client antigo são SQLTOOLS em http://sourceforge.net/projects/sqlt/ (no site diz que conecta com 8i, então há chances de que também conecte via SID com 8.0.x e com v7), TOra em http://torasql.com/Download (seguindo os links de download vc acha até versão 1.3.18 de 2005) , entre outras... []s Chiappa OBS : é ÓBVIO, tudo isto é á parte, além da opção simples e que deve Funcionar SIM, que é usar o sqlplus que vem junto com o client antigo, OU mesmo simplesmente conectar no servidor v7 ou 8.0.x e usar o sqlplus de lá, conectando Diretamente, sem listener, okdoc ??
[oracle_br] Re: Session Inactive
Bom, primeiro fique Claro que se a sessão está ** REALMENTE ** inativa, ela não está processando NADA (não tá executando SQL nenhum, não tá esperando o SO fazer alguma coisa, tá realmente inativa no momento), Obviamente Não está consumindo nem I/O nem CPU, okdoc ?? Ambas as coisas deixam de ser consumidas quando o SQL que a sessão estava executando terminou... Memória E espaço temporário sim, em determinadas circunstâncias pode acontecer da memória que foi alocada e/ou do espaço temporário alocado para um SQL na sessão não ser liberados imediatamente após o SQL terminar de ser executado, só sendo liberados ao fim da transação (com COMMIT ou ROLLBACK) ou mesmo só quando a sessão desconecta... Para vc ver a memória alocada para uma sessão (PGA, que é particular, e SGA, que é Compartilhada) é consultar a (g)v$sesstat, tipo : select b.sid, a.name, b.value from v$statname a, v$sesstat b where a.statistic# = b.statistic# and a.name like '%ga memory%'; É claro, nela não consta a informação se a sessão está inativa ou não, nem há quanto tempo está inativa : então o ideal é juntar com a (g)V$SESSION, mesmo : select s.value as Memory_Usage , n.name|| '(stat#='||s.statistic#||')' as memory_type , a.sid from v$sesstat s, v$statname n, v$session a where s.statistic# = n.statistic# and s.sid = a.sid and a.status='INACTIVE' and a.type= 'USER' and n.name like ‘%ga memory%’ order by s.value; Já para vc ver espaço temporário , consulte a (g)V$SORT_USAGE, tipo : select su.* from v$session s, v$sort_usage su where s.saddr=su.session_addr and s.status='INACTIVE' and s.type= 'USER' ; []s Chiappa
[oracle_br] Re: Session Inactive
Ah, um detalhe importante que esqueci : uma sessão inativa mas que possui Transação aberta além do eventual consumo de memória e de temp space evidentemente tá consumindo espaço de rollback/undo, é Claro : para vc consultar isso, a query seria + ou - : column sid format 999 column segment_name format a15 select b.segment_name, a.username, a.sid, a.serial#, c.used_ublk, c.used_urec,c.START_UBAFIL, c.START_UBABLK, c.START_UBAREC , b.status, b.TABLESPACE_NAME, b.SEGMENT_ID, b.FILE_ID, b.BLOCK_ID from v$session a, dba_rollback_segs b, v$transaction c where b.segment_id = c.xidusn and a.taddr = c.addr ;
[oracle_br] Re: HELP
Bom, antes de responder lembro que num ambiente Corretamente controlado vc Absolutamente não precisaria disto, pois : a. todo e qualquer código-fonte (INCLUSIVE stored PL/SQLs) deveria estar contido num sistema de Vesrionamento, justamente para controlar as diferentes versões/releases E b. na produção, apenas o DBA e/ou (no máximo) um Analista-chefe, que sabe o que está fazendo, é quem (mediante uma requisição de alteração formal, que MANTÈM um histórico pesquisável!) é quem saem fazendo DDLs de qualquer tipo com esses dois fatores, naturalmente vc já teria um histórico E seria capaz de fazer rollback de qualquer alteração, em tese E AINDA vc tem a vantagem de Revisão do Código : por mais perfunctório que seja o review que o DBA/Analista-chefe faz, ao menos algum código terrivelmente ineficiente e/ou malicioso em alto grau ele pega - se vc deixa qquer um sair colocando código no db de produção, salve-se quem puder... Isto posto, a resposta : se realmente o seu ambiente ainda não está otimamente controlado e portanto precisa de coisas do tipo, eu não tenho código pronto para isso mas tenta adaptar o código mostrado em http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:267415465220#4149424900346580446 , que vc deve ser capaz Eu IMAGINO que no seu caso vc teria uma tabela pré-criada á semelhança da DBA_SOURCE e no código da tal trigger (que seria BEFORE) aí vc identifica o objeto pelas built-ins tipo ora_dict_obj_xxx , consulta a DBA_SOURCE e copia as linhas da DBA_SOURCE referentes ao objeto que será alterado, penso... A opção de usara DBMS_METADATA também existe mas deve ser testada COM CUIDADO EXTREMO, dada a performance nem sempre brilhante dessa DBMS []s Chiappa
[oracle_br] Re: Consulta ao Grupo - Off Topic
Bem, já faz tempo que não tive mais ocasião de trabalhar como Analista de Sistemas mas pelo que ouço falar dos amigos que trabalham nessa área aqui em SP/Capital, para um Sênior que além de bastante tempo de estrada de modo geral ainda possui Domínio completo das tools/técnicas/procedimentos de Análise que a Empresa usa, é algo de R$ 7.000 a R$ 8.000 como CLT ou coisa de uns R$ 60 a R$ 65/hora como PJ Isso PODE e VAI ter variações, dependendo de fatores como Localização da Empresa, pacote de benefícios, plano de carreira lá dentro, etc, etc, mas de modo geral espere alguma coisa nessa faixa, mais ou menos... []s Chiappa OBS : ** lógico **, se a negociação evoluir positivamente, vc Não Pode deixar de vir até aqui (ou no mínimo pesquisar com os profissionais adequados, e/ou fazer um levantamento pela internet) dos teus Custos, como moradia, educação, transporte... O custo de vida em geral aqui está bem alto, e esses componentes que citei estão entre os que mais subiram recentemente...
Re: [oracle_br] Oracle Database 7 e 8i
Wanderson, pmji mas é ** natural e Esperado ** que o client 10g não funcione : cfrme eu disse na minha resposta anterior neste tópico, o client 10g não é mais Suportado em conexões a bancos mais antigos que ele mesmo... Assim, esqueça o client 10g e use uma das alternativas que dei na minha resposta anterior, ie : a) client ainda mais antigo - é certeza que o client 9i conecta no db 8i e num eventual 8.0.x , só não tenho certeza do banco v7, veja lá... Uma vez que vc tenha um client compatível com os bancos antigos (client esse instalado numa ORACLE_HOME própria, óbvio), CONFIRA na sua tool de administração comoquefaz# pra que ela use o tal client antigo : nalgumas, como o TOAD, lembre que tinha um botão de configuração tns que permitia vc indicar a ORACLE_HOME que vc quer, em outras tools pode ser que vc tenha que setar TNS_ADMIN, vareia... ou b) passe a usar software em Java, que conecte via JDBC Thin, Sem client algum : há Trocentas opções pelaí, tanto free quanto não []s Chiappa OBS : 1. dada a DNA (data de nascimento Avançada) do banco v7 e dos 8.0.x/8i, até PODE SER que alguma das opção acima (mais provável a) , já que JDBC thin dificilmente tem exigência de versões) exija uma versão mais antiga do próprio software de administração... A conferir ... 2. não deixe de experimentar, se tiver um DVD de instalação do banco 9i sobrando por aí, a opção do Console de administração 9i : dado o tempo que foi lançado, é Provável que ele possa ser usado com bancos mais antigos
[oracle_br] Re: RMAN restauração de backups em plataformas diferen tes
Sobre o RESTORE, o ideal e recomendado sempre é ter a mesma exata versão do SO tanto na origem quanto no destino , mas sendo a diferença de SO tão pequena quanto o que sabemos que foi do RH 4.x para o 5.x , é quae certo que vc consigam, eu diria uns 99% de chance, é quase certo ** mesmo ** que vc vai conseguir sem probs... Sobre as outras perguntas : 1. Backups do RMAN em versões diferentes do Oracle do 10g para o 11g funcionam, utilizando a mesma plataforma funciona? Funcionam, mas já que os datafiles backupeados estão com cabeçalho formato 10g, E as tabelas/views internas da tablespace SYSTEM também estão na versão 10g, vc Logicamente vai ter que fazer o UPGRADE desse database, yep ?? Isso implica em rodar no 10g o script de pré-upgrade e corrigir as incompatibilidades encontradas/apontadas pelo script ** ANTES ** de fazer o backup no 10g , yes ??? Vc vai ver que ele pode mandar botar uma coluninha a mais em tabelas internas, remover / alterar alguma feature incompatível, alterar algums params de inicialização, e outras coisinhas Isso estando OK, é simplesmente fazer o backup completo no 10g, ter um pfile apropriado, iniciar a instância 11g em NOMOUNT, restaurar o controlfile, deixar em MOUNT, se preciso catalogar o novo backup no catalog db, e aí fazer o restore (JUNTO com tudo mais que precise, tal como SET NEWNAME e o que mais for preciso... Depois vc deverpa ser totalmente capaz de abrir com alter database open resetlogs upgrade; e rodar os scripts de upgrade todos 2. Backups do RMAN com onde os bancos de dados tem a mesma versão, mas funcionam em plataformas com arquiteturas diferentes 32 para 64 bits? Funciona sim : veja a nota metalink RMAN Restore a 32 bit Database to 64 bit - Description and Example (Doc ID 467676.1) e os links dela 3. Backups do RMAN onde os bancos de dados tem a mesma versão, mas com plataformas diferentes que seguem a mesma a arquitetura, por exemplo: Windows x64 para um RedHat x64? Há restrições : embora o bitsize seja o mesmo, SOs diferentes podem ter endianness (ordenação interna de números longos, veja http://pt.wikipedia.org/wiki/Extremidade_%28ordena%C3%A7%C3%A3o%29) em diferentes formatos, e isso pode dar diferença == No ** SEU caso específico ** que vc pergunta (ie, Windows x64 - Linux x64) ambos são Little-Endian (mesmo endian-type) então vc PODE usar as opções de conversão para converter um backup RMAN comum completo de um para outro SO... Fossem ambos ambientes 64-bits mas com endian-type diferentes (por exemplo, Linux 64-bits - que é little-endian - para AIX ou Solaris 64-bits - que são big-endian), vc não conseguiria converter um database inteiro, aí vc teria que fazer backup a nível de tablespace incluindo os metadados (TRANSPORTABLE TABLESPACES) ou fazer backup lógico, via export, ou usar algum tipo de replicação enviando os dados de um db para o outro... para mais detalhes, veja a nota Migration Of An Oracle Database Across OS Platforms (Generic Platform) (Doc ID 733205.1) []s Chiappa
Re: [oracle_br] Executar arquivo
Seguinte, colega : nas linguagens nativas do database Oracle (ie, SQL e PL/SQL) vc Rigorosamente não tem NADA que permita abrir arquivos Excel, PONTO. E Muito menos executar macros e coisaradas do tipo... Sendo assim, a minha Sugestão é : - SE essa tarefa de ler dados da planilha e (presumivelmente) inserir no banco é algo que Não vai ser Rotineiro, simplesmente abra a planilha no Excel, faça o que tem que fazer e depois salve os dados num arquivo-texto (seja texto puro, seja HTML, seja XML, mas texto) que depois vc carrega no database... Essa é, Sem Dúvida, imho, a opção mais simples e direta, se vc conhecer um pouco de programação no Excel... - CASO isso seja rotineiro, aí sim partir pra programação, que como eu disse acima ** VAI ** envolver algum recurso/configuração não-padrão do database Poderiam ser, entre outros : a. ** inverter ** o fluxo, ie : ao invés de abrir o arquivo no database, abra o arquivo nalguma máquina cliente que tenha Excel e que tenha client Oracle , e programar e EXCEL se conectar ao database Oracle, sim ??? ou b. (se tiver MESMO que ser pelo RDBMS) se por acaso o RDBMS tá instalado numa máquina que contenha algum software de Office (seja Microsoft Office, Open Office, o que for), que seja capaz de abrir a tua planilha Excel, executar o tal software via PL/SQL ou c. instalar/configurar no database a JVM da Oracle, existem diversas bibliotecas/rotinas semi-prontas em Java para vc manipular arquivos Excel basicamente essas as suas opções... googla por ORACLE READ EXCEL FILE, por EXCEL CONNECT ORACLE DATABASE e por PL/SQL EXECUTE EXTERNAL PROGRAM que vc acha n refs e exemplos de todas elas... []s Chiappa
Re: [oracle_br] Executar arquivo
Ops, sorry : o comentário referente á opção programática dentro do excel ser a mais direta obviamente se refere ao item a []s Chiappa
Re: [oracle_br] Re: Dúvidas - Licenciamento de servidor Standby/Contingência
Yep, eu deveria ter deixado mais claro que, ALÉM do database stand-by nunca estar disponível, os documentos Exigem também, para que se possa usar o direito de failover sem licença, que o servidor de failover esteja no mesmo local e use o mesmo storage - como meus últimos clientes foram datacenters aonde isso acontecia, não explicitei No seu caso, sendo HA (o que é explicitado pela localização remota do servidor stand-by), afaik vc não se encaixa nas condições, então vc terá sim que licenciar esse standby - e no meu caso, nas Empresas aonde usei HA não participei do processo de licenciamento (já havia licença universal) então não tenho um caso real pra te repassar de exemplo... Agora , o que posso dizer é que vc deve notar, porém, é que embora todos exijam que o standby seja licenciado, em momento nenhum é exigido que seja no mesmo modelo de licença do principal em todos os casos, okdoc ? Assim, mesmo que o servidor primário esteja usando uma licença mais cara, por processador digamos, nada impede a meu ver que vc licencie por named user plus, digamos, o servidor standby, custando bem menos, ok ?? O documento http://www.oracle.com/us/corporate/pricing/data-recovery-licensing-070587.pdf inclusive nos diz : Additionally, when licensing by Named User Plus, the user minimums are waived on one failover node only. Assim para mim tá CLARO que existe a possibilidade de vc licenciar um failover via NUP, senão não estaria documentado, certo ?? E na minha Análise, apenas configurações de failover EM CLUSTER é que demandam usar a mesma exata métrica de licença no primary e no standby, cfrme (no mesmo documento acima, ênfase com *s minha) : In a failover environment,the same license metric must be used forthe production and failover nodes *** when licensing a given clustered configuration *** E quando tiver a falha/crash no banco primário e o failover tiver que ser acionado ? O que imho vai te cobrir aí é o fato pouco conhecido que a licença de uso do database produção, que está em uso, Absolutamente ** Não é ** amarrada a um servidor, sim ?? Então se eu estou rodando no servidor x aqui em são paulo meu database produção e amanhã eu cismo de desligar ele aqui e passar a rodar ele num servidor y lá no Rio, digamos, a Oracle não pode dar um pio : claramente o Contrato de Licença não indica em QUAL servidor o software precisa executar Assim, eu entendo que simplesmente no caso de crash funciona como se vc tivesse transferido o database de servidor, operação que é Absolutamente permitida pela licença O que é exigido é que se eu num dado momento a Empresa tem x servidores com databases produção sendo usados, vc tem que apresentar x licenças, Evidentemente respeitando-se capacidade do hardware se licenciamento por processor ou qtdade de usuários se licenciamento por nup ... E eu estou falando aqui da licença básica, de uso - a exceção ao que eu disse, claro, são as Options e licenças opcionais : se vc usa qualquer uma delas no banco primary e quer (ou é obrigado a) continuar usando no banco standby, EVIDENTEMENTE elas tem que ser lcienciadas no standby , cfrme : If any Option or Management Pack (except RAC) is licensed on the primary server, then it must also be licensed on the Standby server. If RAC is on the primary server but not on the standby server, then licensing it is not required. Blz ? Evidentemente eu não sou Advogado nem especialista em Licenciamento, mas as coisas que te disse acima são SIM especificadas na documentação cujo link apresentei, então vc (ou o Jurídico da tua Empresa, devidamente municiado por vc com os docs e textos como este) Não Vai aceitar a alegação que certamente o teu representante Oracle vai apresentar, que a licença do standy tem que ser absolutamente igual á do primary, sim ?? Esse pessoal quer vender, tem metas a cumprir E a comissão é em cima do valor vendido, então é Claro que vão te apresentar o que custa mais, sempre... É uma negociação um tanto dura mas se vc ir pra ele, municiado e com doc na mão, vc já sai em vantagem... []s Chiappa
Re: [oracle_br] Re: Dúvidas - Licenciamento de serv idor Standby/Contingência
No caso de standby (físico, que ao que entendi é o que o colega lá quer usar) eu entendo que se houver um usuário específico que conecta no banco mount e faz o apply, esse usuário não-humano está suficientemente identificado e suas conexoes podem ser auditadas e contadas, então entendo que pode sim ser usado NUP... Eu realmente tentaria uma argumentação nesse sentido... []s Chiappa
Re: [oracle_br] Re: Dúvidas - Licenciamento de servidor Standby/Contingência
Eu não tinha visto essa do Software Investment Guide : se ele afirma, sem restrições, que a licença do standby (e sem citar dataguard ou produto, ele está falando da técnica de standby) deve ser a mesma que o primary, miou... O máximo que vc vai conseguir poupar aí é a licença do RAC (se vc não vai ter RAC no standby), ou alguma eventual feature/add-on opcional que vc tenha no primary e naõ precise no standby, afora isso neca pelo jeito... []s Chiappa
[oracle_br] Re: Store Procedure, procedure ou function
Bem, antes de responder só um Aviso - NEM DE LONGE coisas genéricas assim são recomendadas no RDBMS Oracle, pois podem levar aos mais diversos problemas tais como : - controladoria : como os programadores e/ou usuários finais podem à volonté mandar o texto de SQL que quiserem (SEM validação prévia, SEM estudo de performance, SEM controle de versão), e na hora que quiserem (SEM respeitar nenhum tipo de scheduling), só imagino a bagunça pra controlar esse tipo de ambiente - performance : SQL dinâmico ** necessariamente ** implica sempre em PARSE extra, mais gasto de CPU e recursos de modo geral, Além de não aproveitar plenamente os caches internos do RDBMS - segurança : google por DYNAMIC SQL INJECTION e veja o tamanho da encrenca - complexidade : SQl dinâmico ** necessariamente ** implica que vc vai escrever mais, não importa a API usada - pode ser um pouco mais só no caso de optar por REF CURSOR, pode ser muito mais no caso de vc ter que apelar para DBMS_SQL ou EXECUTE IMMEDIATE, mas que vc vai escrever mais, vai ter mais código para manter, é de ´praxe com SQL dinâmico... isso posto : se REALMENTE vc quiser mesmo ir para esse caminho, veja refs e exemplos em http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:479021456587 , http://asktom.oracle.com/pls/asktom/f?p=100:11:P11_QUESTION_ID:1288401763279 e http://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:1669972300346534908 - se ancaixar na sua necessidade, vá de REF CURSOR dinâmico, aonde vc passa o SQL numa string e abre o REF CURSOR , caso não der aí vc usa as outras técnicas citadas nos links (ie, DBMS_SQL e EXECUTE IMMEDIATE ... O problema com essas outras técnicas é que elas não retornam um resultset per se, com elas vc teria que ter algum objeto temporário para conter os registros retornados []s Chiappa
Re: [oracle_br] Re: Store Procedure, procedure ou function
Na verdade eu entendi que ele quer um ** resultset ** , e que inclusive seria ** indefinido ** em tempo de desenvolvimento já que o SQL vai ser dinãmico : sendo isso, para retornar um RESULTSET, composto de um número indeterminado de linhas e colunas, e que não seja limitado pelas restrições de memória do PL/SQL, REF CURSOR é a resposta... vamos ver se a pessoa lá confirma ou não a suposição do que é que ela quer/precisa []s Chiappa
[oracle_br] Re: Oracle 11g e iSCSI
Pelo que entendi, em um único LUN vc vai enfiar os datafiles, os redo log files e os archives, só mudando o sub-diretório, mas fisicamente o dispositivo é o mesmo pra todo mundo, é isso ?? Sendo isso, para a administração rigorosamente Não vejo diferença de vc ter um subdiretório ../archives ou não Eu só me preocuparia é em termos de performance : lembre-se que o RDBMS Oracle faz I/O (leitura E gravação) constantemente E de modo simultâneo nos seus arquivos (nada impede que a mesmo tempo que o lgwr tá gravando um log o dbwr tá atualizando um datafile, digamos) então vc ** tem ** que se Assegurar que não vai haver contenção em essa única LUn atendendo todo mundo... Sobre uma eventual falha de iSCSI, é assim : tudo depende do teu ambiente *** não perder *** nenhum byte do que estava sendo gravado e *** não corromper *** nada quando os disk devices voltarem a ficar onlines, EM ESPECIAL os archives e os datafiles Basta que vc perca uns poucos bytes duma eventual gravação dum datafile, que vc perca um só vetor de alteração de um log, que vc pode acabar com corrupção na mão, sim ??? Então ALGUÉM/ALGO (alguma opção de journaling, sei lá) tem que te GARANTIR que tudo que estava nos buffers de gravação FOI efetivamente flusheado para disco, que vc não perca nenhum I/O, aí vc consegue recuperar o database depois do CRASH... []s Chiappa
Re: [oracle_br] falha ao criar índice
Na verdade, olhando por cima nem o nome da tabela nem o nome do índice nem o nome da coluna ultrapassam 30 caracteres, então eu ACHO que esse erro é espúrio e que vc ainda tá tendo problemas com 's desbalanceadas ... PLZ vai pro sqlplus e ** DIGITE ** na mão, diretamente, o comando de criação antes de tentar enfiar ele em bloco dinâmico : dando certo vc sabe que é problemas de 's/string mal-definida, e não dando certo aí a gente tem um caso reproduzível, e talvez executando diretamente vc receba uma msg de erro melhor... []s Chiappa
[oracle_br] Re: Ajuda com erro na trigger de logon: ORA-00604: ocorr eu um erro no nível 1 SQL recursivo
http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:49818662859946#49822831803623 é a sua reposta : a questão é que é *** INSEGURO *** ao extremo vc usar USERENV em rotinas não-interativas (ie, jobs e triggers) , usar ao invés a v$mystat []s Chiappa
Re: [oracle_br] Re: Ajuda com erro na trigger de log on: ORA-00604: ocorr eu um erro no nível 1 SQL recursivo
A questão é que o USERENV('sessionid') captura valores quando uma sessão é
estabelecida a pedido do cliente : quando a sessão é criada pelo database (por
exemplo, triggers, JOBs de database, threads derivadas da mesma sessão tal como
o sqlplus faz quando vc ativa o AUTOTRACE, etc) ele Não Vai funcionar a
contento (pode estar em btanco/vazio o AUDSID, já que não há entrada auditável,
e/ou pode ter Duplicidade (no caso de triggers e threads), e DAÍ deve estar
vindo o teu erro de a veja o link que te passei (e procura no asktom por
userenv('sessionid') que vc acha uns tantos quantos casos demonstrando isso...
Sobre IP : para pegar IP da máquina que conectou (imagino que é isso que vc
quer), afaik é seguro o sys_context('userenv','ip_address'), já que essa
informação vem do client e é coletada no instante mesmo da conexão (e vale até
para conexões locais) - E fique claro, o teu problema *** não é *** o
sys_context('userenv', MAS sim o audsid -, mas LOGICAMENTE falando ela é
absolutamente desnecessária : se vc ativar a Auditoria via AUDIT, vc
Automagicamente já terá na AUD$ a informação de IP ** junto ** com a de
terminal, hostname e outras tantas
[]s
Chiappa
Re: [oracle_br] RE: Sessão Travada
Fernando, é Conceitual : no RDBMS Oracle vc Absolutamente ** nunca** , de jeito nenhum, vai ter LOCKs gerados pelo próprio database por causa de alguma configuração, okdoc ?? Talvez vc esteja pensando em outros RDBMSs aonde existe a figura do LOCK ESCALATION (ie, em algumas condições um lock de registro é transfigurado num LOCK a nível de tabela) e/ou onde existem coisas como uma tabela interna de locks , mas no RDBMS Oracle esqueça, nada disso existe Assim, vc não ter RIGOROSAMENTE NADA a fazer em termos de configuração do database : com 100% de certeza o que vc está vendo é efeito causado pela Aplicação (ou pelos seus componentes, como Middleware, Triggers de database, scripts e jobs, etc), sem escapatória possível... Aí então são as fontes / recursos da Aplicação (ie, o Suporte da Aplicação , os Grupos de Usuários da Aplicação, os teuas Analistas que cuidam da Aplicação, etc) que vão poder te orientar melhor Aqui, a nível de RDBMS Oracle, neca... []s Chiappa
Re: [oracle_br] Aplicar PSU ou não?
Pois é : teste, teste teste no ambiente de testes. Numa determinada multinacional monocromática azulada em que trabalhei, ao menos isso funcionava direitinho : a maior parte (se não quase todos ,mesmo) dos clientes era meio que forçado a cumprir, contratualmente, a Exigência de se aplicar os PSUs (ou NO MÍNIMO os CPUs) no máximo 45 dias depois do lançamento deles, se nã a Empresa metia uma cartinha de risco e basicamente usava isso para justificar qquer não-conformidade da operação, e hoje em dia sou Obrigado a concordar com isso, correção de bugs é condição Imperativa para estabilidade E o melhor de tudo, isso mais ou menos forçava os cabras a terem um ambiente de teste : se vc deixar por conta do cliente, o que tem de neguinho que quer testar em produção não tá no gibi []s Chiappa
Re: [oracle_br] Aplicar PSU ou não?
Bem, o fato é que não dá pra ficar sem as muitas correções Cruciais que um PSU (ou mesmo o CPU !!) te dá - no meio delas normalmente tem bugs de segurança terríveis, tem bugs de performance vitais , não dá pra ficar sem em nome de uma pseudo-segurança de eventualmente, quem sabe, o PSU ou CPU xyz introduzir novos bugs... E, imho, dizer que se vai aplicar os one-off patches individualmente é um auto-engano : via de regra há dúzias de patches encapsulados num patch update, eu du-vi-de-o-dó que um DBA vai ter tempo/paci~encia/oportunidade de Realmente os aplicar todos... Aí fica naquela de correr atrás do rabo, só aplicar o one-off quando a issue realmente acontece, colocar a tranca só depois que a porta foi arrombada Sorry, eu não compactuo com isso, não... Pra vc Minimizar a chance de se ver ás voltas com bugs introduzidos por PSU, o que se faz é mesmo : 1. testar BEM no ambiente de teste, e depois em Homologação e 2. enquanto 1. rola, acompanhar no metalink e nos Fóruns os relatos de issues com o patchset Com isso vc diminui Drasticamente a possibilidade, deixando-a (imho) desprezível E só relembrando, CASO o pior aconteça, na remota hipótese de mesmo usando os procedimentos acima vc realmente caia num novo bug introduzido pelo PSU, vc PODE SIm na maioria das vezes DESAPLICAr o PSU, fazendo o proceidmento de rollback dele via opatch , ok ?? Então De Forma Alguma vc vai ficar parado esperando a boa vontade da Oracle em corrigir, yep ?? []s Chiappa OBS : eu citei várias vezes o CPU (Critical Patch Update) em oposição ao PSU (Patch Set Update) porque o CPU é, normalmente, um pacote Muito menor do que o PSU - o CPU foca nos bugs especialmente críticos, no melhor dos piores, okdoc ? Então via de regra é muitíssimo menor a chance de um CPU introduzir novos bugs, assim uma OUTRA opção para aqueles databases ultra-críticos aonde vc não quer correr riscos pode ser vc aplicar os CPUs ao invés dos PSUs , yep ?? Óbvio, isso Não elimina a necessidade de se fazer os dois procedimentos acima, nem de talvez vc ter que eventualmente fazer rollback de algum CPU, mas talvez ajude no gerenciamento de riscos...
Re: [oracle_br] RE: Oracle RAC 11g problema memória
Pelo que eu saiba, não : ou se aplica patch/patchset ou desliga a feature []s Chiappa
Re: [oracle_br] Re: Retirar quebra de linha no final do texto
Bom, vc FOI na página que indiquei e viu que o caracter de LF (que é o que o
Linux/Unix usa para indicar quebra de linha) equivale a 10, certo ?? Então **
VEJA ** no dump que tem SIM chr(10) ás pampas aí, okdoc ? Com certeza foi erro
teu quando vc disse no início da thread que não achou
Muito bem : no caso, veja que vc nçao tem sequências longas de espaço
(espaço=chr(32)) para fazer pular linhas, então como eu disse com certeza o que
vc tem é combinação de quebra de página, ie, uma quebra logo depois de outra,
confirme isso vendo no DUMP se realmente os pulos de linha equivalem aos locais
onde aparecem dosi caracteres de código 10 juntos Sendo isso, é
Exatamente o que eu disse, replace apenas, exemplo :
SYSTEM@xyz#1:SQLcreate table T(c1 varchar2(200));
Table created.
SYSTEM@xyz#1:SQLinsert into T values ('Linha1' || chr(10) || 'Linha2' ||
chr(10) || chr(10) || 'Linha 3' || chr(10));
1 row created.
SYSTEM@xyz#1:SQLcommit;
Commit complete.
= veja aí embaixo a linha sendo pulada pela junção de dois caracters ascii
código 10 :
SYSTEM@xyz#1:SQLselect * from T;
C1
-
Linha1
Linha2
Linha 3
SYSTEM@xyz#1:SQLselect dump(c1) from T;
DUMP(C1)
-
Typ=1 Len=23:
76,105,110,104,97,49,10,76,105,110,104,97,50,10,10,76,105,110,104,97,32,51,10
== Viu no DUMP ??? pelo que vejo é EXATAMENTE esse teu caso, um simples
REPLACE resolve :
SYSTEM@xyz#1:SQLupdate T set c1 = replace(c1, chr(10)||chr(10), chr(10));
1 row updated.
SYSTEM@xyz#1:SQLcommit;
Commit complete.
SYSTEM@xyz#1:SQLselect * from t;
C1
-
Linha1
Linha2
Linha 3
SYSTEM@xyz#1:SQL
okdoc
[]s
Chiappa
Re: [oracle_br] Re: Retirar quebra de linha no final do texto
Uma obs : agora que eu vi que vc queria fazer a operação de troca apenas no
fim de arquivo : isso implica que vc quer substituir não TODOS os 10,10 mas
apenas a partir do último... Ora, para identificar a ÚLTIMA ocorrência de uma
string, o RDBMS Oracle tem (sempre teve) o INSTR(string, argumento, -1), okdoc
?? Então é aplicar o que eu disse APENAS da posição indicada pelo INSTR em
diante... Exemplo :
SYSTEM@xyz#1:SQLtruncate table t;
Table truncated.
SYSTEM@xyz#1:SQLinsert into T values ('Linha1' || chr(10) || 'Linha2' ||
chr(10) || chr(10) || 'Linha 3' || chr(10)
2 || chr(10) );
1 row created.
SYSTEM@xyz#1:SQLcommit;
Commit complete.
SYSTEM@xyz#1:SQLselect * from t;
C1
-
Linha1
Linha2
Linha 3
SYSTEM@xyz#1:SQLselect dump(c1) from t;
DUMP(C1)
-
Typ=1 Len=24:
76,105,110,104,97,49,10,76,105,110,104,97,50,10,10,76,105,110,104,97,32,51,10,10
= legal ? Quero localizar a última sequência de linhas em branco, que
relemebremos são indicadas (no seu caso) por LF+LF :
SYSTEM@xyz#1:SQLselect substr(c1, instr(c1, chr(10)||chr(10), -1) ) from t;
SUBSTR(C1,INSTR(C1,CHR(10)||CHR(10),-1))
-
= vamos olhar o dump, que talvez fique mais visual :
SYSTEM@xyz#1:SQLselect dump( substr(c1, instr(c1, chr(10)||chr(10), -1) ))
from t;
DUMP(SUBSTR(C1,INSTR(C1,CHR(10)||CHR(10),-1)))
-
Typ=1 Len=2: 10,10
== Deu pra ver ?? Aí posso pedir pra exibir do início (posição 1) até o último
par 10,10/linha em branco :
SYSTEM@xyz#1:SQLselect substr(c1, 1, instr(c1, chr(10)||chr(10), -1) -1) from
t;
SUBSTR(C1,1,INSTR(C1,CHR(10)||CHR(10),-1)-1)
-
Linha1
Linha2
Linha 3
= vendo pelo dump :
SYSTEM@xyz#1:SQLselect dump(substr(c1, 1, instr(c1, chr(10)||chr(10), -1) -1))
from t;
DUMP(SUBSTR(C1,1,INSTR(C1,CHR(10)||CHR(10),-1)-1))
-
Typ=1 Len=22:
76,105,110,104,97,49,10,76,105,110,104,97,50,10,10,76,105,110,104,97,32,51
== TAÍ, na prática isso ** elimina ** a última linha em branco, vamos fazer o
UPDATE com isso :
SYSTEM@xyz#1:SQLupdate t set c1=substr(c1, 1, instr(c1, chr(10)||chr(10), -1)
-1);
1 row updated.
SYSTEM@xyz#1:SQLcommit;
Commit complete.
= resultado , removi a última linha em branco :
SYSTEM@xyz#1:SQLselect * from t;
C1
-
Linha1
Linha2
Linha 3
= pelo dump dá pra ver melhor :
SYSTEM@xyz#1:SQLselect dump(c1) from t;
DUMP(C1)
-
Typ=1 Len=22:
76,105,110,104,97,49,10,76,105,110,104,97,50,10,10,76,105,110,104,97,32,51
SYSTEM@xyz#1:SQL
yes ??? COMO eu disse na resposta anterior, SE vc tem múltiplas linhas em
branco a remover, OU vc executa o UPDATE várias vezes (a cada execuçaõ
eliminando uma linha em branco), OU vc aninha vários REPLACEs cfrme o link que
te dei, OU lança mão de REGEXP ou recursos mais sofisticados do tipo...
[]s
Chiappa
Re: [oracle_br] Re: Retirar quebra de linha no final do texto
Óbvio, essa lógica simples funciona para tirar UMA linha em branco : lá no finzinho do dump, por exemplo, vc tem: ...73,78,73,67,73,79,32,67,73,80,82,79,70,76,79,88,65,67,73,78,32,32,32,32,32,32,10,10,10,10,10,10,10,10 que se traduz por : INICIO CIPROFLOXACIN = ou seja, vc tem 8 linhas em branco O replace cortaria as linhas em branco à metade, substiuindo os 10,10 por 10 : CASO vc queira eliminar esses casos também, OU vc roda o UPDATE múltiplas vezes (viável se for volume pequeno), OU vc usa alguma lógica mais sofisticada : http://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:13912710295209 tem um exemplo com múltiplos REPLACEs aninhados (no caso removendo espaços em branco, mas seria a mesma lógica para remover CHRs(10), e/ou dá um bico na Documentação sobre REGEXP que na sua versão 11.2.0.3 é totalmente possível e viável, e/ou (em ÚLTIMO CASO) faz um LOOP num PL/SQl, mesmo []s Chiappa
Re: [oracle_br] Re: Retirar quebra de linha no final do texto
Duhhh... Como sempre, depois que eu faço/digo alguma coisa, penso mais
friamente e me vêm à mente a solução ótima :( ... Por isso, penso, é que fui
mal nalguns testes, penso devagar mesmo
Veja só : o final de algo em Inglês é TRAILING, e no 11g que é o seu (iirc
na verdade introduzido no 10gr2) nós Já TEMOS a opção de TRAILING na função
TRIM Então é SIMPLESMENTE usar o que temos :
SYSTEM@xyz#1:SQLtruncate table t;
Table truncated.
== vamos enfiar uma qtdade N de linhas em branco (combinações chr(10) chr(10)
na string :
SYSTEM@xyz#1:SQLinsert into T values ('Linha1' || chr(10) || 'Linha2' ||
chr(10) || chr(10) || 'Linha 3' ||
2 chr(10) || chr(10) || chr(10) || chr(10) || chr(10) || chr(10) ||
chr(10) || chr(10) || chr(10) );
1 row created.
SYSTEM@xyz#1:SQLcommit;
Commit complete.
SYSTEM@xyz#1:SQLselect * from t;
C1
-
Linha1
Linha2
Linha 3
= maravilha, vamos ver via dump :
SYSTEM@xyz#1:SQLselect dump(c1) from t;
DUMP(C1)
-
Typ=1 Len=31:
76,105,110,104,97,49,10,76,105,110,104,97,50,10,10,76,105,110,104,97,32,51,10,10,10,10,10,10,10,10,10
= legal, vamos remover os TRAILING CHARACTERS :
SYSTEM@xyz#1:SQLupdate T set c1 = trim(TRAILING chr(10) from c1)
2 ;
1 row updated.
SYSTEM@xyz#1:SQLcommit;
Commit complete.
== taí :
SYSTEM@xyz#1:SQLselect * from t;
C1
-
Linha1
Linha2
Linha 3
SYSTEM@xyz#1:SQLselect dump(c1) from t;
DUMP(C1)
-
Typ=1 Len=22:
76,105,110,104,97,49,10,76,105,110,104,97,50,10,10,76,105,110,104,97,32,51
SYSTEM@xyz#1:SQL
né ?? Du pra mim...
[]s
Chiappa
[oracle_br] Re: paralelismo - range de data
Bem, ** sempre ** que se fala de planos de execução diferentes para o mesma SQL mas com valores diferentes (é o caso, ao que entendi), a PRIMEIRA coisa que se pensa é que o CBO recebeu estatísticas diferentes para os diferentes valores em questão... Para vc confirmar se as estatísticas são de boa qualidade, obtenha o plano de execução Extendido do SQL em questão para que vc tenha as colunas de E-ROWS e A-ROWS (ie, qtdade de linhas estimadas e efetivas) e veja se está com diferença significativa ou não... CASO esteja, pode ser o caso de melhorar a qualidade das estatísticas aumentando SIZE de histogramas na coluna em questão, indicando cardinalidade diferente com o hint de cardinalidade, ou coisas assim... Mas antes de qualquer coisa : tenha CERTEZA que o CBO não está mesmo fazendo a coisa certa gerando um plano diferente - no plano diferente, sem paralelismo, a performance é pior ou melhor E finalmente : vc tem CERTEZA que os recursos necessários para se fazer Parallel sql estavam disponíveis quando foi gerado o plano diferente ?? É Claro que se outros SQLs estavam ocupando os parallel slaves não sobraram recursos pra vc []s Chiappa
Re: [oracle_br] RE: Upgrade Oracle 11.2.0.2 para 11.2.0.3
Ah, diquinha : hoje no blog de Oracle upgrade o autor colocou um pequeno lembrete, relembrando que falta menos de um ano para o fim do Premier Support do 11gr2, E que o tradicional 1 ano de extended support na faixa só vai valer Apenas e Tão Somente para o 11.2.0.4 !!! Então considere Seriamente a possibilidade de já pular para o 11.2.0.4 ao invés do 11.2.0.3, sim ??? Aí vc Evita a correria de retestar/remigrar para 11.2.0.4 no fim de ano para aproveitar o 1 ano de extended support free... []s Chiappa
[oracle_br] Re: CRS e CSS não sobem
Ah, detalhe importante : outra tool que pode ajudar Muitão é a RACcheck, que pode ser usada a partir do 10.2.0.4 e portanto serve pra vc... Só não sei se com a recente mudança de nome e introdução de novas features ele continua compatível com 10.2.0.4, consulte os detalhes na nota metalink ORAchk - Oracle Configuration Audit Tool (Doc ID 1268927.2), e se for o caso baixe as versões anteriores []s Chiappa
[oracle_br] Re: CRS e CSS não sobem
Bom, primeiro de tudo *** muito dificilmente *** o crs pára de funcionar do nada : com quase Absoluta certeza, alguma mudança teve aí... O difícil é que muitas vezes a mudança é de rede e/ou do próprio servidor, aí o pessoal de rede jura de pé junto que não, que não, mas depois de uma longa e difícil investigação aí vc descobre coisas como conflito de IPs (o um dos IPs quew deveria estar reservado para o cluster RAC não foi reservado no DNS e algum outro device na rede o quis usar, digamos), vc descobre que o monstrengo do sysadmin mudou senha e/ou detalhes do usuário oracle quebrando a conectividade ssh entre as máquinas, que neguim fez update no SO, que algum software idiótico de segurança remover os privilégios de CAP_NUMA_ATTACH,CAP_BYPASS_RAC_VMM,CAP_PROPAGATE do usuário que roda o CRS, coisas assim... A primeira coisa então é investigar ** EXATAMENTE ** o que mudou Uma ferramenta que pode ser utilíssima é o CVU, ele tem DIVERSOS checks (de hardware, de conectividade, de packages, etc) que vc pode pedir, baixe no metalink a versão mais recente dele...Infelizmente , coisas INTERNAs como DNS malconfigurado, conflito de IPs e quetais nem sempre com ele vc pega... na mesma toada, recomenda-se Muito que vc instale e rode o diagcollection.pl, o RDA e um oswatcher : todos esses te dão bons insgights e servem como material para um possível futuro chamado no Suporte Oracle... Essas coisas não são invenção da minha cabeça, estão nas notas : Data Collecting for Troubleshooting Oracle Clusterware (CRS or GI) And Real Application Cluster (RAC) Issues (Doc ID 289690.1) e Oracle Clusterware 10gR2/ 11gR1/ 11gR2/ 12cR1 Diagnostic Collection Guide (Doc ID 330358.1) ... Segunda coisa, checks de interesse em troubleshoot de CRS : veja a nota metalink CRS can not Start After Node Reboot (Doc ID 733260.1) , que ela lista diversos cenários comuns... Sobre logs, veja que além dos logs do crs (que INCLUSIVE a nota anterior mostra que nem todos estão abaixo do CRS_HOME), os logs ** do sistema ** (como /var/log/messages) ABSOLUTAMENTE tem que serem checados... Outro teste MUITO válido é : pedir o ./init.cssd stop , se ASSEGURAR que não há entradas perdidas em /var/.oracle, /tmp e quetais, e aí pedir o ./init.cssd start (sempre como o usuário que roda o CRS, of course:) : com isso vc recebe Diretamente as msgs de erro, às vezes isso ajuda... E sempre recheque o cssdout.log após suas tentativas... E finalmente : o VIP não subir num outro nó após uma falha com reboot é Extremamente comum : para verificar essa possibilidade, siga a nota How to Troubleshoot CRS Not Starting a VIP Resource (Doc ID 372643.1) ... []s Chiappa
[oracle_br] RE: Oracle RAC 11g problema memória
Dá um look na nota metalink Cluster Health Monitor (CHM/OS) osysmond.bin High Resource (CPU, Memory and FD etc) Usage (Doc ID 1554116.1) que vc acha Diversos bugs desse cara consumindo em excesso, e CONFIRME com um Chamado no Suporte Oracle em qual/quais vc pode estar caindo E Como vc vai notar, Diversos deles foram corrigidos em PSUs recentes (os quais ao que parece vc Não Aplicou nenhum, pois tua versão está 11.2.0.3.0, com algum PSU ela iria para 11.2.0.3.x) e/ou no patchset 11.2.0.4 : muito provavelmente o Suporte vai INSISTIR para que vc, se não puder aplicat p atchset 11.2.0.4, que ao menos vc aplique o PSU mais recente... E é claro, o Cluster Health Monitor é um processo ** auxiliar e Opcional ** , absolutamente nada impede vc de o parar (via crsctl stop resource ora.crf -init , normalmente) para estabilizar o ambiente enquanto vc investiga mais... []s Chiappa
[oracle_br] RE: Problema com Proc enviando e-mail
Depende : ** SE ** vc tem total certeza que os dados / registros sendo lidos absolutamente nunca ultrapassam o limite máximo de uma variável string no PL/SQL (ie, 32767 bytes), vc simplesmente redimensiona a variável V_EMAIL_CORPO para varchar2(32767), continua concatenando cada registro lido nela que nem vc faz hoje e apenas MOVE a chamada da WENVIA_EMAIL_3 para fora do loop Já se pode acontecer do tamanho total do corpo do email (contando cabeçalhos e todos os registros de dados lidos/concatenados) crescer mais que isso, aí a solução é vc gravar um arquivo-texto (com UTL_FILE) com os dados e alterar a rotina de envio de email para que envie o arquivo como um attachment : se for esse o caso, nos diga a versão exata do banco e nos diga se a tal WENVIA_EMAIL_3 usa UTL_MAIL ou UTL_SMTP pra enviar o email, que a gente pode indicar links e refs []s Chiappa
[oracle_br] RE: Por que SYS não usa sua TEMPORARY_TABLESPACE no expdp ?
Bom, eu desconheço Documentação a respeito, mas a partir do momento em que o sujeitim se mete a NÃO usar a recomendação da Oracle, a pessoa tá por conta própria , Óbvio que pode (alguns dizem VAI) cair nalgum buraco não-documentado : o DOCUMENTADO só mesmo o recomendado, yep ?? E no caso a recomendação para ** nunca ** de forma Alguma, de jeito nenhum usar o SYS para tarefas de administração rotineira é clara, sim : no instante que o poessoal aí se mete a usar o SYS para outra coisa que não seja startup/shutdown/patching/manutenção interna do database, coisas inesparedas poidem e vão ocorrer : o SYS é interno, é especial, e não tem por onde... A única ref que eu conheço na documentação é sobre a propriedade de DEFAULT TABLESPACE , que é documentada se ser ** ignorada ** pelo SYS , no manual Oracle® Database Security Guide 11g Release 2 (11.2), cap. 2 - Managing Security for Oracle Database Users (ênfase com *s minha) : Assigning a Default Tablespace for the User Each user should have a default tablespace. When a schema object is created in the user's schema and the DDL statement does not specify a tablespace to contain the object, Oracle Database stores the object in the default user's tablespace. The default setting for the default tablespaces of all users is the SYSTEM tablespace. If a user does not create objects, and has no privileges to do so, then this default setting is fine. However, if a user is likely to create any type of object, then you should specifically assign the user a default tablespace, such as the USERS tablespace. Using a tablespace other than SYSTEM reduces contention between data dictionary objects and user objects for the same data files. In general, do not store user data in the SYSTEM tablespace. You can use the CREATE TABLESPACE SQL statement to create a permanent default tablespace other than SYSTEM at the time of database creation, to be used as the database default for permanent objects. By separating the user data from the system data, you reduce the likelihood of problems with the SYSTEM tablespace, which can in some circumstances cause the entire database to become nonfunctional. === ** This default permanent tablespace is not used by system users, that is, SYS, SYSTEM, and OUTLN ** , whose default permanent tablespace is SYSTEM. []s Chiappa
Re: [oracle_br] Software repositório de scripts
okdoc... Inclusive, em verdade essa opção de se ter os scripts centralizados no servidor de gateway (e ou acessados pelos servidores Oracle num mountpoint NFS no gateway ou coisa do tipo, ou mesmo executados a partir do gateway conectando nos servidores Oracle - seja via client por sqlplus, seja acesso SEM client através de jdbc thin, como por exemplo via Oracle SQL Developer) eu não vejo nem como quebra-galho, mas como uma Solução definitiva e perfeitamente possível/viável ... Por exemplo, num cliente anterior nós não só tinhamos os scripts no gateway mas Também cada DBA tinha uma pasta própria no servidor de gateway (limitada em tamanho numa quota razoável, óbvio) para podermos guardar/transportar arquivos entre/de/para os servidores Oracle e nossas máquinas pessoais - digamos, um trace file ou um alert log que vc precisa trazer pra sua máquina pessoal e enviar por email para a Oracle, um arquivo-texto grande e/ou um dumpfile que vc precise transportar entre as máquinas, coisas assim... []s Chiappa
[oracle_br] RE: Executar um comando do Linux via PL/SQL
Bom, provavelmente vão te passar rotinas java e outras complicações quetais, mas sendo 10g ou acima pra mim Não Tem Por Onde, a maneira fácil e simples de se executar comandos do SO e/ou programas externos via PL/SQL é com o DBMS_SCHEDULER , veja em http://halisway.blogspot.com.br/2007/05/run-system-commands-from-oracle-with.html um exemplo um tanto mais sofisticado mas válido... Não exige NENHUM componente a mais a ser instalado (ao contrário do java, que Exige vc ter instalado a opção de JVM no database), Não exige privilégios extraordinários.. O Único senão é que (OBVIAMENTE) vc vai estar executando o comando como o usuário linux que instalou e roda o RDBMS - se precisar executar alguma coisa como root ou como outro usuário, aí vc vai precisar de alguma coisa extra no SO, como permissão no sudo, abrir um novo shell conectando com a senha do tal usuário, ou coisas assim... []s Chiappa
Re: [oracle_br] Software repositório de scripts
O que vc descreve são softwares tipo o SourceSafe, que além de armazenar o código-fonte ainda possuem features de versionamento e controle de alterações, que pelo jeito ao que entendi vc não vai usar... Como alternativas (afaik TODOs tem a capacidade de copiar/colar o fonte) de freeware vc pode tentar o SVN, ou o Mercurial, Git, AnkhSVN, ou se tiver uma verbinha de pago mas não tão caro pode ser o visualsvn : googla por eles que vc já deve cair no site deles todos Eu particularmente não uso nenhum deles (prefiro sempre que possível simplesmente ter um mountpoint NFS ou Samba ou coisa que o valha acessível diretamente pelos servidores, pois aí nem o trabalho de copiar/colar eu tenho, já executo Diretamente pelo servidor Oracle o script que quero... []s Chiappa
Re: [oracle_br] Software repositório de scripts
E é claro, há outras possibilidades : uma delas é se vc tiver uma máquina desktop, sua, de onde vc possa conectar em todos os databases a partir dela, vc simplesmente mantem num diretório dessa máquina teus scripts e cadastra os databases todos no TNSNAMES do client Oracle que vc vai ter lá... Uma variação desta possibilidade é instalar um software tipo o muSQL ou o TOAD script manager ou mesmo o Oracle OEM nessa máquina central e cadastrar os seus databases-alvos todos nesse software - isso te dá a vantagem de poder executar um único script de uma vez só contra múltiplos databases (digamos, um script de checklist ou de healthcheck rápido) Mas isso só e apenas se TODOS os databases estão na mesma subnet (ou pelo menos são acessíveis de um ponto central na rede), é claro... []s Chiappa
