13 de mar. de 2013


Muito bom dia a todos!

Hoje vou falar sobre um comando SQL que não vejo muita gente usar mas que é bem poderoso. Esse comando é o MERGE.

Vejo muito código em PL/SQL da seguinte forma:
DECLARE
   var_existe   NUMBER (4) := 0;
BEGIN
   SELECT COUNT (cod)
     INTO var_existe
     FROM tabela
    WHERE cod = :par_cod;

   IF var_existe > 0 THEN
      --Significa que existe valor para o parametro buscado (par_cod)
      UPDATE tabela SET campo = :par_campo WHERE cod = :par_cod;
   ELSE
      --Significa que NÃO existe valor para o parametro buscado
      INSERT INTO tabela  VALUES (:par_cod, :par_campo);     
   END IF;
  
END;

Abstraindo o nome da tabela e seus campos, e levando em consideração à estrutura do bloco de código, basicamente o que é feito é um teste se um determinado valor (:par_cod) existe na tabela, caso exista, será realizada uma alteração (UPDATE) caso contrário será inserido um registro com aquele código (INSERT).

Agora vou falar um pouco sobre o MERGE e depois associar o comando com o bloco PL/SQL acima. 

Segundo Watson, O merge foi introduzido no SQL com o padrão SQL1999, e implementado no Oracle a partir da versão 9i. No Oracle Database 10g o comando foi aprimorado para entrar em conformidade com o padrão SQL2003.

O propósito principal do comando merge é justamente o mesmo do bloco lógico apresentado anteriormente. Uma operação merge não faz nada que não possa ser feito com as instruções INSERT, UPDATE e DELETE – mas com uma passagem pelos dados de origem, ela pode fazer as três coisas. Código alternativo sem MERGE iria exigir três passagem pelos dados, uma para cada comando.

Os dados de Origem para uma instrução MERGE pode ser uma tabela ou uma sub-consulta qualquer. A condição usada para encontrar linhas correspondentes no destino é similar a uma cláusula WHERE. As cláusulas que atualizam, inserem ou excluem linhas são semelhantes aos comandos update, insert e delete. Alguns autores e profissionais  de banco de dados afirmam que o MERGE é o mais complicado dos comandos DML, porém um dos mais poderosos.

A sintaxe do MERGE, em sua forma básica é a informada na Figura 1.
Figura 1 - Estrutura do comando MERGE. (Fonte: Orale Corporation)

Na Figura 1, as operações DML não estão especificadas, então seguem algumas imagens complementares.

Na Figura 2, é apresentada a sintaxe para realizar um UPDATE na linha para o caso de correspondência (MATCHED) na comparação realizada no comando.

Essa mesma estrutura apresentada na Figura 2 pode ser utilizada para a exclusão de linhas na tabela em questão.
Figura 2 - UPDATE/DELETE no MERGE caso a comparação realizada corresponda. (Fonte: Orale Corporation)

Para o caso de não existir uma correspondência na comparação realizada no comando, um INSERT pode ser realizado conforme apresentado na Figura 3.
Figura 3 - INSERT no MERGE caso a comparação realizada não corresponda. (Fonte: Orale Corporation)

Em ambas as situações, Figura 2 e 3, existem um trecho chamado “where_clause, que nada mais é que uma cláusula WHERE normal, no formado: WHERE condição.

Na Figura 1, existe um trecho chamado “error_loggin_clause”, que possui sua sintaxe conforme Figura 4. Sua utilidade é para o caso de erros na execução do comando MERGE. O registro na tabela de log será efetivado caso ocorra algum problema. Para se criar uma tabela para o log do Oracle usa-se o pacote DBMS_ERRLOG.CREATE_ERROR_LOG. Como não é nosso foco principal não abordarei profundamente a questão, mas recomendo a leitura do assunto para um entendimento melhor (é interessante).
Figura 4 - Tratamento de erros no comando MERGE. (Fonte: Oracle Corporation)

Aplicando a sintaxe acima ao nosso bloco lógico citado no início do post temos o seguinte:
MERGE INTO tabela t
     USING (SELECT :par_cod AS cod FROM DUAL) t_aux
        ON (t.cod = t_aux.cod)
