Aprenda PL/SQL

Tag Archive: Oracle 11g

A maioria das pessoas tem essas perguntas sobre Index Partition:

  • O que é um Local Index?
  • O que é um Global Index?
  • Quando você forçaria a criação de um Global Index em uma partition table?
  • Quando você recomendaria criar um Global Index em vez de um Local Index?

Para responder a essas perguntas….

1. O que é um Local Index?

Local Indexes particionados são mais fáceis de gerenciar, cada partição do Local Index está associado a uma partição. Eles também oferecem maior disponibilidade e são comuns em ambientes de DSS. Quando tomamos qualquer ação (MERGE, SPLIT,EXCHANGE etc) em um Local Index, isso impacta apenas aquela partição e as outras estarão disponíveis. Nós não podemos adicionar explicitamente um Local Index para uma nova partição. O Local Index será adicionado implicitamente a nova partição, quando for criada uma nova partição na tabela. Da mesma forma, não podemos dropar o índice local em uma partição específica. Ele pode ser dropado automaticamente quando nós dropamos a partição da tabela subjacente. Local Indexes podem ser UNIQUE quando a chave da partição é parte do índice composto. Unique Local Indexes são úteis para o ambiente OLTP. Podemos também criar bitmap indexes em tabelas, com a restrição de que os índices de bitmap deve ser local para a tabela particionada. Eles não podem ser Global Indexes.

SQL> CREATE TABLE employees
2 (employee_id NUMBER(4) NOT NULL,
3 last_name VARCHAR2(10),
4 department_id NUMBER(2))
5 PARTITION BY RANGE (department_id)
6 (PARTITION employees_part1 VALUES LESS THAN (10) TABLESPACE ODS_STAGE_DATA,
7 PARTITION employees_part2 VALUES LESS THAN (20) TABLESPACE ODS_STAGE_DATA,
8 PARTITION employees_part3 VALUES LESS THAN (30) TABLESPACE ODS_STAGE_DATA);

Table created.

SQL> declare
2 v_no number :=1;
3 begin
4 delete employees;
5 for i in 1..10 loop
6 insert into employees values(v_no,'name...',v_no);
7 v_no := v_no+1;
8 end loop;
9 end;
10 /

PL/SQL procedure successfully completed.

SQL>
SQL> create index idx_local on employees(last_name) local;

Index created.

SQL>


Leia mais…




Eu considero Edition-Based Redefinition a nova característica mais matadora do Oracle Database 11g Release 2. Em suma, é a capacidade de executar uma atualização de aplicações online. É também um recurso gigante, tão grande que vai demorar pelo menos três colunas para descrevê-lo. Vou começar em Como usar Edition-Based Redefinition afim de aplicar “patches” em sistemas.

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.
Leia mais…




Colunas Virtuais no 11g – Parte 2 – Índices e Constraints

Continuando o artigo sobre colunas virtuais no Oracle 11g, veremos outras possibilidades do uso dessa feature.

Se tentarmos inserir dados que resultem em uma coluna virtual duplicada, podemos esperar uma violação de Unique Constraint:
Leia mais…




Oracle suportou expressões armazenadas por muitos anos, em views e índices baseados em função. Mais principalmente, são as views que nos permitem armazenar e modularisar expressões calculadas baseados em outras colunas da tabela.

Em versões mais recentes (a partir do 8i), temos como indexar as colunas baseados em função. (Function based indexes). Agora, a partir da versão 11g, o banco Oracle nos permite também armazenar expressões diretamente nas tabelas como colunas virtuais.

Como veremos neste artigo, colunas virtuais são mais flexíveis que as outras alternativas citadas. Vamos examinar seu uso básico e também considerar alguns outros aspectos dessa nova feature.
Leia mais…