quarta-feira, 17 de dezembro de 2014

Gerenciando a Lixeira no Oracle 10g

Fonte: http://www.devmedia.com.br/gerenciando-a-lixeira-no-oracle-10g/7895

Gerenciando a Lixeira no Oracle 10g

O objetivo deste artigo é apresentar o funcionamento da Lixeira no Oracle 10g, as implicações deste novo comportamento e como utilizar esta nova funcionalidade.

A partir da versão 10g, quando uma tabela é dropada, o SGBD não remove automaticamente o espaço desta das tablespaces, a não ser que o parâmetro PURGE tenha sido especificado no comando DROP. Na realidade os metadados da tabela, dos índices e das constraints associadas a esta são renomeados e colocados em uma tabela conhecida como recycle bin, ou simplesmente, lixeira. Desta forma, caso a tabela tenha sido excluída erroneamente é possível recuperá-la posteriormente. Esta funcionalidade é chamada de Flashback Drop e através do comando FLASHBACK TABLE é realizada a recuperação.

O objetivo deste artigo é apresentar o funcionamento da Lixeira, as implicações deste novo comportamento e como utilizar esta nova funcionalidade.

A tabela Recycle Bin

Esta tabela do dicionário contém informações sobre os objetos deletados, sendo eles tabelas, índices, triggers e contraints. Uma vez que a exclusão física não é mais realizada após o comando de DROP, estes objetos ainda continuam ocupando espaço nas tablespaces até que sejam efetivamente removidos ou até que outro objeto da tablespace necessite de espaço para extensão.

As exceções ocorrem quando uma tablespace e o seu conteúdo ou um usuário e seus objetos são excluídos. Em ambos os casos os objetos não são transferidos para a lixeira e os que já se encontravam na mesma são expurgados. Os índices bitmap join, os logs de materialized views e as constraints de integridade referencial associados a uma tabela também não são transferidos para a lixeira.

Para saber quais os objetos do usuário estão na lixeira basta realizar a seguinte query:

SELECT * FROM RECYCLEBIN;

Ou através do SQL*Plus Release 10.2.0.1.0 para visualizar somente as tabelas:

SQL> show recyclebin
 
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
--------------- ------------------------------ ------------ --------------
EMPLOYEES BIN$yrMKlZaVMhfgNAgAIMenRA==$0 TABLE 2003-10-27:14:00:19
IDX_EMP BIN$yrQIJMkVDlopOAlAIMenRA==$1 INDEX 2003-10-27:14:00:19
EMPLOYEES BIN$yrMJVBaVMimtNAgAIMiqRA==$5 TABLE 2003-10-27:10:23:02

A seguir a estrutura da lixeira (tabela recyclebin) obtida através do describe:

SQL> desc recyclebin
 
Nome Nulo? Tipo
----------------------------------------- -------- -------------------------
OBJECT_NAME NOT NULL VARCHAR2(30)
ORIGINAL_NAME VARCHAR2(32)
OPERATION VARCHAR2(9)
TYPE VARCHAR2(25)
TS_NAME VARCHAR2(30)
CREATETIME VARCHAR2(19)
DROPTIME VARCHAR2(19)
DROPSCN NUMBER
PARTITION_NAME VARCHAR2(32)
CAN_UNDROP VARCHAR2(3)
CAN_PURGE VARCHAR2(3)
RELATED NOT NULL NUMBER
BASE_OBJECT NOT NULL NUMBER
PURGE_OBJECT NOT NULL NUMBER
SPACE NUMBER

Ao serem transferidos para a lixeira, os objetos são renomeados para evitar conflitos, uma vez que uma mesma tabela pode ter sido excluída, recriada e depois excluída novamente. A coluna OBJECT_NAME contém o novo nome e a coluna ORIGINAL_NAME contém o nome do objeto antes de ser excluído. Na realidade recyclebin é um sinônimo público para a visão user_recyclebin.