WHEN MATCHED THEN
   UPDATE SET campo = :par_campo
WHEN NOT MATCHED THEN
   INSERT     VALUES (:par_cod, :par_campo);

Fiz uma simulação de consulta utilizando a tabela DUAL, apenas para depois testar se o valor “passado por parâmetro” (par_cod) existe na tabela.

A sintaxe está bem simplificada, mas é bastante potente e mais performático em relação ao bloco apresentado anteriormente.

Fica a dica: avaliem se em algum script seu existe uma situação que possa ser utilizado o MERGE e faça um teste. Vale o aprendizado!

Espero conseguido passar o conhecimento!

Grande abraço e até a próxima...

Referências:

Watson, John; Ramklass, Roopesh (2010) – OCA Oracle Database 11g – Fundamentos I SQL – Manual do Exame 1z0-051. Editora: ALTABOOKS.

Oracle Corporation – MERGE. Disponível em http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9016.htm. Acessado em 13/03/2013.

Raphael Fernandes, quarta-feira, março 13, 2013

Sem comentários

12 de mar. de 2013


Pessoal,

No final do ano de 2012, prestei concurso para o DataPrev o qual me classifiquei em 18º do Nordeste. As provas foram de responsabilidade do Instituto QUADRIX e é sobre uma das questões que caíram na prova que quero comentar. A questão subjetiva da prova para o cargo de ANALISTA DE TECNOLGIA DA INFORMAÇÃO – Perfil: BANCO DE DADOS; era a seguinte:

Uma característica do RDBMS ORACLE é a separação entre a estrutura física e a lógica de armazenamento.

Explique o porquê ou qual a principal vantagem dessa separação entre as estruturas física e lógica.

Descreva a composição de cada uma das estruturas, física e lógica, e os respectivos componentes dentro de cada estrutura.”.


Para falar sobre o assunto, mais uma vez vou recorrer ao meu “amigo” John Watson.

O banco de dados consistem em três tipos de arquivos: arquivo de controle, arquivos de redo log e os arquivos de dados.
O BD Oracle fornece uma abstração completa do armazenamento lógico para o físico, ajudando muito na redução da carga de tarefas freqüentes de um DBA. Essa divisão do Oracle ajuda no gerenciamento e organização das informações.

Para iniciar o assunto, vamos entender basicamente alguns conceitos: tablespace e datafiles (arquivos de dados). Os dados são armazenados logicamente em segmentos e fisicamente em arquivos de dados. A entidade tablespace abstrai os dois – um tablespace pode conter vários segmentos e ser composto por muitos datafiles. Não existe uma relação direta entre um segmento e um datafile.
Segue um exemplo para criação de tablespace com dois datafiles associados (em sua forma básica):

CREATE TABLESPACE TBS_1MD DATAFILE
  '/opt/oracle/oradata/workspace/tbs1md_01.dbf' SIZE 2048M AUTOEXTEND OFF,
  '/opt/oracle/oradata/workspace/tbs1md_02.dbf' SIZE 2048M AUTOEXTEND OFF
LOGGING
ONLINE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M
BLOCKSIZE 8K
SEGMENT SPACE MANAGEMENT AUTO
FLASHBACK ON;

Então vamos lá!

O banco de dados Oracle é dividido logicamente por tablespaces. Numa divisão abaixo das tablespaces se encontram os segmentos, que são constituídos de extensões. Uma extensão consiste no conjunto de blocos de dados. Para o entendimento ficar mais claro, a Figura 1 exibe como se dá as a. Cada extensão somente existe em um arquivo de dados. Os blocos de dados representam a menor unidade de entrada/saída no banco de dados.
 Figura 1 - Estrutura lógica de armazenamento no banco de dados Oracle. (Fonte: LEGATTI)

Todo banco de dados Oracle tem um ou mais arquivos de dados (datafiles), onde são armazenados os dados da base de dados. Os dados das estruturas lógicas como tabelas e índices são fisicamente armazenados nos datafiles alocados para o banco de dados, conforme Figura 2.

Figura 2 - Armazenamento lógico e físico de objetos no Oracle. (Fonte: Oracle Corporation)

É importante saber, que um datafile pode ser associado a apenas um banco de dados e a uma única tablespace. Os dados de um datafile são lidos, quando preciso, durante as operações de DML no banco de dados e armazenados no cachê de memória do Oracle (na porção de blocos de dados).  Dados modificados ou alterados não são necessariamente armazenados no datafile de imediato. Para reduzir o acesso a disco e melhorar o desempenho, o dado é colocado na memória e gravado no datafile todos de uma vez como determinado pelo processos interno do Oracle chamado “database writer process”.

Continuando a falar sobre as estruturas físicas do banco Oracle, temos o Redo Log File. Todo banco de dados Oracle tem um ou mais redo log files. O conjunto de um ou mais redo log files são conhecidos coletivamente como redo log do banco de dados. A função principal desses arquivos é registrar todas as mudanças realizadas nos dados do banco. Se devido a uma falha há necessidade de se recuperar informações do banco de dados isto é possível de ser feito através dos redo log files.

Para concluir a explicação de arquivos físicos do Oracle, vou falar sobre os control files. Todo banco de dados do Oracle tem um control file que são responsáveis por guardar os registros que especificam as estruturas físicas dos arquivos, tais como: 
- Nome do banco de dados
- Nomes e localizações dos redo log files
- A data da criação do banco de dados

Assim como os redo log files os control files também podem ter cópias mantidas em mais de um disco para efeito de segurança.

É importante lembrar que a estrutura de armazenamento das informações pode ter impacto na performance do banco de dados, então deve-se planejar de forma coerente como e onde alocar os dados para evitar problemas dessa natureza.

Bom pessoal,

Essa foi a questão que caiu no concurso e minha resposta foi mais ou menos essa (obviamente sem imagens).

Por enquanto é isso!

Um abraço e até a próxima!!


Referências:

WATSON, JOHN – OCA Oracle Database 11g – Administração I – Guia do Exame 1z0-052. Editora: BOOKMAN.

LEGATTI, EDUARDO – Introdução ao conceito de Tablespaces. Postado em setembro/2011. Disponível em: http://www.oracle.com/technetwork/pt/articles/database-performance/introducao-conceito-de-tablespaces-495850-ptb.html. Acessado em: 10/03/2013.

Oracle Corportaion – Schema Objects. Disponível em: http://docs.oracle.com/cd/B19306_01/server.102/b14220/schema.htm. Acessado: 11/03/2013.

Raphael Fernandes, terça-feira, março 12, 2013

3 comentários

11 de mar. de 2013

Olá pessoal.

Estava lendo umas notícias, quando és que surge algo que me chamou a atenção. Uma reportagem que falava da Oracle e seu novo foco.

O título e a chamada para a notícia era: "A ORACLE NÃO É MAIS UMA EMPRESA DE BANCO DE DADOS - Depois de mais de 90 aquisições em uma década, empresa aumentou seu portfólio e hoje tem somente 40% de seu faturamento vindo de Bancos de Dados".

Em leitura, existe uma passagem do vice-presidente executivo da Oracle para a América Latina que diz: “a empresa tem produtos para todos os tipos de trabalho em todos os tipos de indústria”; algo que já mostra o direcionamento da empresa para novas áreas do mercado.

Em outro trecho da mesma reportagem, é afirmado que uma área que vem crescendo e ganhando bastante mercado é a de cloud computing, ou computação em nuvem, aonde a Oracle vem conseguindo um faturamento bastante elevado, chegando a passar os lucros com hardwares.

Na explicação sobre a evolução da Oracle, é abordado o fato da empresa ter realizado mais de noventa aquisições nos últimos dez anos.

Achei uma reportagem muito interessante, e recomendo a leitura!

Acessem e confiram:
http://epocanegocios.globo.com/Informacao/Resultados/noticia/2013/01/oracle-nao-e-mais-uma-empresa-de-banco-de-dados.html

Raphael Fernandes, segunda-feira, março 11, 2013