Limpeza da Lixeira

Se um objeto não for mais necessário ele pode ser removido da lixeira usando o comando PURGE. É possível realizar a remoção de uma tabela ou índice, informando o seu nome novo ou o nome inicial. Como por exemplo:

PURGE TABLE "BIN$yrMKlZaVMhfgNAgAIMenRA==$0";
PURGE TABLE employees;
PURGE INDEX "BIN$yrQIJMkVDlopOAlAIMenRA==$1";
PURGE INDEX idx_emp;

Caso exista mais de um objeto na lixeira com o mesmo nome inicial, o mais antigo será eliminado. Quando uma tabela é completamente eliminada da lixeira, todas as suas partições, LOBs, índices e constraints associados também são eliminados.

No comando de PURGE, também pode ser especificada a tablespace de modo a excluir fisicamente todos os objetos da lixeira que se encontram na mesma ou somente os objetos de um usuário:

PURGE TABLESPACE users;
PURGE TABLESPACE users USER hr;

Um usuário também pode limpar toda a sua lixeira através do comando:

PURGE RECYCLEBIN;

O DBA poderá agendar um procedimento periódico de limpeza da lixeira de todos os esquemas do banco de dados, dê preferência após um backup completo, utilizando o comando abaixo e conectado como sys as sysdba:

PURGE DBA_RECYCLEBIN;

O próprio SGBD poderá realizar uma limpeza da lixeira caso uma tablespace tenha atingido o seu tamanho máximo e espaço adicional seja necessário para o crescimento dos seus objetos. Neste caso os primeiros objetos a serem eliminados da lixeira são os índices porém serão eliminados tantos objetos da lixeira quanto forem necessários para o espaço que estiver sendo demandado na tablespace.

Recuperando objetos da Lixeira

O comando para recuperar uma tabela da lixeira é o FLASHBACK TABLE ... TO BEFORE DROP, onde é possível especificar o nome original ou o novo nome atribuído a tabela. Quando uma tabela é recuperada, os objetos associados também são recuperados, como índices, triggers e constraints.

FLASHBACK TABLE employees TO BEFORE DROP;

A cláusula RENAME TO permite que a tabela receba um novo nome na recuperação. Trata-se de uma cláusula opcional porém necessária caso exista uma tabela com o mesmo nome da original no esquema do usuário. A seguir um exemplo:

FLASHBACK TABLE employees TO BEFORE DROP RENAME TO old_emp;

Infelizmente os objetos associados recuperados, como índices, triggers e constraints, não retornam aos seus nomes originais por isso é necessário recuperar os nomes dos objetos da visão recyclebin antes do comando FLASHBACK TABLE e depois executar o comando ALTER RENAME TO para renomeá-los.

Caso exista mais de um objeto com o mesmo nome original, o excluído mais recentemente será recuperado. Porém se a intenção do usuário for recuperar uma determinada versão do objeto que foi excluído que não seja a mais recente deve ser especificado o novo nome atribuído ao objeto pela lixeira.

FLASHBACK TABLE "BIN$yrMKlZaVMhfgNAgAIMenRA==$0"
TO BEFORE DROP RENAME TO old_old_emp;

DROP Table

A sintaxe do comando DROP TABLE sofreu alterações para que seja possível especificar que remoção física da tabela e dos outros objetos relacionados a esta seja realizada sem transferi-los para a lixeira.

DROP TABLE [ schema. ]table [ CASCADE CONSTRAINTS ] [ PURGE ] ;

A Lixeira no SQL Developer

Através do SQL Developer também é possível visualizar, limpar ou recuperar objetos da lixeira.

segunda-feira, 1 de dezembro de 2014

Publicando WebService no TomCat

Fonte: http://www.devmedia.com.br/construindo-um-webservice-em-java/4516

Instalando o Tomcat

1) Baixe o Tomcat em : http://tomcat.apache.org/ (No meu caso, baixei a versão 5.5, formato .msi para executar em um Windows 2000)

2) Após baixar, executar o processo de instalação. (No caso do arquivo .msi basta executa-lo).

3) A instalação pode ser feita sem alterar nenhum dos parâmetros pré-definidos.

4) Ao chegar no fim da instalação, deixe a opção “Run Apache Tomcat” marcada para que a própria instalação execute o Tomcat.

5) Se tudo tiver corrido bem, deve ter sido adicionado ao lado do relógio do Windows, a ícone do Tomcat. Caso sua instalação seja feita no mundo Linux, você deve conseguir visualizar o processo através do comando ps –ef .

Após a instalação do Tomcat, você deve realizar um último teste para certificar-se que ele esta funcionando de maneira correta.

Abra o browser de sua preferência e digite o endereço : http://localhost:8080/

Se tudo estiver funcionando deverá aparecer à tela abaixo.

Após a instalação do Tomcat, devemos instalar o Axis.

Instalando o Axis

1) Baixe o Axis do endereço: http://ws.apache.org/axis/ (No meu caso, baixei a versão 1.4 no formato .zip para executar no Windows 2000)

2) Descompacte o arquivo no diretório que desejar.

3) Ao terminar de descompactar, deve existir um diretório denominado “axis”. Dentro deste diretório você irá encontrar um diretório “webapps”. Copie o diretório “axis“ que está localizado dentro do “webapps” para o diretório “webapps”do Tomcat. No meu caso, a copia será feita assim:

De: C:\Documentos\Instaldores\tomcat\axis\axis-1_4\webapps\

Para: C:\Arquivos de programas\Apache Software Foundation\Tomcat 5.5\webapps\

Para testar se a instalação e a copia foram feitas corretamente, digite no browser o seguinte endereço: http://localhost:8080/axis/

Deverá aparecer a seguinte tela:

Pronto, após a instalação do Tomcat e do Axis, e com tudo funcionando, podemos partir para criação efetiva do nosso Webservice.

Criando o WebService

Primeiramente, é necessário esclarecermos que um WebService em Java não é nada mais que uma classe, uma simples classe.

Para realizar este artigo criei a classe abaixo:

public class Soma {

public int getSoma(int n1, int n2) {

return n1+n2;

}

1) Após a criação da classe, copie o arquivo .java para dentro do diretório do axis. No meu caso : C:\Arquivos de programas\Apache Software Foundation\Tomcat 5.5\webapps\axis\

2) Troque a extensão deste arquivo de .java para .jws.

3) Após trocar a extensão do arquivo, acesse no browser o endereço : http://localhost:8080/axis/Soma.jws

4) Se você estiver vendo a tela acima, está tudo OK!

5) Click no link indicado pela tela e lhe será apresentado à definição de seu Webservice

Note que nosso método getSoma(int n1, int n2) aparece na definição do WSDL.

PRONTO!

WSDL – O que é? Pra que serve?

Fonte: http://fabriciosanchez.com.br/2/wsdl-o-que-e-pra-que-serve-onde-utilizo/

RPC – Remote Procedure Calls

RPC (em português, chamada de procedimentos remotos) é um modelo que define a forma como são realizadas as chamadas a operações remotas através de web services.

O modelo descreve o funcionamento de chamadas remotas, de forma semelhante a chamada de procedimentos locais. Assim, a diferença fundamental de um modelo em relação ao outro consiste no fato de que, no modelo descrito pelo RPC, temos a presença marcante de duas figuras trabalhando ativamente: o cliente e o servidor.

Basicamente, no modelo RPC tem-se uma thread responsável por gerir o processo de requisição e resposta, que funciona da seguinte forma:

O processo invocador (A) faz uma requisição ao processo servidor (B). Enquanto esta resposta não é devolvida com todos os parâmetros, o processo A aguarda bloqueado (ou seja, nenhuma outra operação pode ser realizada por A). A mensagem enviada por A, possui toda parametrização necessária para a execução da mesma e posterior resposta por parte de B.
O processo B recebe a solicitação, extrai os dados, processa a mesma e produz os resultados e devolve a resposta para A. Vale notar que, assim que a resposta foi despachada, B volta a esperar por uma nova requisição.

Neste modelo de comunicação, apenas um processo permanece ativo em determinado instante de tempo. Variações do modelo RPC, permitem a comunicação assíncrona, mas este é um assunto para outro post. A Figura 1 apresenta o modelo de comunicação RPC.

Figura 1: O modelo RPC de comunicação inter-processos

WSDL – O que é?

WSDL é um documento proposto pela W3C a partir de Junho de 2007 escrito em XML que visa padronizar as descrições das funcionalidades ofereridas por web services de forma independente de plataforma ou linguagem. Possui basicamente duas finalidades:

Expor os métodos que determinado serviço disponibilizará
Possibilitar a localização de determinado serviço

Como mencionado anteriormente, WSDL é escrito em XML, portanto, para que se possa elaborá-lo, é preciso acumular alguns conhecimentos, tais como: XML Namespaces, XML Schemas, etc.

Outro conceito importante relacionado a WSDL é o fato de que ele trabalha em parceria com outras duas tecnologias, sendo elas: UDDI e SOAP. Em posts futuros, trataremos destes dois assuntos com maiores detalhes. Por hora, basta mencionar que enquanto WSDL apresenta os recursos disponíveis, UDDI permite a publicação do serviço e SOAP possibilita o tráfego das informações.

WSDL – Elementos básicos

Como mencionado anteriormente, WSDL é um documento XML simples que descreve através de elementos específicos, a estrutura dos serviços web. Assim, sua estrutura é extremamente simplificada. A seguir apresentamos os principais elementos descritivos de um documento WSDL.

<types>: aqui deverão ser descritos os tipos de dados suportados pelo serviço em questão
<message>: aqui devem ser especificados os padrões de entrada e saída de dados dos web services
<portType>: aqui devem ser descritos os agrupamentos lógicos das operações. São as operações executadas pelo web service
<binding>: aqui devem ser apresentados os protocolos de comunicação que os web services utilizam
<operation>: região que permite a especificação das assinaturas dos métodos disponibilizados
<definitions>: elemento padrão de todos os documentos WSDL. Permite efetuar descrições sobre schemas enamespaces

Mais adiante neste post, analisaremos um arquivo WSDL pronto para que possamos entender em nível prático como se dá a construção do mesmo.

WSDL – Namespaces

Se você trabalha com C#, por exemplo, já está acostumado com o conceito de namespaces. Para arquivos WSDL, a ideia é rigorosamente a mesma, isto é, os conceitos de reaproveitamento e organização de códigos são implementados também. A seguir, apresentamos os principais namespaces já disponíveis para WSDL.

http://schemas.xmlsoap.org/wsdl: namespace de WSDL
http://schemas.xmlsoap.org/wsdl/soap: namespace que permite a utilização de WSDL com SOAP
http://schemas.xmlsoap.org/wsdl/http: namespace que permite HTTP, GET e POST
http://schemas.xmlsoap.org/wsdl/mime: namespace que permite a vinculação de MIME aos WSDLs
http://schemas.xmlsoap.org/soap/encoding: namespace que permite a codificação segundo padrão SOAP
http://schemas.xmlsoap.org/soap/envelope: namespace que permite a codificação segundo padrão SOAP 1.1
http://www.w3.org/2001/XMLSchema-instance: namespace de instância definido pelo padrão XML
http://www.w3.org/2001/XMLShema: namespace de schemas definido conforme regras do XML

Sobre o exemplo deste post

Agora que já fomos apresentados aos conceitos fundamentais sobre WSDL, podemos estruturar um arquivo para que possamos aplicar os conceitos de forma satisfatória.