Sem comentários


Pessoal,

Vejo sempre uma confusão no que envolve users e schemas (usuários e esquemas), então resolvi escrever um pouco e tentar esclarecer os conceitos envolvidos sobre eles.

Segundo John Watson e Roopesh Ramklass (OCP’s), para o ambiente Oracle um usuário é uma pessoa que pode se conectar ao banco de dados. Ele terá um nome de usuário e uma senha. Um esquema é um “contêiner” para os objetos de um usuário. Quando um usuário é criado, seu esquema é criado também (só que vazio). Alguns esquemas estarão sempre vazios: o usuário nunca criará quaisquer objetos porque não precisará e pode ser configurado para que eles não tenham permissão para tal ação. Nesse caso, os usuários deverão ter permissão para acessar objetos de outros esquemas, de propriedades de outros usuários. Outros usuários serão o oposto disso: eles terão muitos objetos mas nunca farão logon realmente no banco de dados. Os objetos de esquema são objetos com um proprietário. O identificador exclusivo de um objeto de um tipo específico não é seu nome, é o seu nome prefixado por com o nome do esquema ao qual ele pertence.

Ex.: WORKSPACE.TBL_TEST – indica uma tabela chamada TBL_TEST que é de propriedade do usuário WORKSPACE.

Poderia existir outra tabela: HOUSEWORK.TBL_TEST, que poderia ser uma tabela de estrutura e/ou conteúdo diferente da anterior, de propriedade do usuário HOUSEWORK e residindo em seu esquema.

Uma quantidade de usuários (e seus esquemas) é criada automaticamente no momento de criação do banco. Destacam-se entre eles o SYS e o SYSTEM. O usuário SYS possui o dicionário de dados (que é um conjunto de tabelas que define o banco de dados e seu conteúdo), possui também uma série de pacotes de PL/SQL (utilizados para administrar e utilizar o banco). O esquema SYSTEM vários objetos adicionais que são utilizados para administração e monitoramento da base de dados. Esses dois esquemas não devem ser alterados através de comandos DML para que não ocorram problemas dados corrompidos por exemplo.

É uma boa prática, e na política da empresa que trabalho nós utilizamos, que sejam criados usuários que terão seus esquemas com tabelas e demais objetos para o armazenamento dos dados, e usuários (com esquemas vazios) para acessar os dados via aplicação.

Exemplo:
 - Usuário com esquema populado: WORKSPACE
 - Usuário de aplicação: USER_WORKSPACE

Esse usuário de aplicação terá direito de executar comandos DML nos objetos do esquema WORKSPACE, mas a segurança e administração de um ambiente com essa configuração é bastante interessante.


A sintaxe para criação de um usuário é a apresentada na Figura 1 e exemplificada mais adiante (de forma básica).
 Figura 1 - Sintaxe de criação de usuário. (Fonte: Oracle Corporation)

CREATE USER WORKSPACE
   IDENTIFIED BY SENHA
   DEFAULT TABLESPACE TBS_USUARIOS
   TEMPORARY TABLESPACE TEMP
   PROFILE DEFAULT
   ACCOUNT UNLOCK;


Espero ter ajudado com esse post.

Até a próxima!

Referências:

Watson, John; Ramklass, Roopesh (2010) – OCA Oracle Database 11g – Fundamentos I SQL – Manual do Exame 1z0-051. Editora: ALTABOOKS.

Oracle Corporation – CREATE USER. Disponível em http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_8003.htm. Acessado em 10/03/2013.

Raphael Fernandes, segunda-feira, março 11, 2013

Sem comentários

10 de mar. de 2013

Olá.

Hoje vou falar sobre algo que é bastante frequente na vida de um DBA: efetuar DUMP, ou seja, importar e exportar dados.
Segundo a Oracle, export e import é um caminho simples para se transferir objetos de dados entre banco de dados Oracle, mesmo quando as bases residem em plataformas com diferentes hardwares e softwares.
Antes de executar um Export e import, é necessário atentar para algumas questões:
            - é necessário ter executado o script catexp.sql o catalog.sql;
            - verificar se existe espaço suficiente em disco para a criação do arquivo de exportação, e na importação verificar se existe espaço suficiente em disco para receber os dados;
            - atentar se seu privilégio permite realizar tal execução.