Basicamente existem duas formas para escrever arquivos WSDL, sendo que, a forma escolhida impacta também na forma como a associação com o serviço é realizada. As formas as quais nos referimos são: manual (onde o arquivo WSDL é estruturado manualmente pelo desenvolvedor) e automática (gerado pela ferramenta onde o o serviço é criado). Se você optar por criar um serviço utilizando Visual Studio 2010 e WCF, por exemplo, o arquivo WSDL vai sendo gerado a medida que o serviço é estruturado.

O que faremos é criar um serviço de disponibiliza um método que reajusta o salário informado de acordo com uma faixa salarial fictícia.

Criando o web service

Para criar o serviço, utilizarei o Mono Develop, entretanto, você pode utilizar o Visual Studio ou outra ferramenta qualquer de desenvolvimento que será possível obter o mesmo resultado. A Listagem 1 apresenta o código doweb service.

<%@ WebService Language="C#" Class="WebServiceReajusteDeSalario.WSReajusteSalario" %>

using System;

using System.Web.Services;

namespace WebServiceReajusteDeSalario

{

public class WSReajusteSalario : System.Web.Services.WebService

{

[WebMethod]

public string CalculaReajusteSalario(string pSalario)

{

string SalarioFormatado = pSalario.Replace(",",".");

if(SalarioFormatado == "" || SalarioFormatado == string.Empty || SalarioFormatado == null)

{

return "Erro ao tentar calcular o reajuste!";

}

else

{

double dSalario = Convert.ToDouble(SalarioFormatado);

if(dSalario >=0 && dSalario <=600.0)

{

dSalario *= 1.8;

return Convert.ToString(dSalario);

}

else if(dSalario >= 601.0 && dSalario <= 1000.0)

{

dSalario *= 1.5;

return Convert.ToString(dSalario);

}

else

{

dSalario *= 1.2;

return Convert.ToString(dSalario);

}

}

}

}

}

Listagem 1: Serviço que calcula o reajuste de salário

O código do serviço é simples e dispensa maiores comentários. Como estamos criando um serviço ASMX, estamos trabalhando com o protocolo SOAP no encapsulamento das informações trafegadas e, portanto, precisamos de um arquivo WSDL para apresentar a descrição do serviço. A Listagem 2 apresenta o código do arquivo gerado pelo Mono Develop para o serviço em questão.

<?xml version="1.0" encoding="utf-8"?>

<definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:s="http://www.w3.org/2001/XMLSchema"

xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"

xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:s0="http://tempuri.org/"

name="WSReajusteSalario" targetNamespace="http://tempuri.org/"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<xs:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="CalculaReajusteSalario">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="1" name="pSalario" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="CalculaReajusteSalarioResponse">

<xs:complexType>

<xs:sequence>

<xs:element minOccurs="0" maxOccurs="1" name="CalculaReajusteSalarioResult"

type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="string" nillable="true" type="xs:string"/>

</xs:schema>

</types>

<message name="CalculaReajusteSalarioSoapIn">

<part name="parameters" element="s0:CalculaReajusteSalario"/>

</message>

<message name="CalculaReajusteSalarioSoapOut">

<part name="parameters" element="s0:CalculaReajusteSalarioResponse"/>

</message>

<message name="CalculaReajusteSalarioHttpGetIn">

<part name="pSalario" type="s:string"/>

</message>

<message name="CalculaReajusteSalarioHttpGetOut">

<part name="Body" element="s0:string"/>

</message>

<message name="CalculaReajusteSalarioHttpPostIn">

<part name="pSalario" type="s:string"/>

</message>

<message name="CalculaReajusteSalarioHttpPostOut">

<part name="Body" element="s0:string"/>

</message>

<portType name="WSReajusteSalarioSoap">

<operation name="CalculaReajusteSalario">

<input message="s0:CalculaReajusteSalarioSoapIn"/>

<output message="s0:CalculaReajusteSalarioSoapOut"/>

</operation>

</portType>

<portType name="WSReajusteSalarioSoap12">

<operation name="CalculaReajusteSalario">

<input message="s0:CalculaReajusteSalarioSoapIn"/>

<output message="s0:CalculaReajusteSalarioSoapOut"/>

</operation>

</portType>

<portType name="WSReajusteSalarioHttpGet">

<operation name="CalculaReajusteSalario">

<input message="s0:CalculaReajusteSalarioHttpGetIn"/>

<output message="s0:CalculaReajusteSalarioHttpGetOut"/>

</operation>

</portType>

<portType name="WSReajusteSalarioHttpPost">

<operation name="CalculaReajusteSalario">

<input message="s0:CalculaReajusteSalarioHttpPostIn"/>

<output message="s0:CalculaReajusteSalarioHttpPostOut"/>

</operation>

</portType>

<binding name="WSReajusteSalarioSoap" type="s0:WSReajusteSalarioSoap">

<soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="CalculaReajusteSalario">

<soap:operation soapAction="http://tempuri.org/CalculaReajusteSalario" style="document"/>

<input>

<soap:body use="literal"/>

</input>

<output>

<soap:body use="literal"/>

</output>

</operation>

</binding>

<binding name="WSReajusteSalarioSoap12" type="s0:WSReajusteSalarioSoap12">

<soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/>

<operation name="CalculaReajusteSalario">

<soap12:operation soapAction="http://tempuri.org/CalculaReajusteSalario"

style="document"/>

<input>

<soap12:body use="literal"/>

</input>

<output>

<soap12:body use="literal"/>

</output>

</operation>

</binding>

<binding name="WSReajusteSalarioHttpGet" type="s0:WSReajusteSalarioHttpGet">

<http:binding verb="GET"/>

<operation name="CalculaReajusteSalario">

<http:operation location="/CalculaReajusteSalario"/>

<input>

<http:urlEncoded/>

</input>

<output>

<mime:mimeXml part="Body"/>

</output>

</operation>

</binding>

<binding name="WSReajusteSalarioHttpPost" type="s0:WSReajusteSalarioHttpPost">

<http:binding verb="POST"/>

<operation name="CalculaReajusteSalario">

<http:operation location="/CalculaReajusteSalario"/>

<input>

<mime:content type="application/x-www-form-urlencoded"/>

</input>

<output>

<mime:mimeXml part="Body"/>

</output>

</operation>

</binding>

<service name="WSReajusteSalario">

<port name="WSReajusteSalarioSoap" binding="s0:WSReajusteSalarioSoap">

<soap:address location="http://127.0.0.1:8080/WSReajusteSalario.asmx"/>

</port>

<port name="WSReajusteSalarioSoap12" binding="s0:WSReajusteSalarioSoap12">

<soap12:address location="http://127.0.0.1:8080/WSReajusteSalario.asmx"/>

</port>

<port name="WSReajusteSalarioHttpGet" binding="s0:WSReajusteSalarioHttpGet">

<http:address location="http://127.0.0.1:8080/WSReajusteSalario.asmx"/>

</port>

<port name="WSReajusteSalarioHttpPost" binding="s0:WSReajusteSalarioHttpPost">

<http:address location="http://127.0.0.1:8080/WSReajusteSalario.asmx"/>

</port>

</service>

</definitions>

Listagem 2: Código do arquivo WSDL criado

Como é possível observar, o arquivo WSDL possui todas as informações sobre o serviço criado, tais como: nome, encode, descrição do método disponível, MIME, etc., e tudo isso, em um formato extremamente simples – XML. A Figura 2 apresenta o serviço criado em funcionamento.

Figura 2: Serviço em execução

Bom pessoal, por hoje é isso. Espero que este post possa tê-lo ajudado a entender o conceito relacionado aos arquivos WSDL e sua importância no conexto da comunicação de aplicações.

Alexandre Palmeira

quarta-feira, 17 de dezembro de 2014