Bom.
Para começar, vou falar do exp e imp.
O exp é o comando utilizado para se exportar objetos de uma base de dados. A estrutura do comando (em sua forma básica) é a seguinte:

- Exportando objetos do esquema (usuário) workspace:
exp workspace/Senha@ORCL  file=d:\EXPORT\workspace.dmp log=d:\EXPORT\exp_workspace.log feedback=1000
            file: é o arquivo de dump gerado
            log: é o arquivo de acompanhamento do que foi realizado pelo export
           feedback: é o retorno que será dado para o log em termos de registros. Ex.: a cada 1000 registros, será marcado um ponto (.) no arquivo de log

- Exportando algumas tabelas do esquema (usuário) workspace:
exp workspace/Senha@ORCL  file=d:\EXPORT\workspace_tables.dmp log=d:\EXPORT\exp_workspace_tables.log feedback=1000 tables=(tabela1, tabela2, tabela3)
            tables: contém o(s) nome(s) da(s) tabels(s)

O imp é o comando utilizado para se importar objetos de um arquivo de dump. A estrutura do comando (também em sua forma básica) é a seguinte:

- Importando objetos do esquema (usuário) workspace para um esquema workspace_new:
imp userid=system file=d:\EXPORT\workspace.dmp log= d:\EXPORT\imp_workspace.log fromuser=workspace touser=workspace_new feedback=1000

- Importando algumas tabelas do esquema (usuário) workspace para um esquema workspace_new:
imp userid=system file=d:\EXPORT\workspace.dmp log= d:\EXPORT\imp_workspace.log fromuser=workspace touser=workspace_new feedback=1000 tables=(tabela1, tabela2, tabela3)

Com o avanço da tecnologia Oracle Database e com suas novas versões, a forma de se importar e exportar evoluiu, e os comandos exp e imp foram substituídos pelos comandos expdp e impdp (os comandos substituídos ainda são suportados nas versões mais recentes, pelo menos até a versão 11G). Esses “novos” utilitários usam as procedures contidas no pacote DBMS_DATAPUMP para executar as tarefas a que se destinam.

Quanto à compatibilidade, os novos utilitários expdp e impdp, embora parecidos com os anteriores (exp e imp), são completamente distintos, e os arquivos gerados e utilizados pelas novas versões não são compatíveis.
Os dump files gerados pelas novas versões não podem ser lidos pelos antigos programas e vice-versa. Seguem diferenças entre os utilitários Data Pump e os antigos programas exp e imp.

  • os programas do Data Pump operam um grupo de arquivos chamado dump file set em vez de um arquivo sequencial;
  • os programas Data Pump acessam arquivos no servidor e não no cliente para melhorar a performance
  • os novos utilitários usam execução paralela para melhorar a performance;
  • o Data Pump usa documento XML para representar metadados no arquivo de dump e não comandos DDL (Data Definition Language) como nas antigas versões;
  • os programas do Data Pump possuem ajustes automáticos e não utilizam parâmetros de ajustes que eram utilizados nas versões anteriores;
  • mídias sequenciais como fitas não são suportadas;
  • se durante uma importação de dados para usando os comandos APPEND ou TRUNCATE ocorrer alguma violação de constraint por alguma linha, o carregamento será terminado e nenhum dado será carregado. Na versão antiga, era carregamento era feito um registro de log das linhas com violação e o carregamento continuava.

Data Pump Export

O expdp extrai a definição do objeto e seu conteúdo, transformando-os em um conjunto de arquivos do sistema operacional chamados dump file set. Esses arquivos podem ser usados pelo utilitário impdp, que pode convertê-lo e inserir seus dados em outro banco Oracle. O conjunto de arquivos de dump é composto por um ou mais arquivos que contém dados, metadados do banco de dados e informações de controle.
O expdp extrai todos os objetos do banco juntamente com os objetos relacionados ou dependentes, por exemplo uma tabela é extraída com índices comentários e permissões.
O Export possui alguns modos de exportação, a saber:

- Full export mode: exporta todos os objetos do banco:
expdp system DIRECTORY=DIR_DPUMP DUMPFILE=workspace.dmp FULL=y LOGFILE=expfull.log

- Schema mode: exporta as tables, views materialized views, clusters, dblinks, sequences, synonyms functions, triggers e stored procedures de um schema especificado:
expdp system DIRECTORY=DIR_DPUMP DUMPFILE=workspace_schema.dmp SCHEMAS=hr

- Table mode: permite a exportação de tabelas específicas do esquema. Permite também a exportação das linhas, permissões, definições, restrições e triggers das tabelas:
expdp system tables=hr.employees directory=DIR_DPUMP dumpfile=workspace_tabela.dmp logfile=FUNCIONARIO.log

- Tablespace mode: nesse modo, apenas as tabelas contidas em uma tablespace, ou grupo de tablespaces especificados, serão exportadas:
expdp system DIRECTORY=funcionarios DUMPFILE=funcionarios_TB.dmp TABLESPACES=USERS

Data Pump Import

O impdp é o complemento do expdp. Ele restaura os objetos de schema exportados previamente pelo programa EXP para um conjunto de arquivos de dump. O Import  permite ao usuário visualizar todos os comandos SQL DDL que serão executados sem a sua efetiva execução, permitindo assim uma análise de seu funcionamento.
A sintaxe do impdp é a seguinte:

- Importando o banco de dados inteiro:
impdp system DIRECTORY=DIR_DPUMP DUMPFILE=workspace.dmp FULL=y

- Importando um schema, remapeando com um novo usuario (schema), chamado amanda:
impdp system DIRECTORY=DIR_DPUMP DUMPFILE=workspace_schema.dmp remap_schema=hr:hr_new remap_tablespace=USERS:tbs_dados

- Importando uma tabela:
impdp system DIRECTORY=DIR_DPUMP DUMPFILE=funcionario_tabela.dmp TABLES=hr.funcionarios

 - Importando uma tablespace:
impdp system DIRECTORY=DIR_DPUMP DUMPFILE=funcionarios_TB.dmp TABLESPACES=tbs_dados


É importante lembrar que para o uso do expdp e impdp é necessário a criação de um DIRECTORY e permissões de uso, como exemplo:

CREATE OR REPLACE DIRECTORY DIR_DPUMP AS ‘/u01/dumps/’;

Bom pessoal!
Por hoje é só!
Espero ter conseguido explicar o assunto de forma fácil de entender.
Até a próxima!

Referências:
Ramalho, José Antônio (2005) – Oracle 10g – Ideal para quem deseja iniciar o aprendizado do Oracle. Editora: Thomson Learning.

Oracle Corporation – Export -/import. Disponível em: http://docs.oracle.com/cd/B19306_01/server.102/b14215/exp_imp.htm. Acessado em: 07/03/2013.

Oracle Base – Oracle Data Pump. Disponível em: http://www.oracle-base.com/articles/10g/oracle-data-pump-10g.php. Acessado em 07/03/2013.

Aprender Oracle - Backup: Utilizando Data Pump (EXPDP E IMPDP). Disponível em: http://aprenderoracle.com/2011/07/backup-utilizando-data-pump-expdp-e-impdp/. Acessado em 08/03/2013.

Raphael Fernandes, domingo, março 10, 2013

6 comentários

7 de mar. de 2013

Olá a todos!

Vou interromper um pouco a publicação de partes do meu projeto sobre Hard Parse para falar de um problema que vinha passando e finalmente consegui resolver (com ajuda de terceiros).

Quem nunca passou por problemas de acentuação utilizando o SQL*Plus via prompt do DOS?

Pois bem.

Sempre passei por esse problema e para "resolver" momentaneamente ou atender à solicitação, utilizava outra ferramenta (TOAD ou Oracle SQL Developer) para executar alguns scripts que possuíam acentos. Obviamente, isso não resolve o problema, e em uma pesquisa que fiz, consegue sanar essa situação.

Inicialmente, vou exemplificar o problema.

Primeiro criei uma tabela chamada TESTE, inseri um registro com valor “acentuação” e realizei uma consulta nessa tabela, conforme indicado na Figura 1.

Figura 1 - Exemplificando o problema de acentuação. (Fonte: autoria própria)

Como pode ser verificado na imagem acima, a acentuação bem como o “ç” do valor do campo apresentam problema na visualização: onde deveria constar a palavra “acentuação” consta o valor “acentua¿Æo”.
Pois bem. Entendido o problema, vamos à solução!

Existe um comando do DOS chamado CHCP (Change Code Page), que é responsável pela manutenção dos caracteres de modo geral dos códigos submetidos no DOS.
Para sabermos o valor atual na máquina, basta abrir um prompt e digitar chcp conforme indicado na Figura 2.
Figura 2 - Verificação do CHCP. (Fonte: autoria própria)

Na imagem acima, podemos constatar que o valor do Change Code Page é 850, que equivale à linguagem “Multilingual (Latin I)” segundo a Microsoft.

Para conseguirmos o suporte à acentuação para uso no SQL*Plus via DOS, vamos configurar o CHCP para a linguagem “Western Latin” cujo valor equivalente é 1252. Podemos fazer essa alteração apenas na sessão do prompt aberta no momento, ou configurar, por exemplo, em um atalho para todas as vezes que esse for acessado, não ocorra problemas de acentuação durante seu uso.

Em ambas as alterações, a fonte da letra que deve ser utilizada é a mesma: Lucida Console (para usar as mensagens traduzidas da versão do Windows em inglês sem problemas), conforme Figura 3.
Figura 3 - Configuração da fonte do prompt de comando. (Fonte: autoria própria)

Para configurar o suporte na sessão, basta executar o comando apresentado na Figura 4.

Figura 4 - Alteração do CHCP na sessão. (Fonte: autoria própria)

Agora vamos verificar se a alteração surtiu efeito através dos comandos exibido na Figura 5.

Figura 5 - Verificação de sucesso da alteração. (Fonte: autoria própria)

Opá...

Mas calma lá, Raphael. O erro não foi corrigido!

Na verdade foi sim, o que acontece é que o valor do campo foi inserido de forma errada, portanto o que foi gravado no banco está errado! Vamos efetuar um UPDATE e verificar o valor do campo conforme Figura 6.

Figura 6 - Update de registro para sucesso da alteração na configuração. (Fonte: autoria própria)

Pronto! Perfeito! A alteração na sessão funcionou conforme esperado.

Agora vamos configurar o atalho.

Essa configuração nada mais é do que a indicação que no momento da inicialização do programa, seja executado um script (já conhecido por nós), conforme indicado na Figura 7.

Figura 7 - Alteração na inicialização do atalho do prompt de comando. (Fonte: autoria própria)

Vou só confirmar que tudo correu certo conforme Figura 8.

Figura 8 - Verificação de sucesso na configuração do atalho. (Fonte: autoria própria)

É importante atentar que na primeira linha do atalho prompt onde foi realizada a configuração, sempre aparecerá o texto: “Página de código ativa: 1252”; confirmando que o CHCP está setado para o valor 1252.

OBS.: Vale lembrar que no SQL*Plus para Windows, o problema de acentuação não ocorre.
Bom pessoal, espero ter ajudado com esse post. Julgo o assunto bastante útil para quem usa SQL Plus.

Grande abraço e até a próxima!

Referências:

Legatti, Eduardo. Oracle Blog - Habilitando o suporte à acentuação no prompt do DOS para uso do SQL*Plus. Publicado em 02/01/2011. Disponível em: http://eduardolegatti.blogspot.com.br/2011/01/habilitando-o-suporte-acentuacao-no.html . Acessado em 28/02/2013.

Microsoft. CHCP. Disponível em: http://technet.microsoft.com/en-us/library/bb490874.aspx. Acessado em 06/03/2013.

Raphael Fernandes, quinta-feira, março 07, 2013

2 comentários