ORACLE – Furushima https://furushima.com.br - Consultoria de Banco de Dados | Furushima Tue, 10 Jun 2025 11:04:16 +0000 pt-BR hourly 1 https://furushima.com.br/wp-content/uploads/2024/02/cropped-favicon-32x32.png ORACLE – Furushima https://furushima.com.br 32 32 Estruturas de Armazenamento do Oracle https://furushima.com.br/blog/estruturas-de-armazenamento-do-oracle/ Tue, 10 Jun 2025 10:59:20 +0000 https://furushima.com.br/?p=2841 Como o Oracle armazena os dados?

A estrutura de armazenamento do Oracle Database é projetada para ser altamente eficiente e flexível, permitindo o armazenamento e o gerenciamento de grandes volumes de dados de forma organizada e segura.

Visão Geral da Estrutura de Armazenamento

O Oracle organiza os dados em várias camadas hierárquicas, garantindo escalabilidade e otimização. As principais estruturas de armazenamento do Oracle são:

  • Database (Banco de dados)
  • Tablespace
  • Segment
  • Extent
  • Oracle Data Block

Cada um desses níveis desempenha um papel importante na organização e armazenamento dos dados.

Database

No nível mais alto da hierarquia, temos o Database. O banco de dados Oracle é composto por vários arquivos de dados que armazenam as informações do usuário e os metadados necessários para o funcionamento do sistema. Ele é o contêiner principal que engloba todos os outros componentes de armazenamento.

O Oracle Database é composto por três tipos principais de arquivos:

  • Datafiles: Armazenam os dados reais.
  • Redo Log Files: Guardam um histórico das alterações no banco, usados para recuperação em caso de falhas.
  • Control Files: Contêm informações estruturais sobre o banco, como a localização dos datafiles e redo logs.

Tablespace

O Tablespace é o próximo nível da hierarquia e age como um contêiner lógico para organizar os dados dentro do banco de dados. Ele agrupa múltiplos datafiles, que são arquivos físicos no sistema operacional onde os dados reais são armazenados. Um banco de dados pode ter vários tablespaces, sendo cada um especializado em armazenar diferentes tipos de objetos de dados.

Os tablespaces podem ser divididos em dois tipos principais:

  • Permanent Tablespaces: Armazenam dados persistentes, como tabelas e índices.
  • Temporary Tablespaces: Usados para operações temporárias, como ordenações ou junções de dados durante consultas.

Exemplos comuns de tablespaces incluem:

  • SYSTEM: Onde ficam os dicionários de dados (metadados do banco).
  • SYSAUX: Um tablespace auxiliar para armazenar componentes não-críticos, como o AWR.
  • USERS: Um tablespace típico onde são armazenados os dados dos usuários.

Segment

Dentro de cada tablespace, encontramos os segments. Um segmento é um espaço lógico alocado para armazenar um tipo específico de objeto de banco de dados, como uma tabela, índice, view materializada, rollback segment, etc.

Cada tipo de segmento desempenha um papel específico:

  • Data Segments: Armazenam os dados reais das tabelas.
  • Index Segments: Contêm os índices de tabelas para melhorar a performance de busca.
  • Temporary Segments: Usados para operações temporárias, como ao realizar consultas grandes.
  • Undo Segments: Utilizados para manter o controle das transações para garantir a consistência dos dados e permitir rollback.

Os segmentos são compostos por unidades de espaço chamadas extents.

Extent

Um extent é uma unidade contígua de espaço dentro de um segmento, onde os dados são armazenados fisicamente nos datafiles. Um segmento é composto por um ou mais extents, que são alocados conforme necessário para acomodar o crescimento do objeto de banco de dados (como uma tabela que aumenta de tamanho).

Quando um segmento precisa de mais espaço, o Oracle aloca um novo extent para ele. Os extents garantem que os dados sejam armazenados em blocos contínuos, o que melhora a eficiência de leitura/escrita.

Oracle Data Block

O nível mais baixo da hierarquia de armazenamento é o Oracle Data Block, também chamado de database block ou data block. Os data blocks representam a menor unidade de armazenamento no Oracle Database. Cada extent é composto de múltiplos data blocks.

Os data blocks armazenam os dados reais, como as linhas de uma tabela. Eles são a interface entre o banco de dados e o sistema de arquivos subjacente. O tamanho dos data blocks é configurável e pode variar (tipicamente 4KB, 8KB, 16KB ou 32KB), dependendo das necessidades do ambiente.

Os data blocks contêm várias informações, além dos dados do usuário, como cabeçalhos que registram metadados importantes, como o endereço do bloco e informações de transações.

Componentes de um Oracle Data Block

Um data block possui várias subestruturas:

  1. Cabeçalho do Bloco (Block Header): Contém metadados sobre o bloco, como o endereço do bloco, identificadores de transações ativas e status de formatação.
  2. Tabela de Diretório (Table Directory): Mantém informações sobre as tabelas cujos dados estão armazenados neste bloco (importante em caso de blocos com dados de mais de uma tabela).
  3. Tabela de Linhas (Row Directory): Lista de ponteiros para as linhas reais armazenadas no bloco.
  4. Linhas de Dados: São os dados reais das colunas de uma tabela.
  5. Espaço Livre (Free Space): Espaço não utilizado no bloco que pode ser usado para inserções futuras ou expansões de linhas.
  6. Gerenciamento de Espaço: O Oracle utiliza métodos sofisticados para o gerenciamento de espaço dentro dos blocos, como o PCTFREE (percentual de espaço reservado para futuras atualizações) e PCTUSED (percentual de ocupação após o qual novos dados podem ser inseridos no bloco).

Tabelas e Índices no Oracle Data Block

Os data blocks podem armazenar dados de tabelas e índices. Ao trabalhar com tabelas:

  • As linhas da tabela são armazenadas dentro dos data blocks.
  • Em caso de atualização, se a linha de dados crescer e não couber no bloco original, pode ocorrer a migração de linhas ou encadeamento de linhas, em que a linha é movida para outro bloco, o que pode afetar a performance.

No caso de índices, os data blocks são usados para armazenar as estruturas de árvore B-tree que organizam e aceleram a busca de dados.


No Oracle Database, a parametrização de armazenamento em uma tabela, definida pela cláusula STORAGE, determina como o espaço em disco será alocado e gerenciado para essa tabela. Esses parâmetros são essenciais para otimizar o uso de espaço, controlar o crescimento dos segmentos e reduzir a fragmentação. Eles influenciam aspectos como o tamanho dos extents, a reserva de espaço para atualizações futuras e a frequência de alocação de novos extents. Vamos explorar esses parâmetros com base na tabela de exemplo “empregados”:

CREATE TABLE empregados (
    empregado_id NUMBER PRIMARY KEY,
    nome VARCHAR2(100),
    cargo VARCHAR2(50),
    salario NUMBER(10, 2),
    data_admissao DATE DEFAULT SYSDATE,
    departamento_id NUMBER,
    CONSTRAINT fk_departamento
    FOREIGN KEY (departamento_id) REFERENCES departamentos(departamento_id)
) TABLESPACE meu_tablespace
STORAGE (
    INITIAL 64K
    NEXT 128K
    PCTINCREASE 0
)
PCTFREE 10
PCTUSED 40;

Parâmetros de Armazenamento (STORAGE Clause)

1. INITIAL

  • Descrição: Define o tamanho do primeiro extent alocado para o segmento da tabela. Um extent é uma unidade contígua de espaço no disco alocada para armazenar dados.
  • Exemplo: "INITIAL 64K" significa que o primeiro extent terá 64 kilobytes. Isso determina o espaço inicial reservado para a tabela ao ser criada, influenciando a capacidade inicial de armazenamento.

2. NEXT

  • Descrição: Especifica o tamanho dos extents subsequentes alocados após o primeiro. À medida que a tabela cresce e o primeiro extent é preenchido, um novo extent é alocado com o tamanho definido aqui.
  • Exemplo: "NEXT 128K" indica que cada novo extent alocado após o primeiro terá 128 kilobytes. Esse valor ajuda a controlar o crescimento da tabela ao longo do tempo, garantindo alocações eficientes de espaço.

3. PCTINCREASE

  • Descrição: Define a porcentagem de aumento de cada novo extent em relação ao anterior. Isso controla o crescimento progressivo dos extents.
  • Exemplo: "PCTINCREASE 0" indica que todos os extents subsequentes terão o mesmo tamanho definido em "NEXT", ou seja, 128K. Se fosse configurado um valor diferente de zero, cada novo extent seria maior que o anterior, aumentando pela porcentagem especificada. Por exemplo, se "PCTINCREASE" fosse 50, o próximo extent após 128K seria 192K (50% maior).

Outros Parâmetros de Tabela

1. PCTFREE

  • Descrição: Determina a porcentagem de espaço em cada data block que é reservada para futuras atualizações de linhas já existentes. Isso garante que, ao alterar valores de uma linha, o bloco tenha espaço suficiente para armazenar os novos dados sem precisar movê-los para um bloco diferente.
  • Exemplo: "PCTFREE 10" reserva 10% de cada data block para atualizações futuras. Se uma linha for atualizada e seus novos dados excederem o espaço previamente alocado para ela, os 10% reservados serão usados para evitar a migração de linhas para outros blocos, o que poderia impactar a performance.

2. PCTUSED

  • Descrição: Define a porcentagem mínima de ocupação de um data block antes que ele seja reutilizado para novas inserções de dados. Após a exclusão ou movimentação de linhas, se o percentual de uso do bloco cair abaixo desse limite, o bloco será reutilizado para novas inserções.
  • Exemplo: "PCTUSED 40" indica que, quando a ocupação do bloco cair abaixo de 40%, ele será marcado como disponível para novas inserções de dados. Esse parâmetro ajuda a evitar fragmentação e melhora a eficiência na reutilização de blocos parcialmente cheios.

Como Esses Parâmetros Funcionam Juntos

  1. Alocação Inicial e Crescimento de Extents:
    • Ao criar a tabela, o Oracle aloca um extent inicial de 64K, conforme definido em "INITIAL". À medida que os dados são inseridos e o extent inicial é preenchido, o Oracle aloca novos extents de 128K, conforme especificado em "NEXT". Como "PCTINCREASE" está definido como 0, todos os extents subsequentes terão o mesmo tamanho de 128K. Isso mantém o crescimento linear e previsível da tabela.
  2. Gerenciamento de Espaço Livre em Data Blocks:
    • O parâmetro "PCTFREE 10" garante que 10% de cada data block seja reservado para atualizações de dados. Isso é importante para evitar que atualizações frequentes de linhas movam os dados para novos blocos, o que reduziria a eficiência de leitura. Esse espaço reservado permite que as linhas cresçam dentro do mesmo bloco.
    • O parâmetro "PCTUSED 40" garante que blocos parcialmente utilizados sejam reutilizados para novas inserções quando sua ocupação cair abaixo de 40%. Isso ajuda a evitar o desperdício de espaço em blocos que não estão completamente cheios e reduz a necessidade de alocar novos blocos, otimizando o uso do espaço.

Benefícios da Configuração Correta dos Parâmetros de Armazenamento

Ao configurar corretamente os parâmetros de armazenamento, é possível otimizar o uso de espaço e melhorar a performance da tabela. Esses parâmetros permitem ao DBA:

  • Controlar o crescimento do segmento: Ao especificar tamanhos adequados para os extents e definir políticas claras para a alocação subsequente, o crescimento da tabela é gerenciado de maneira eficiente, evitando fragmentação excessiva.
  • Gerenciar atualizações e inserções: Parâmetros como "PCTFREE" e "PCTUSED" garantem que os blocos de dados sejam utilizados de forma inteligente, reservando espaço para atualizações e reutilizando blocos que ficaram abaixo da ocupação mínima.
  • Prevenir fragmentação: O controle da alocação de extents e a reutilização de blocos parcialmente ocupados ajudam a minimizar a fragmentação, o que melhora a performance de leitura e escrita no banco de dados.

Esses parâmetros, quando bem configurados, são ferramentas poderosas para otimizar o armazenamento e o desempenho de tabelas no Oracle Database, garantindo uma utilização eficiente dos recursos de hardware e mantendo a performance à medida que a tabela cresce e é atualizada ao longo do tempo.

]]> Oracle Database Fases de Startup/Shutdown https://furushima.com.br/blog/oracle-database-fases-de-startup-shutdown/ Tue, 29 Apr 2025 15:11:13 +0000 https://furushima.com.br/?p=2818 Iniciando a instância do banco de dados Oracle


Antes que os usuários possam se conectar a uma instância de banco de dados, um administrador de banco de dados deve iniciar a instância do banco de dados. A instância e o banco de dados passam por estágios à medida que o banco de dados é disponibilizado para acesso pelos usuários. A instância é iniciada, o banco de dados é montado e, em seguida, o banco de dados é aberto, como mostrado no slide.


NOMOUNT: Nesta etapa, o software Oracle lê um arquivo de parâmetros de inicialização, PFILE ou SPFILE, inicia os processos em segundo plano, aloca memória para a SGA, abre o log de alerta e os arquivos de rastreamento. Uma instância é tipicamente iniciada apenas no modo NOMOUNT durante a criação do banco de dados, durante a recriação de arquivos de controle ou em cenários específicos de backup e recuperação.


MOUNT: Nesta etapa, o software Oracle associa o banco de dados à instância de banco de dados previamente iniciada, abre e lê o controlefile especificado no arquivo de parâmetros de inicialização, PFILE ou SPFILE, e obtém os nomes e estados dos datafiles e dos redo logs. No entanto, nesta fase, não são realizadas verificações para confirmar a existência dos datafiles e dos redo logs. Iniciar no modo MOUNT para executar algumas operações de manutenção, como renomear datafiles e realizar restore do banco de dados.


OPEN: O software Oracle abre os redo logs e os datafiles de acordo com a lista registrada no controlefile. Inicie no modo OPEN para permitir que os usuários se conectem à instância do banco de dados. Os PDBs não são iniciados por padrão quando você abre o banco de dados.

Desligando a instância do banco de dados Oracle

Às vezes, é necessário desligar a instância do banco de dados (por exemplo, para alterar um parâmetro estático ou aplicar um patch no servidor do banco de dados).

Use o comando SHUTDOWN para desligar a instância do banco de dados, porém há vários modos possívels de se desligar a instância: ABORT, IMMEDIATE, NORMAL e TRANSACTIONAL.

ABORTIMMEDIATENORMALTRANSACTIONAL
Permite novas conexõesNONONONO
Espera até que todas as sessões terminemNONOYESNO
Espera até que todas as transações terminemNONOYESYES
Força um checkpoint e fecha os todos os arquivosNOYESYESYES


ABORT: Se os outros modos de desligamento não funcionarem, você pode usar o modo ABORT. O modo ABORT executa a menor quantidade de trabalho antes de desligar. Como esse modo coloca o banco de dados em um estado inconsistente e requer recuperação antes do reinício, use-o apenas quando necessário. Não é aconselhável fazer backup do banco de dados nesse estado. Geralmente, é usado quando nenhuma outra forma de desligamento funciona, quando há problemas para iniciar a instância do banco de dados ou quando você precisa desligar imediatamente devido a uma situação iminente (como aviso de queda de energia em questão de segundos). O modo ABORT costuma ser o modo de desligamento mais rápido, e o modo NORMAL é o mais lento. Os modos NORMAL e TRANSACTIONAL podem levar muito tempo, dependendo do número de sessões e transações.


Durante um desligamento no modo ABORT, uma falha na instância ou um reinício da instância do banco de dados no modo FORCE, o que acontece com o banco de dados:

  • As declarações SQL atuais sendo processadas pelo servidor Oracle são imediatamente interrompidas.
  • O servidor Oracle não espera pelos usuários que estão atualmente conectados ao banco de dados se desconectarem.
  • Os buffers do banco de dados e de redo não são gravados em disco.
  • Transações não confirmadas não são revertidas.
  • A instância é terminada sem fechar os arquivos.
  • O banco de dados não é fechado ou desmontado.
  • O próximo reinício requer recuperação da instância, que ocorre automaticamente pelo processo SMON.

IMMEDIATE: Um desligamento no modo IMMEDIATE é a opção mais utilizada. • As declarações SQL atuais sendo processadas pela instância do banco de dados não são concluídas. • O servidor de banco de dados não espera pelos usuários que estão atualmente conectados à instância do banco de dados se desconectarem. • O servidor de banco de dados faz rollback das transações ativas e desconecta todos os usuários conectados. • O servidor de banco de dados fecha e desmonta o banco de dados antes de desligar a instância do banco de dados.

NORMAL: NORMAL é o modo de desligamento padrão se nenhum modo for especificado com o comando SHUTDOWN. • Novas conexões não podem ser feitas. • O servidor Oracle espera que todos os usuários se desconectem antes de concluir o desligamento. • Buffers de banco de dados e de redo são gravados em disco. • Processos em segundo plano são terminados e a SGA é removida da memória. • O servidor Oracle fecha e desmonta o banco de dados antes de desligar a instância.

TRANSACTIONAL: Um desligamento no modo TRANSACTIONAL impede que os clientes percam dados, incluindo resultados de sua atividade atual. • Nenhum cliente pode iniciar uma nova transação nesta instância específica. • Um cliente é desconectado quando o cliente encerra a transação que está em andamento. • Quando todas as transações forem concluídas, ocorre um desligamento imediato.

Exemplos práticos:

Executando apenas o comando STARTUP é possível verificar todas as etapas que a instância transita até o estado OPEN, onde a base de dados está aberta e pronta para receber conexões:

É possível escolher a fase de inicialização da instância utilizando as opções NOMOUNT ou MOUNT:

STARTUP NOMOUNT, o arquivo de parametros PFILE ou SPFILE será lido e apenas a instância fará a alocação na memória:

-- VERIFICAR O STATUS(FASE) DA INSTÂNCIA

SELECT STATUS FROM V$INSTANCE;


Ao consultar o status da instância, aparecerá


STARTUP MOUNT, o arquivo de parametros PFILE ou SPFILE será lido, a instância iniciará e o controlfile será montado:


Ao consultar o status da instância, aparecerá como MOUNTED:


SHUTDOWN IMMEDIATE, que é o mais utilizado, ve-se também todas as fases:

]]> Views no Oracle https://furushima.com.br/blog/views-no-oracle/ Thu, 24 Apr 2025 12:11:29 +0000 https://furushima.com.br/?p=2806 As views (ou também visões) são recursos bastante úteis em bancos de dados relacionais, pois permitem a criação de representações lógicas dos dados armazenados em tabelas, facilitando a consulta, segurança e manutenção.

Mas o que exatamente são as views?

Uma view pode ser entendida como uma tabela virtual que se baseia no resultado de uma consulta, ou seja, ao invés de armazenar os dados diretamente ela apenas exibe os dados pertencentes a outras tabelas. Estes dados são recuperados através de uma instrucão SQL toda vez que a view é executada.

De acordo com a documentação da versão 19c do Oracle, temos:

Use the CREATE VIEW statement to define a view, which is a logical table based on one or more tables or views. A view contains no data itself. The tables upon which a view is based are called base tables.

Vantagens ao utilizar views

– Simplicar consultar complexas

A utilização de views possibilita que uma query complexa seja encapsulada em uma query simples.

– Segurança no acesso aos dados

Através da utilização de views é possível restringir o acesso a colunas ou linhas específicas, podendo assim exibir somente os dados necessários.

– Abstração

Com as views é possível implementar uma camada de abstração que permite ocultar tanto a estrutura das tabelas ou até mesmo a fonte dos dados.

– Reutilização de consulta

Para consultas que são utilizadas com certa frequência é indica a criação de views para reduzir a repetição de código.

Tipos de Views no Oracle

Views

Podem ter desde uma estrutura simplificada baseada em apenas uma tabela e sem funções de agregações e joins ou até mesmo mais complexas com joins entre multiplas tabelas, funções de agregação, subconsultas, etç.

As views com estrutura simples geralmente permitem que sejam feitas inserções e alterações nos dados da tabela de origem.

Já as views que não permitem inserções e alterações são as que possuem clasulas como DISTINCT, funções de agregação, GROPU BY, ORDER BY, sub queries no select, condições recursivas com a clásula WITH, etç.

Independente da estrutura da view, ela não ocupa espaço em disco.

Mais informações disponíveis em https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/UPDATE.html

Exemplo:

CREATE VIEW vw_empresas AS
SELECT id, nome_empresa
FROM empresas;

Materialized Views

Já as materialized views (views materializadas) armazenam os dados fisicamente, ou seja, ela irá consumir espaço em disco.

As materialized views podem ser usadas para melhorar a performance em consultas complexas ou consultas que envolvam grandes volumes de dados.

Também é possível utiliá-las para transportar ou replicar dados para outros bancos de dados oracle através de database links.

As MVs podem ser atualizadas periodicamente ou sob demanda e podem ser totalmente reconstruídas a cada atualização ou de maneira incremental com a utilização de mlogs (materialized view logs).

Exemplo:

CREATE MATERIALIZED VIEW mv_vendas
REFRESH FAST ON COMMIT
AS
SELECT produto_id, SUM(quantidade) AS total_vendido
FROM vendas
GROUP BY produto_id;

]]> Como usar Hint no Oracle? https://furushima.com.br/blog/como-usar-hint-no-oracle/ https://furushima.com.br/blog/como-usar-hint-no-oracle/#respond Mon, 07 Apr 2025 19:31:00 +0000 https://furushima.com.br/?p=2662 Super Dicionário de Hints do Oracle

Quando trabalhamos com Oracle, um ponto importante para otimizar o desempenho das consultas SQL é entender como orientar o otimizador a escolher determinados planos de execução. É exatamente para isso que servem os hints.

Ao inserir hints (dicas) diretamente na consulta, podemos influenciar o Cost Based Optimizer (CBO) a tomar decisões mais adequadas em situações específicas.

O que são Hints?

Os hints são instruções especiais escritas em comentários dentro de uma consulta SQL, que afetam o plano de execução escolhido pelo Oracle. O formato geral é:






SELECT /*+ HINT_EXEMPLO */ coluna1, coluna2
FROM tabela
WHERE condicao;





    

  • Comentário especial: O Oracle reconhece a estrutura /*+ ... */ após o SELECT.
    • 




  • Case sensitive: Tecnicamente, o texto do hint não faz distinção entre maiúsculas e minúsculas, mas é fundamental que a sintaxe e o nome do hint estejam corretos para que ele seja reconhecido.
    • 




  • Uso do CBO: Qualquer hint (exceto o RULE) instrui o Oracle a usar o Cost Based Optimizer. Se a sintaxe do hint estiver incorreta, ele é simplesmente ignorado.
    • 






A





AND_EQUAL





    

  • Função: Força o otimizador a fazer um “merge scan” de vários índices de coluna única.
    • 




  • Sintaxe: AND_EQUAL(tabela índice1 índice2 ...)
    • 




  • Status: Depreciado no Oracle 10g e versões posteriores.
    • 






APPEND





    

  • Função: Em instruções INSERT, faz uma inserção em direct path, ignorando espaço livre no bloco. Pode reduzir o volume de redo gerado quando a tabela está em modo NOLOGGING.
    • 




  • Sintaxe: INSERT /*+ APPEND */ INTO tabela ...
    • 




  • Observação: Exige que a tabela não seja indexada de forma a impedir o uso de bulk inserts, e que não haja triggers ou constraints que impeçam direct path load.
    • 




  • Status: Suportado em várias versões. Continua válido.
    • 






APPEND_VALUES





    

  • Função: Similar ao APPEND, mas para instruções INSERT ... VALUES, introduzido em versões mais recentes (por volta do Oracle 12c+).
    • 




  • Sintaxe: INSERT /*+ APPEND_VALUES */ INTO tabela VALUES (...)
    • 




  • Observação: Otimiza a inserção de linhas únicas em modo de direct path. Útil quando não se está usando INSERT SELECT.
    • 






ALL_ROWS





    

  • Função: Otimiza a consulta para melhor throughput (menor consumo total de recursos).
    • 




  • Sintaxe: SELECT /*+ ALL_ROWS */ ...
    • 




  • Status: Válido e muito comum.
    • 






B





BITMAP





    

  • Função: Força o uso de um índice Bitmap para acessar a tabela.
    • 




  • Sintaxe: BITMAP(tabela índice_bitmap)
    • 




  • Status: Em algumas versões é considerado obsoleto ou pouco suportado, pois a detecção automática de bitmap normalmente funciona bem.
    • 






C





CACHE / NOCACHE





    

  • Função: Controla como os blocos lidos são colocados no Buffer Cache em caso de full table scan.
    • 




  • Sintaxe: CACHE(tabela) / NOCACHE(tabela)
    • 






CHOOSE





    

  • Função: Permite ao otimizador escolher entre rule-based e cost-based baseado na presença de estatísticas.
    • 




  • Sintaxe: SELECT /*+ CHOOSE */ ...
    • 




  • Status: Muito antigo, raramente usado hoje. A partir do 10g, o Oracle praticamente só usa CBO.
    • 






CLUSTER





    

  • Função: Força um cluster scan para a tabela.
    • 




  • Sintaxe: CLUSTER(tabela)
    • 






CURSOR_SHARING_EXACT





    

  • Função: Desativa a substituição de literais por binds, mesmo que CURSOR_SHARING esteja habilitado no banco.
    • 




  • Sintaxe: SELECT /*+ CURSOR_SHARING_EXACT */ ...
    • 






CARDINALITY





    

  • Função: Informa ao otimizador uma estimativa do número de linhas esperadas da tabela ou subquery.
    • 




  • Sintaxe: CARDINALITY(tabela ou subquery, linhas)
    • 




  • Observação: Pode ser útil quando as estatísticas não representam corretamente o volume real de dados.
    • 






D





DISTRIBUTE / DISTRIBUTE_JOIN





    

  • Função: Força a distribuição específica no join paralelo, semelhante ao PQ_DISTRIBUTE, mas usado principalmente em ambientes Exadata ou ambientes paralelos sofisticados.
    • 




  • Sintaxe: DISTRIBUTE_JOIN(tabela, método)
    • 




  • Observação: Os métodos mais comuns são BROADCAST, PARTITION, NONE.
    • 






DRIVING_SITE





    

  • Função: Em ambientes distribuídos, força a execução remota de parte da query em um site específico.
    • 




  • Sintaxe: SELECT /*+ DRIVING_SITE(tabela_ou_alias) */ ...
    • 






DYNAMIC_SAMPLING





    

  • Função: Controla a coleta de estatísticas dinâmicas em tempo de compilação para melhorar estimativas de seletividade.
    • 




  • Sintaxe: DYNAMIC_SAMPLING(nível) ou DYNAMIC_SAMPLING(tabela, nível)
    • 




  • Valores: De 0 a 11. Quanto maior, mais esforço (e potencial custo de compilação) para coletar estatísticas. (11 não é documentado , mas ele trabalha como AUTO, legal né? mas trabalha mal.)
    • 






E





EXPAND_GSET_TO_UNION





    

  • Função: Força a expansão de conjuntos (GROUPING SETS) para instruções UNION ALL.
    • 




  • Status: Depreciado no Oracle 10g.
    • 






F





FACT / NO_FACT





    

  • Função: Em star transformations, indica se a tabela é ou não considerada fact table.
    • 




  • Sintaxe: FACT(tabela) / NO_FACT(tabela)
    • 






FIRST_ROWS(n)





    

  • Função: Otimiza para resposta rápida dos primeiros n registros.
    • 




  • Sintaxe: SELECT /*+ FIRST_ROWS(10) */ ...
    • 






FULL





    

  • Função: Força um full table scan na tabela especificada.
    • 




  • Sintaxe: FULL(tabela)
    • 






G





GATHER_PLAN_STATISTICS





    

  • Função: Faz o Oracle coletar estatísticas detalhadas de execução para aquela query, que podem ser visualizadas com DBMS_XPLAN.DISPLAY_CURSOR.
    • 




  • Sintaxe: SELECT /*+ GATHER_PLAN_STATISTICS */ ...
    • 






H





HASH





    

  • Função: Força hash scan (normalmente para tabelas em clusters hash).
    • 




  • Sintaxe: HASH(tabela)
    • 






HASH_AJ





    

  • Função: Transforma subconsulta NOT IN em hash anti-join.
    • 




  • Sintaxe: HASH_AJ(tabela)
    • 




  • Status: Depreciado no 10g.
    • 






HASH_SJ





    

  • Função: Força hash semi-join ou hash anti-join.
    • 




  • Sintaxe: HASH_SJ(tabela)
    • 




  • Status: Antigo e pouco utilizado em versões modernas.
    • 






I





INDEX





    

  • Função: Força o uso de um índice específico ou conjunto de índices.
    • 




  • Sintaxe: INDEX(tabela índice) ou INDEX(tabela índice1 índice2 ...)
    • 






INDEX_ASC / INDEX_DESC





    

  • Função: Força index range scan em ordem ascendente ou descendente.
    • 




  • Sintaxe: INDEX_ASC(tabela índice) / INDEX_DESC(tabela índice)
    • 






INDEX_COMBINE





    

  • Função: Força o otimizador a usar uma combinação de índices Bitmap.
    • 




  • Sintaxe: INDEX_COMBINE(tabela índice1 índice2 ...)
    • 






INDEX_FFS





    

  • Função: Força fast full index scan, em vez de full table scan.
    • 




  • Sintaxe: INDEX_FFS(tabela índice)
    • 






INDEX_JOIN





    

  • Função: Força o index join de várias combinações de índices para cobrir todas as colunas necessárias.
    • 




  • Sintaxe: INDEX_JOIN(tabela índice1 índice2 ...)
    • 






INDEX_SS / INDEX_SS_ASC / INDEX_SS_DESC





    

  • Função: Força (ou impede) o index skip scan em ordem ascendente/descendente.
    • 




  • Status: Oracle 10g+.
    • 




  • Sintaxe: INDEX_SS(tabela índice), INDEX_SS_ASC(tabela índice), INDEX_SS_DESC(tabela índice)
    • 






NO_INDEX / NO_INDEX_FFS / NO_INDEX_SS





    

  • Função: Desabilitam uso de índice em geral, fast full index scan ou skip scan, respectivamente.
    • 




  • Sintaxe: NO_INDEX(tabela índice), NO_INDEX_FFS(tabela), NO_INDEX_SS(tabela índice)
    • 






INVISIBLE (NO_USE_INVISIBLE_INDEXES / USE_INVISIBLE_INDEXES)





    

  • Função: Controla se o Otimizador pode ou não considerar índices marcados como invisíveis.
    • 




  • Sintaxe: USE_INVISIBLE_INDEXES / NO_USE_INVISIBLE_INDEXES
    • 




  • Status: Disponível a partir do Oracle 11g R2+ (quando índices invisíveis foram introduzidos).
    • 






L





LEADING





    

  • Função: Define a tabela ou a sequência de tabelas que o Oracle deve usar primeiro em joins.
    • 




  • Sintaxe: LEADING(t1 t2 t3 ...)
    • 






M





MERGE





    

  • Função: Força a fusão de views no plano de execução.
    • 




  • Sintaxe: MERGE(tabela/view)
    • 






MERGE_AJ





    

  • Função: Transforma subconsulta NOT IN em merge anti-join.
    • 




  • Status: Depreciado no 10g.
    • 






MONITOR / NO_MONITOR





    

  • Função: Ativa ou desativa o monitoramento de query em tempo de execução (para V$SQL_MONITOR).
    • 




  • Sintaxe: SELECT /*+ MONITOR */ ... ou SELECT /*+ NO_MONITOR */ ...
    • 




  • Status: Introduzido no Oracle 11g para melhor monitoramento de SQL em tempo real.
    • 






N





NL_AJ / NL_SJ





    

  • Função: Forçam nested loop anti-join ou nested loop semi-join.
    • 




  • Status: Obsoletos em algumas versões.
    • 






NO_EXPAND





    

  • Função: Impede a expansão de consultas com OR ou IN-lists em UNION ALL.
    • 




  • Sintaxe: SELECT /*+ NO_EXPAND */ ...
    • 






NO_MERGE





    

  • Função: Impede a fusão de views.
    • 




  • Sintaxe: NO_MERGE(tabela/view)
    • 






NO_PARALLEL / NOPARALLEL





    

  • Função: Desativa a execução paralela, mesmo que a tabela tenha atributo PARALLEL.
    • 




  • Sintaxe: NO_PARALLEL(tabela)
    • 






NO_PARALLEL_INDEX





    

  • Função: Evita parallel index scan.
    • 




  • Sintaxe: NO_PARALLEL_INDEX(tabela índice)
    • 






NO_PUSH_PRED / NO_PUSH_SUBQ





    

  • Função: Impede que predicados ou subconsultas sejam “empurrados” para etapas anteriores do plano de execução.
    • 




  • Sintaxe: NO_PUSH_PRED, NO_PUSH_SUBQ
    • 






NO_QUERY_TRANSFORMATION





    

  • Função: Desabilita transformações internas de consulta (por exemplo, unnesting, etc.).
    • 




  • Sintaxe: NO_QUERY_TRANSFORMATION
    • 






NO_REWRITE / NOREWRITE





    

  • Função: Desabilita o uso de materialized views para reescrever a query.
    • 




  • Sintaxe: NO_REWRITE (renomeado a partir de NOREWRITE no 10g)
    • 






NO_STAR_TRANSFORMATION





    

  • Função: Impede que o otimizador faça a transformação star.
    • 




  • Sintaxe: NO_STAR_TRANSFORMATION
    • 






NO_USE_HASH / NO_USE_MERGE / NO_USE_NL





    

  • Função: Forçam o otimizador a não usar hash join, merge join ou nested loops.
    • 




  • Sintaxe: NO_USE_HASH(tabela), NO_USE_MERGE(tabela), NO_USE_NL(tabela)
    • 






NOCACHE





    

  • Ver CACHE / NOCACHE.
    • 






NOAPPEND





    

  • Função: Desabilita inserção via direct path, mesmo se APPEND estiver setado como default.
    • 




  • Sintaxe: NOAPPEND
    • 






O





OPT_PARAM





    

  • Função: Altera parâmetros de otimização apenas para aquela query (como se fosse um session-level hint).
    • 




  • Exemplo: SELECT /*+ OPT_PARAM('_optimizer_cost_based_transformation' 'off') */ ...
    • 




  • Status: Útil para tunar consultas sem alterar parâmetros de todo o banco.
    • 






ORDERED





    

  • Função: Faz o Oracle fazer joins na ordem em que as tabelas aparecem no FROM.
    • 




  • Sintaxe: ORDERED
    • 






ORDERED_PREDICATES





    

  • Função: Solicita que o Oracle avalie os predicados na ordem que aparecem na cláusula WHERE.
    • 




  • Status: Depreciado no 10g.
    • 






P





PARALLEL





    

  • Função: Ativa a execução paralela para a tabela especificada. Pode receber grau de paralelismo.
    • 




  • Sintaxe: PARALLEL(tabela, DOP) ou PARALLEL(tabela, DEFAULT)
    • 






PQ_DISTRIBUTE





    

  • Função: Controla a distribuição de linhas entre slaves no join paralelo.
    • 




  • Sintaxe: PQ_DISTRIBUTE(tabela, método_produtor, método_consumidor)
    • 






PUSH_PRED / PUSH_SUBQ





    

  • Função: Forçam o “empurrão” de predicados ou subconsultas para etapas anteriores do plano.
    • 




  • Sintaxe: PUSH_PRED, PUSH_SUBQ
    • 






Q





QB_NAME





    

  • Função: Nomeia um bloco de consulta (query block) para efeitos de análise e aplicação de outros hints.
    • 




  • Sintaxe: SELECT /*+ QB_NAME(meu_bloco) */ ...
    • 






R





REWRITE





    

  • Função: Força a reescrita da consulta usando materialized views disponíveis (independente do custo).
    • 




  • Sintaxe: REWRITE
    • 






RESULT_CACHE / NO_RESULT_CACHE





    

  • Função: Faz caching do resultado da query (ou impede caching) no Query Result Cache.
    • 




  • Sintaxe: SELECT /*+ RESULT_CACHE */ ... ou SELECT /*+ NO_RESULT_CACHE */ ...
    • 




  • Status: Disponível a partir do 11g para frente, se o result cache estiver habilitado.
    • 






ROWID





    

  • Função: Força acesso via ROWID na tabela especificada.
    • 




  • Sintaxe: ROWID(tabela)
    • 




  • Status: Depreciado no 10g.
    • 






RULE





    

  • Função: Força o uso do Rule-Based Optimizer. Ignora quaisquer outros hints.
    • 




  • Status: Obsoleto a partir do 10g (Oracle praticamente não usa mais RBO).
    • 






S





SPREAD_MIN_ANALYSIS





    

  • Função: Reduz algumas otimizações de planilha interna, focando em análises mínimas.
    • 




  • Status: Oracle 10g+.
    • 






STAR





    

  • Função: Força a tabela maior a ser joinada por último usando nested loops em índices.
    • 




  • Status: Depreciado no 10g.
    • 






STAR_TRANSFORMATION





    

  • Função: Permite o melhor plano gerado via transformação star.
    • 




  • Sintaxe: STAR_TRANSFORMATION
    • 






SWAP_JOIN_INPUTS





    

  • Função: Instrui o otimizador a inverter a ordem das tabelas no join, trocando o lado do driver e driven na operação de join
    • 




  • Sintaxe: SWAP_JOIN_INPUTS(tabela)
    • 




  • Observação: Pode melhorar o desempenho quando a ordem natural de join do otimizador não é a ideal.
    • 






SWAP_JOIN_INPUTS_AJ





    

  • Função: Similar ao SWAP_JOIN_INPUTS, mas aplicado para anti-joins. (subqueries transformadas em NOT EXISTS ou JOIN anti-join).
    • 




  • Sintaxe: SWAP_JOIN_INPUTS_AJ(tabela)
    • 






U





UNNEST / NO_UNNEST





    

  • Função: Controlam a “descompactação” (unnesting) de subconsultas, transformando-as em joins.
    • 




  • Sintaxe: UNNEST ou NO_UNNEST
    • 






USE_SEMI





    

  • Função: Força o otimizador a usar semi-joins (subqueries transformadas em EXISTS ou JOIN com filtragem).
    • 




  • Sintaxe: USE_SEMI(tabela)
    • 






USE_CONCAT





    

  • Função: Converte condições OR em um UNION ALL.
    • 




  • Sintaxe: SELECT /*+ USE_CONCAT */ ...
    • 






USE_ANTI





    

  • Função: Força o otimizador a usar anti-joins (subqueries transformadas em NOT EXISTS ou JOIN anti-join).
    • 




  • Sintaxe: USE_ANTI(tabela)
    • 






USE_HASH / USE_MERGE / USE_NL





    

  • Função: Forçam o uso de hash join, merge join ou nested loops para as tabelas especificadas.
    • 




  • Sintaxe: USE_HASH(tabela1 tabela2), USE_MERGE(tabela1 tabela2), USE_NL(tabela1 tabela2)
    • 











Dica sobre a Dica..










    

  1. Versão do Oracle: Alguns hints surgiram ou foram removidos em certas versões. Sempre verifique a documentação da sua versão específica (10g, 11g, 12c, 18c, 19c, 21c, etc.).
    2. 




  2. Sintaxe Exata: Um simples erro de ortografia (por exemplo, esquecer o “+” em /*+ ... */, escrever INDEXS em vez de INDEX) faz o Oracle ignorar completamente o hint.
    3. 




  3. Estatísticas Atualizadas: O Cost Based Optimizer (CBO) funciona melhor com estatísticas de tabelas e índices coerentes. Sem elas, mesmo os hints podem produzir resultados inconsistentes.
    4. 




  4. Ferramentas de Análise:

      

    • Use EXPLAIN PLAN e DBMS_XPLAN.DISPLAY (ou DBMS_XPLAN.DISPLAY_CURSOR) para verificar se o hint foi aplicado e qual foi o plano de execução.
      • 




    • Verifique também colunas como NOTE que podem indicar se houve “unrecognized hint” ou “hint ignored”.
      • 

    

    5. 




  5. Relevância:

      

    • Alguns hints (especialmente os marcados como dep. ou deprecated) podem não ter efeito.
      • 




    • Muitos hints antigos foram substituídos por melhorias automáticas no CBO nas versões recentes.
      • 

    

    6. 




  6. Testes A/B: Sempre compare o plano de execução com e sem o hint. Às vezes, o otimizador padrão pode ser melhor do que forçar um caminho específico.
    7. 




  7. Documentação Oficial: Consulte o capítulo “Hints” do Oracle Database SQL Tuning Guide para sua versão.
    8. 






Boa consulta e bons tunings!






]]>
					
					https://furushima.com.br/blog/como-usar-hint-no-oracle/feed/
			0
		
		
			
		
		Como Criar banco de dados oracle 19c em silent mode
		https://furushima.com.br/blog/como-criar-banco-de-dados-oracle-em-silent-mode-19c/
		
		
		Tue, 01 Apr 2025 09:46:12 +0000
				
		
		
		
		
		
		
		
		https://furushima.com.br/?p=2750

					
										Criando do banco de dados CDB single instance em Silent Mode





Após a instalação do software gerenciador de base de dados (SGBD), é necessário proceder à criação do banco de dados. Para isso, pode-se utilizar a ferramenta Database Configuration Assistant (DBCA), localizada no diretório $ORACLE_HOME/bin. Esta ferramenta permite a criação do banco de dados tanto em modo gráfico como em silent mode (modo texto), dependendo das necessidades e preferências do ambiente





1) Criação do response file





Para criação de um banco de dados utilizando Silent mode, por linha de comando, é necessário criar um arquivo de configuração passando os parâmetros de criação do banco de dados. Existe no caminho $ORACLE_HOME/assistants/dbca, um arquivo padrão chamado dbca.rsp para o preenchimento manual, porém, iremos criar o nosso próprio arquivo de configuração.





Acesse o servidor de banco de dados com o usuário oracle e crie um arquivo de configuração chamado create_db.rsp seguindo os passos abaixo:





Levando em consideração que as variáveis mencionadas a seguir, como ORACLE_BASE e ORACLE_HOME, são específicas para o meu ambiente, é importante destacar que estas podem variar em outros ambientes e devem ser ajustadas conforme necessário.





Além disso, é fundamental prestar atenção aos parâmetros de senha, como sysPassword, systemPassword e pdbAdminPassword. No exemplo apresentado, foi utilizada uma senha fraca, que deve ser substituída por uma senha mais robusta em ambientes produtivos, garantindo maior segurança.





Por fim, o nome do banco de dados container, configurado pelo parâmetro gdbName, está definido como orcl no exemplo. Este valor também pode ser alterado para atender às necessidades específicas do seu ambiente.





## Configurar variáveis de ambiente Oracle
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/db_home1

## criar arquivo de configuração
vi /u01/app/oracle/product/19.0.0/db_home1/assistants/dbca/db_create.rsp


## Copiar o conteúdo abaixo para dentro do arquivo de configuração db_create.rsp

responseFileVersion=/home/oracle/assistants/rspfmt_dbca_response_schema_v19.0.0
databaseConfigType=SI
gdbName=orcl
createAsContainerDatabase=true
pdbName=pdb1
useLocalUndoForPDBs=true
sysPassword=oracle
systemPassword=oracle
pdbAdminPassword=oracle
templateName=General_Purpose.dbc
storageType=FS
datafileDestination=/u01/app/oracle/oradata
characterSet=AL32UTF8
databaseType=OLTP
totalMemory=2048





Será criado um banco de dados container com um pdb, utilizando a configuração padrão, os datafiles, controlfiles e redo log files estarão localizados no caminho: /u01/app/oracle/oradata.





Se a criação do seu banco de dados for em diskgroup ASM, basta substituir os parametros relacionado ao storage diskGroupName e storageType conforme abaixo, por exemplo, diskgroup DATA.





storageType=ASM
diskGroupName=DATA





2) Criação do banco de dados





Após a configuração do reponse file, com o usuário oracle, execute a criação do banco de dados em modo Silent conforme abaixo:





## Acessar diretório ORACLE_HOME
cd $ORACLE_HOME

## Executar instalação em Silent Mode
dbca -silent -createDatabase -responseFile /u01/app/oracle/product/19.0.0/db_home1/assistants/dbca/db_create.rsp





No processo de criação poderá aparecer alguns alertas devido a complexidade das senhas, pode ignorar os alertas.










Criação do banco de dados finalizado










3) Validação do banco de dados





É possível validar no arquivo /etc/oratab as instâncias de banco de dados que estão registradas no servidor, podemos ver a nova instância que foi criada. 





cat /etc/oratab | grep orcl










Para acessar o banco de dados é necessário configurar as variáveis de ambiente, ORACLE_HOME e ORACLE_SID, para isso, executar os comandos abaixo.





## Configurar varíaveis de ambiente
. oraenv
orcl

## Acessar o banco de dados
sqlplus / as sysdba

## Verificar pluggables databases 
SQL> show pdbs

## Verificar estatus da instância
SQL> select instance_name,status from v$instance;





Configurar variáveis e acessar a instância orcl










Verificar status da instância











]]>
					
		
		
			
		
		Como Instalar Oracle Database 19c no Oracle Linux
		https://furushima.com.br/blog/instalar-oracle-database-19c-no-oracle-linux/
		
		
		Wed, 05 Mar 2025 18:24:55 +0000
				
		
		https://furushima.com.br/?p=2300

					
										Oracle Database 19c no Oracle Linux 7.9 em Silent Mode




Para instalação do Oracle Database 19c, é necessário que o sistema operacional seja preparado, nesse exemplo é utilizado o Oracle Linux 7.9, para mais informações, consulte o link oficial da oracle:





https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/oracle-database-installation-checklist.html#GUID-E847221C-1406-4B6D-8666-479DB6BDB046





1) Preparação do Oracle Linux 7.9 para o Oracle Database 19c





Antes de iniciar a instalação, o pacote oracle-database-preinstall-19c deve ser instalado para configurar automaticamente os pré-requisitos do sistema operacional. Esse pacote instala dependências necessárias e cria o usuário oracle e o grupo oinstall.





Execute o seguinte comando como ROOT:





$ yum install oracle-database-preinstall-19c.x86_64 -y





2) Como Descomprimir os Binários do Oracle Database 19c





Tendo acesso o servidor com o usuário oracle, descompactar o binário de instalação do Oracle Database 19c dentro do ficheiro da variável $ORACLE_HOME, que está configurada com o caminho: /u01/app/oracle/product/19.0.0/db_home1, conforme abaixo:










## COM USUARIO ORACLE OU OWNER DO BANCO DE DADOS 
### Configurar variáveis de ambiente 
export ORACLE_BASE=/u01/app/oracle 
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/db_home1 

### Mostrar conteúdo das variáveis 
echo $ORACLE_HOME
echo $ORACLE_BASE 

### Acessar e descompactar binários 

cd /u01/binarios 
unzip LINUX.X64_193000_db_home.zip -d $ORACLE_HOME 

### acessar o diretório dos binários descompactados 
cd $ORACLE_HOME










3) Criando o Response File para Instalação Silent do Oracle 19c





Criar um arquivo de configuração chamado db19_response.rsp, esse arquivo será utilizado como parâmetro para instalação dos binários, por default é disponibilizado um arquivo modelo em $ORACLE_HOME/install/response/, porém iremos criar o nosso, conforme abaixo:





Lembrando que deverá ser ajustado conforme cada ambiente, neste caso temos um Enterprise Edition sendo instalado!





### criar arquivo de configuração 
vi /u01/app/oracle/product/19.0.0/db_home1/install/response/db19_response.rsp 

### Copiar as informações abaixo para o arquivo criado db19_response.rsp 

oracle.install.responseFileVersion=/home/oracle/rspfmt_dbinstall_response_schema_v19.0.0 
oracle.install.option=INSTALL_DB_SWONLY 
UNIX_GROUP_NAME=oinstall 
INVENTORY_LOCATION=/u01/app/oracle/oraInventory
SELECTED_LANGUAGES=en,en_GB
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/19.0.0/db_home1
oracle.install.db.InstallEdition=EE
oracle.install.db.OSDBA_GROUP=oinstall
oracle.install.db.OSBACKUPDBA_GROUP=oinstall
oracle.install.db.OSDGDBA_GROUP=oinstall
oracle.install.db.OSKMDBA_GROUP=oinstall
oracle.install.db.OSRACDBA_GROUP=oinstall
oracle.install.db.rootconfig.executeRootScript=false 
oracle.install.db.rootconfig.configMethod=ROOT






4) Instalando o Oracle Database 19c em Silent Mode no Oracle Linux





Agora podemos iniciar a instalação do Oracle Database 19c no modo Silent Mode.





Execute o comando abaixo na mesma sessão como oracle:





### Acessar diretório ORACLE_HOME 

cd $ORACLE_HOME 
### Executar instalação em Silent Mode 

./runInstaller -silent -ignorePrereqFailure -responseFile /u01/app/oracle/product/19.0.0/db_home1/install/response/db19_response.rsp 





Finalizado a instalação, é necessário executar o script que se pede com usuário ROOT, para isso, abra outra sessão SSH e rode os comandos abaixo:










Neste sessão com o usuario ROOT, executar o script no sistema operacional, será necessário apertar a tecla ENTER 2 vezes










5) Como Validar a Instalação do Oracle Database 19c





Validar a instalação do Oracle Database no servidor mostrando a conteúdo do OraInventory. Dessa maneira é possível confirmar que há uma instalação do Oracle Database no servidor.





### Verificar instalações 
cat /u01/app/oracle/oraInventory/ContentsXML/inventory.xml | grep -i OraDB19















Conclusão





Seguindo esses passos, você terá o Oracle Database 19c instalado no Oracle Linux 7.9 utilizando o modo Silent. Se precisar configurar um banco de dados a partir dessa instalação, será necessário executar o dbca ou configurar manualmente os arquivos de inicialização.






]]>
					
		
		
			
		
		Entendendo o Plano de Execução no Oracle: Como Melhorar a Performance das Suas Consultas SQL – PARTE 1
		https://furushima.com.br/blog/entendendo-o-plano-de-execucao-no-oracle-como-melhorar-a-performance-das-suas-consultas-sql-parte-1/
		
		
		Fri, 21 Feb 2025 19:08:00 +0000
				
		
		
		https://furushima.com.br/?p=2536

					
										





O Poder do SQL e o Desafio da Performance





Uma das grandes vantagens do SQL é sua natureza declarativa. Isso significa que você não precisa dizer ao banco de dados como obter os dados; basta especificar o que deseja. O otimizador do Oracle (CBO) cuida de encontrar a melhor forma de executar sua consulta.





No entanto, nem sempre o caminho escolhido pelo banco de dados é o mais eficiente. Em consultas complexas ou com grandes volumes de dados, a performance pode ser impactada. Mas como identificar e corrigir esses problemas?





A resposta está no plano de execução.










O Que é um Plano de Execução?





O Execution Plan (Plano de Execução) é um roteiro detalhado que descreve o caminho que o Oracle seguirá para recuperar os dados solicitados em uma consulta SQL. Esse plano é gerado durante a fase de análise (parser) da instrução SQL.
Para construir esse caminho de execução, o Oracle considera diversas informações, entre elas:





    

  • Estatísticas do banco de dados: Incluem system statistics (estatísticas do sistema) e data statistics (estatísticas dos dados), que ajudam a prever a melhor forma de acessar as tabelas e índices.
    • 






    

  • Parâmetros da instância do banco de dados: Configurações específicas da instância que influenciam as decisões do otimizador.
    • 











Esses fatores fornecem insumos para o CBO (Cost-Based Optimizer), o otimizador do Oracle, que calcula a estratégia mais eficiente para executar a consulta SQL. Dessa forma, o plano de execução representa a melhor estimativa do banco de dados sobre como recuperar as informações da maneira mais rápida e eficiente possível.





Diferença entre Execution Plan e Explain Plan





EXPLAIN PLAN (Planos de Explicação) e EXECUTION PLAN (Plano de execução): Qual a Diferença?





Ao trabalhar com consultas SQL no Oracle, é essencial entender a diferença entre dois tipos de planos: EXPLAIN PLAN e EXECUTION PLAN.





Explain Plan (Planos de Explicação)





O EXPLAIN PLAN é uma previsão do que o Oracle planeja fazer para executar a consulta. Quando você roda um EXPLAIN PLAN, o banco de dados gera um plano estimado de execução, com base nas estatísticas atuais das tabelas e nos algoritmos do otimizador. Isso pode ser útil para entender a estratégia escolhida pelo otimizador antes de realmente executar a consulta.





No entanto, o EXPLAIN PLAN pode estar errado ou ser diferente do plano real de execução, porque:





Ele não executa a consulta de fato, apenas faz uma previsão.





Se as estatísticas do banco de dados estiverem desatualizadas, a previsão pode ser imprecisa.











EXPLAIN PLAN FOR 
SELECT * FROM TABELA_XPTO WHERE coluna = 'valor';

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);











Execution Plan (Plano de execução)





O EXECUTION PLAN, por outro lado, mostra o que realmente aconteceu quando a consulta foi executada. Ele exibe:





A sequência exata de operações realizadas pelo banco de dados.
O tempo gasto em cada operação.
O número real de linhas processadas.
O impacto da E/S (leitura e escrita em disco ou memória).
Se a consulta utilizou índices, joins, ordenações ou full table scans.





SELECT * FROM TABLE(dbms_xplan.display_cursor('<SQL_ID>','<CHILD_NUMBER>','ALLSTATS LAST  +PEEKED_BINDS +PREDICATE +COST +BYTES ADVANCED'));











Ao analisar a rota seguida pelo banco de dados, você pode identificar se ele escolheu o caminho mais eficiente ou se há uma alternativa ainda mais rápida, como a criação de um atalho.





Abaixo está o plano de execução para a junção de duas tabelas:





--------------------------------------
| Id  | Operation          | Name    |
--------------------------------------
|   0 | SELECT STATEMENT   |         |
|   1 |  HASH JOIN         |         |
|   2 |   TABLE ACCESS FULL| TAB_A   |
|   3 |   TABLE ACCESS FULL| TAB_B   |
--------------------------------------


Cada linha no Execution Plan (Plano de Execução) representa uma operação distinta. Essas operações estão organizadas em uma estrutura hierárquica, formando um relacionamento de pai/filho.

O plano pode ser visualizado como uma árvore. A instrução SELECT, localizada no topo, é a raiz; as tabelas, situadas na parte inferior, são as folhas; e, entre elas, há uma série de operações intermediárias.

Essas operações se dividem em três categorias principais:

- Single-child operations (Operações de filho único)
- Multichild operations (Operações de múltiplos filhos)
- Joins (Junções)










Single-child operations (Operações de filho único)





Como o nome sugere, esse tipo de operação sempre possui exatamente uma operação abaixo dela na árvore do plano de execução. Exemplos comuns incluem:





    

  • Grouping (Agrupamento)
    • 




  • Sorting (Ordenação)
    • 











Multichild operations (Operações de múltiplos filhos)





Essas operações podem ter uma ou mais operações abaixo delas e são mais raras. A mais comum que pode aparecer no plano de execução é a operação UNION (ALL), que combina os resultados de múltiplas consultas.










Joins (Junções)





As junções sempre possuem exatamente dois filhos. Esses filhos podem ser:





    

  • Outras junções
    • 




  • Tabelas
    • 




  • Qualquer outra operação do plano de execução
    • 






Cada um desses componentes desempenha um papel essencial na forma como o banco de dados processa a consulta, influenciando diretamente a eficiência e o desempenho da execução.





Como Ler ou Interpretar um Execution Plan (Plano de Execução)





Em um Execution Plan (Plano de Execução) baseado em texto, a estrutura hierárquica das operações é representada pelo nível de recuo (indentação). Esse recuo indica o relacionamento pai/filho entre as operações.





    

  • Operação pai: É sempre a primeira linha acima de uma operação, com um recuo menor.
    • 




  • Operações filhas: São as linhas logo abaixo da operação pai, recuadas mais para a direita. Elas pertencem à operação pai até que outra linha com o mesmo nível de recuo apareça.
    • 











Essa estrutura ajuda a visualizar como as operações se relacionam e a entender a ordem em que o banco de dados executa cada etapa da consulta.










Para ilustrar a estrutura hierárquica de um Execution Plan (Plano de Execução) no Oracle, vamos analisar um exemplo prático. Suponha que temos duas tabelas: clientes e pedidos. Desejamos selecionar todos os clientes e seus respectivos pedidos. A consulta SQL seria:






SELECT c.nome, p.numero_pedido
FROM clientes c
JOIN pedidos p ON c.cliente_id = p.cliente_id;






Ao gerar o plano de execução para essa consulta, obteríamos uma saída semelhante a:





--------------------------------------------------------------------------------
| Id  | Operation           | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |         |   100 |  5200 |    10   (0)| 00:00:01 |
|*  1 |  HASH JOIN          |         |   100 |  5200 |    10   (0)| 00:00:01 |
|   2 |   TABLE ACCESS FULL | CLIENTES|   100 |  2600 |     5   (0)| 00:00:01 |
|   3 |   TABLE ACCESS FULL | PEDIDOS |   200 |  5200 |     5   (0)| 00:00:01 |
--------------------------------------------------------------------------------

Vamos interpretar esse plano de execução, destacando as relações pai/filho:

Operação Raiz (Pai Principal):

Id 0: SELECT STATEMENT é a operação raiz. Todas as outras operações são suas filhas diretas ou indiretas.

Operação Filha da Raiz:

Id 1: HASH JOIN é filha direta do SELECT STATEMENT. Esta operação combina as tabelas CLIENTES e PEDIDOS usando um algoritmo de junção hash.
Operações Filhas do HASH JOIN:

Id 2: TABLE ACCESS FULL na tabela CLIENTES. Esta operação lê toda a tabela CLIENTES e fornece os dados para o HASH JOIN.

Id 3: TABLE ACCESS FULL na tabela PEDIDOS. Similarmente, lê toda a tabela PEDIDOS e passa os dados para o HASH JOIN.

Observações Importantes:
Recuo (Indentação): No plano de execução baseado em texto, o nível de recuo indica a hierarquia das operações. Operações com maior recuo são filhas da operação imediatamente acima com menor recuo.

Relação Pai/Filho:

SELECT STATEMENT é o pai do HASH JOIN.
HASH JOIN é pai das operações TABLE ACCESS FULL das tabelas CLIENTES e PEDIDOS.

Entender essa estrutura hierárquica é crucial para analisar como o Oracle executa a consulta e identificar possíveis otimizações, como a criação de índices ou a reescrita da consulta para melhorar o desempenho.











Passo a Passo do Execution Plan





1 – Primeira operação (Seta Vermelha) – Busca inicial das tabelas COLOURS e TOYS





    

  • A execução começa buscando os dados da tabela COLOURS (TABLE ACCESS FULL, linha 4).
    • 




  • Em seguida, os dados da tabela TOYS são buscados (TABLE ACCESS FULL, linha 5).
    • 




  • Esses dados são passados para o primeiro HASH JOIN (linha 3), que combina os resultados dessas tabelas.
    • 






    




    




    2 – Segunda operação (Seta Roxa) – Adicionando a tabela PENS
    




      

    • Após a junção das tabelas COLOURS e TOYS, o banco acessa a tabela PENS (TABLE ACCESS FULL, linha 6).
      • 




    • O resultado do primeiro HASH JOIN é combinado com os dados da tabela PENS através de outro HASH JOIN (linha 2).
      • 




    • Neste ponto, temos um novo dataset contendo os dados já filtrados e processados.
      • 

    




      




      




      3 – Terceira operação (Seta Laranja) – Busca na tabela BRICKS
      




        

      • O próximo passo é buscar os dados da tabela BRICKS (TABLE ACCESS FULL, linha 7).
        • 




      • O resultado da junção anterior (dataset da etapa 2) é agora unido à tabela BRICKS por meio de um HASH JOIN (linha 1).
        • 

      




        




        




        4 – Última operação (Seta Verde) – Retorno do resultado
        




          

        • O HASH JOIN final combina todos os resultados e retorna os dados ao cliente através do SELECT STATEMENT (linha 0).
          • 




        • Como não há mais filhos na estrutura, essa etapa finaliza a execução.

          • 

        




          




          




          Resumo da Ordem de Execução
          




          A ordem correta de execução pode ser descrita assim:
          




            

          1. TABLE ACCESS FULL COLOURS (linha 4) → primeiro conjunto de dados.
            2. 




          2. TABLE ACCESS FULL TOYS (linha 5) → segundo conjunto de dados.
            3. 




          3. HASH JOIN (linha 3) → combinação de COLOURS e TOYS.
            4. 




          4. TABLE ACCESS FULL PENS (linha 6) → terceiro conjunto de dados.
            5. 




          5. HASH JOIN (linha 2) → combinação do resultado do primeiro HASH JOIN com PENS.
            6. 




          6. TABLE ACCESS FULL BRICKS (linha 7) → quarto conjunto de dados.
            7. 




          7. HASH JOIN (linha 1) → combinação do resultado da segunda junção com BRICKS.
            8. 




          8. SELECT STATEMENT (linha 0) → retorna o resultado final ao cliente.
            9. 

          




          




          




          




          




          




          Compreender a estrutura e a ordem de execução de um plano de execução é essencial para diagnosticar e otimizar o desempenho de consultas no Oracle Database. Ao analisar detalhadamente cada operação e suas interações, é possível identificar gargalos e aplicar melhorias específicas, resultando em consultas mais eficientes e sistemas mais responsivos.
          




          




          Referencias : 
          https://blogs.oracle.com/connect/post/how-to-read-an-execution-plan
          




          




          




          
]]>          
					
		
		
			          
		
		[SCRIPT] – showplan.sql
		https://furushima.com.br/blog/script-showplan-sql-2/
		
		
		Wed, 29 Jan 2025 16:58:22 +0000
				
		
		
		https://furushima.com.br/?p=2337

					
										
          




          Utilidade do script showplan.sql
          




            

          1. Identificar a parte específica do plano de execução que está causando gargalos em um determinado SQL_ID.
            2. 




          2. Analisar os eventos de espera principais associados a um SQL_ID específico para identificar possíveis ineficiências.
            3. 




          3. Avaliar quais objetos no Oracle demandam maior tempo de processamento para um determinado SQL_ID.
            4. 

          




          




          




          




          




          -- ################################################################################
-- #
-- #          name: showplan.sql v1.0
-- #
-- #          File: showplan.sql
-- #   Description: Show SQL Plan and performance details
-- #         Usage: @showplan <SQL_ID> [Plan Hash Value] [Details: [+](B)inds|SQL (T)ext|(Pee(K)ed Binds|(P)lan|(O)utlines|Pre(D)icate|Plan (L)oading|(W)ait events|(S)tatistics]
-- #       Created: 2014-03-12
-- #        Author: Wei Huang
-- #      Web Site: www.HelloDBA.com
-- #Latest Version: http://www.HelloDBA.com/download/showplan.zip
-- #   User run as: dba
-- #     Tested DB: 11gR2
-- #    Parameters: 1: SQL_ID of SQL to be shown
-- #    Parameters: 2: Plan Hash Value, if null (Default), will show all plans
-- #    Parameters: 3: Details to be shown: [+](B)inds|SQL (T)ext|(Pee(K)ed Binds|(P)lan|(O)utlines|Pre(D)icate|Plan (L)oading|(W)ait events|(S)tatistics, 
-- #                   default is BPDTLWS; + stand for the default options
-- #
-- #  Copyright (c) 2014 Wei Huang
-- #
-- # History
-- # Modified by   When      Why
-- # -----------   -------   ----------------------------------------------------
-- ################################################################################
set autot off verify off feedback off pagesize 50000 lines 2000 long 10000000 longchunksize 10000000 serveroutput on size unlimited format wrapped buffer 99999999 head off
set termout off
col p1 noprint
col p2 new_value 2 noprint
col p3 new_value 3 noprint
select null p2, null p3 from dual where 1=2;
select nvl(upper(decode(upper('&2'),'NULL',null,upper('&2'))),null) p2, nvl(upper(decode(upper('&3'),'NULL','BPDTLWS',upper('&3'))),'BPDTLWS')||decode(instr('&3','+'),0,'','BPDTLWS') p3 from dual;
set termout on
clear columns
col xxx format a2000

prompt Usage: @showplan <SQL_ID> [Plan Hash Value] [Details: [+](B)inds|SQL (T)ext|(Pee(K)ed Binds|(P)lan|(O)utlines|Pre(D)icate|Plan (L)oading|(W)ait events|(S)tatistics]
prompt Description: Show SQL Plan
prompt 

set termout off
var sqlid varchar2(32);
var planHashValue varchar2(32);
var showOptions varchar2(32);
begin select '&1', decode(upper('&2'),'NULL',null,'&2'), nvl(upper(decode(upper('&3'),'NULL','BPDTLWS',upper('&3'))),'BPDTLWS')||decode(instr('&3','+'),0,'','BPDTLWS') into :sqlid, :planHashValue, :showOptions from dual; end;
/
set termout on

with q as (select /*+materialize*/*
           from (select sql_fulltext from v$sqlarea where sql_id=:sqlid
                 union all
                 select sql_text from dba_hist_sqltext
                 where sql_id=:sqlid and not exists (select 1 from v$sqlarea where sql_id=:sqlid))),
     p as (select /*+materialize*/*
           from (select m.SQL_ID,SQL_PLAN_HASH_VALUE PLAN_HASH_VALUE,PLAN_LINE_ID ID,PLAN_PARENT_ID PARENT_ID,
                        PLAN_OPERATION OPERATION,p.OTHER_TAG,PLAN_OPTIONS OPTIONS,PLAN_OBJECT_NAME OBJECT_NAME,
                        PLAN_OBJECT_TYPE OBJECT_TYPE,p.OPTIMIZER,PLAN_COST COST,OUTPUT_ROWS||' rows' CARDINALITY,
                        PHYSICAL_READ_BYTES+PHYSICAL_WRITE_BYTES||'/'||PLAN_BYTES BYTES,
                        p.access_predicates, p.filter_predicates, p.parsing_schema_name
                 from v$sql_plan_monitor m, (select p.SQL_ID, p.PLAN_HASH_VALUE, p.ID, p.CHILD_ADDRESS, p.OTHER_TAG, 
                                                    p.OPTIMIZER, p.access_predicates, p.filter_predicates, q.parsing_schema_name 
                                             from v$sql_plan p, v$sql q
                                             where p.SQL_ID=:sqlid AND (:planHashValue is NULL or p.PLAN_HASH_VALUE=to_number(:planHashValue))
                                             and p.sql_id=q.sql_id(+) and p.CHILD_ADDRESS=q.CHILD_ADDRESS(+)
                                             union
                                             select p.SQL_ID, p.PLAN_HASH_VALUE, ID, null CHILD_ADDRESS, p.OTHER_TAG, 
                                                    p.OPTIMIZER, access_predicates, p.filter_predicates, q.parsing_schema_name 
                                             from dba_hist_sql_plan p, dba_hist_sqlstat q
                                             where p.SQL_ID=:sqlid AND (:planHashValue is NULL or p.PLAN_HASH_VALUE=to_number(:planHashValue))
                                             and p.sql_id=q.sql_id(+) and p.PLAN_HASH_VALUE=q.PLAN_HASH_VALUE(+)
                                             and not exists (select 1 from V$SQL_PLAN p1 
                                                             where p1.SQL_ID=:sqlid AND (:planHashValue is NULL or p1.PLAN_HASH_VALUE=to_number(:planHashValue)))) p
                 where m.SQL_ID=:sqlid AND (:planHashValue is NULL or m.SQL_PLAN_HASH_VALUE=to_number(:planHashValue))
                   and last_refresh_time = (select max(last_refresh_time) from v$sql_plan_monitor m
                                             where m.SQL_ID=:sqlid AND (:planHashValue is NULL or m.SQL_PLAN_HASH_VALUE=to_number(:planHashValue)))
                   and m.SQL_ID=p.SQL_ID(+) and m.SQL_PLAN_HASH_VALUE=p.PLAN_HASH_VALUE(+) and m.PLAN_LINE_ID=p.ID(+) and m.SQL_CHILD_ADDRESS=p.CHILD_ADDRESS(+)
                 union
                 select p.SQL_ID,p.PLAN_HASH_VALUE, p.ID, p.PARENT_ID,p.OPERATION,p.OTHER_TAG,p.OPTIONS,p.OBJECT_NAME,
                        p.OBJECT_TYPE, p.OPTIMIZER,p.COST,''||p.CARDINALITY CARDINALITY,''||p.BYTES BYTES,
                        p.access_predicates, p.filter_predicates, q.parsing_schema_name
                 from V$SQL_PLAN p, v$sql q
                 where p.SQL_ID=:sqlid AND (:planHashValue is NULL or p.PLAN_HASH_VALUE=to_number(:planHashValue))
                 and p.child_number = (select max(child_number) from V$SQL_PLAN p1
                                       where p1.SQL_ID=:sqlid AND (:planHashValue is NULL or p1.PLAN_HASH_VALUE=to_number(:planHashValue)))
                 and not exists (select 1 from v$sql_plan_monitor m
                                  where m.SQL_ID=:sqlid AND (:planHashValue is NULL or m.SQL_PLAN_HASH_VALUE=to_number(:planHashValue)))
                 and p.sql_id=q.sql_id(+) and p.CHILD_ADDRESS=q.CHILD_ADDRESS(+)
                 union 
                 select p.SQL_ID,p.PLAN_HASH_VALUE, p.ID, p.PARENT_ID,p.OPERATION,p.OTHER_TAG,p.OPTIONS,p.OBJECT_NAME,
                        p.OBJECT_TYPE,p.OPTIMIZER,p.COST,''||p.CARDINALITY CARDINALITY,''||p.BYTES BYTES,
                        p.access_predicates, p.filter_predicates, q.parsing_schema_name
                 from dba_hist_sql_plan p, dba_hist_sqlstat q
                 where p.SQL_ID=:sqlid AND (:planHashValue is NULL or p.PLAN_HASH_VALUE=to_number(:planHashValue))
                 and timestamp = (select max(timestamp) from dba_hist_sql_plan p1
                                  where p1.SQL_ID=:sqlid AND (:planHashValue is NULL or p1.PLAN_HASH_VALUE=to_number(:planHashValue)))
                 and not exists (select 1 from v$sql_plan_monitor  m
                                  where m.SQL_ID=:sqlid AND (:planHashValue is NULL or m.SQL_PLAN_HASH_VALUE=to_number(:planHashValue)))
                 and not exists (select 1 from V$SQL_PLAN p1
                                  where p1.SQL_ID=:sqlid AND (:planHashValue is NULL or p1.PLAN_HASH_VALUE=to_number(:planHashValue)))
                 and p.sql_id=q.sql_id(+) and p.PLAN_HASH_VALUE=q.PLAN_HASH_VALUE(+))),
     pa as ( select /*+materialize*/sql_plan_hash_value plan_hash_value, sql_plan_line_id, 
                    sql_plan_operation||' '||nvl(sql_plan_options,'') sql_plan_op,nvl(event, 'ON CPU') event, 
                    TEMP_SPACE_ALLOCATED, PGA_ALLOCATED, current_obj#, count(*) over () total_waits
               from v$active_session_history 
              where sql_plan_line_id is not null and sql_id=:sqlid AND (:planHashValue is NULL or SQL_PLAN_HASH_VALUE=to_number(:planHashValue))
              union all
             select sql_plan_hash_value plan_hash_value, sql_plan_line_id, 
                    sql_plan_operation||' '||nvl(sql_plan_options,'') sql_plan_op,nvl(event, 'ON CPU') event, 
                    TEMP_SPACE_ALLOCATED, PGA_ALLOCATED, current_obj#, count(*) over () total_waits
               from dba_hist_active_sess_history 
              where not exists (select 1 from v$active_session_history 
                                 where sql_id=:sqlid AND (:planHashValue is NULL or SQL_PLAN_HASH_VALUE=to_number(:planHashValue)))
                and sql_plan_line_id is not null and sql_id=:sqlid AND (:planHashValue is NULL or SQL_PLAN_HASH_VALUE=to_number(:planHashValue))),
     pl as ( select plan_hash_value, sql_plan_line_id, sql_plan_op, total_waits, count(*) waits
               from pa
              group by plan_hash_value, sql_plan_line_id, sql_plan_op, total_waits),
     we as (select pa.plan_hash_value, pa.event, o.owner||'.'||o.object_name||'('||o.object_type||')' wait_object, 
                   count(*) waits, total_waits from pa, dba_objects o
             where pa.current_obj#=o.object_id
             group by pa.plan_hash_value, pa.event, o.owner, o.object_name, o.object_type, total_waits),
     pb as (select /*+inline*/plan_hash_value,b.name,b.value,
                  decode(b.type#, 
                       1, 'VARCHAR2('||b.maxlength||')',
                       2, decode(b.scale, null,
                                 decode(b.precision#, null, 'NUMBER', 'FLOAT'),
                                 'NUMBER'),
                       8, 'LONG',
                       9, 'VARCHAR('||b.maxlength||')',
                       12, 'DATE',
                       23, 'RAW', 24, 'LONG RAW',
                       69, 'ROWID',
                       96, 'CHAR('||b.maxlength||')',
                       100, 'BINARY_FLOAT',
                       101, 'BINARY_DOUBLE',
                       105, 'MLSLABEL',
                       106, 'MLSLABEL',
                       112, 'CLOB',
                       113, 'BLOB', 114, 'BFILE', 115, 'CFILE',
                       178, 'TIME(' ||b.scale|| ')',
                       179, 'TIME(' ||b.scale|| ')' || ' WITH TIME ZONE',
                       180, 'TIMESTAMP(' ||b.scale|| ')',
                       181, 'TIMESTAMP(' ||b.scale|| ')' || ' WITH TIME ZONE',
                       231, 'TIMESTAMP(' ||b.scale|| ')' || ' WITH LOCAL TIME ZONE',
                       182, 'INTERVAL YEAR(' ||b.precision#||') TO MONTH',
                       183, 'INTERVAL DAY(' ||b.precision#||') TO SECOND(' ||
                             b.scale || ')',
                       208, 'UROWID',
                       'UNDEFINED') data_type
              from v$sql_plan m, xmltable('/*/peeked_binds/bind' passing xmltype(m.OTHER_XML)
                                 columns name varchar2(4000) path '/bind/@nam', 
                                         type# varchar2(4000) path '/bind/@dty',
                                         precision# varchar2(4000) path '/bind/@pre',
                                         scale varchar2(4000) path '/bind/@scl',
                                         maxlength varchar2(4000) path '/bind/@mxl',
                                         value varchar2(4000) path '/bind') b
             where m.sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue))
               and trim(OTHER_XML) is not null),
     mb as (select /*+inline*/m.sid,m.session_serial#,sql_id,b.name,b.data_type,b.value
            from V$SQL_MONITOR m, xmltable('/binds/bind' passing xmltype(m.BINDS_XML)
                                           columns name varchar2(30) path '/bind/@name', 
                                                   data_type varchar2(30) path '/bind/@dtystr', 
                                                   value varchar2(4000) path '/bind') b
           where m.sql_id = :sqlid
             and exists (select 1 from V$SQL_MONITOR m1 
                          where m1.sid=m.sid and m1.session_serial#=m.session_serial# and m1.sql_id=m.sql_id
                           and (not exists (select 1 from v$sql_plan 
                                            where sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue)))
                                or exists (select 1 from v$sql_plan p 
                                           where sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue))
                                             and m1.sql_child_address=p.child_address))
                          group by sid,session_serial#,sql_id 
                         having max(m1.last_refresh_time)=m.last_refresh_time)
             and m.BINDS_XML is not null),
     ol as (select /*+inline*/plan_hash_value,b.hint
              from v$sql_plan m, xmltable('/*/outline_data/hint' passing xmltype(m.OTHER_XML)
                                 columns hint varchar2(4000) path '/hint') b
             where m.sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue))
               and trim(OTHER_XML) is not null),
     bc  as ( select distinct name,datatype,datatype_string,value_string from v$sql_bind_capture
               where sql_id = :sqlid
                 and last_captured = (select max(last_captured) from v$sql_bind_capture c 
                                       where sql_id = :sqlid
                                       and (not exists (select 1 from v$sql_plan 
                                                        where sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue)))
                                            or exists (select 1 from v$sql_plan p 
                                                       where sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue))
                                                         and c.child_address=p.child_address)))),
     bc1 as ( select distinct b.name,b.datatype,b.datatype_string,b.value_string,b.snap_id from dba_hist_sqlbind b, dba_hist_snapshot s
               where b.sql_id = :sqlid and b.snap_id=s.snap_id and b.instance_number=s.instance_number
                 and not exists (select 1 from bc)
                 and b.snap_id = (select max(c.snap_id) from dba_hist_sqlbind c
                                  where sql_id = :sqlid)),
     cb as (select /*+materialize*/* 
            from (select LISTAGG('var '||substr(name,2)||' '||decode(datatype_string,'VARCHAR2(4001)','CLOB',datatype_string)||';' ,chr(10)) WITHIN GROUP (ORDER BY name) var,
                         LISTAGG('exec '||name||':='||nvl2(value_string,decode(datatype,1,'''','')||value_string||decode(datatype,1,'''','')||';','null;'),chr(10)) WITHIN GROUP (ORDER BY name) exe
                  from bc
                  union all
                  select LISTAGG('var '||substr(name,2)||' '||decode(datatype_string,'VARCHAR2(4001)','CLOB',datatype_string)||';' ,chr(10)) WITHIN GROUP (ORDER BY name) var,
                         LISTAGG('exec '||name||':='||nvl2(value_string,decode(datatype,1,'''','')||value_string||decode(datatype,1,'''','')||';','null;'),chr(10)) WITHIN GROUP (ORDER BY name) exe
                  from bc1
                  group by snap_id)
          where (var is not null or exe is not null)),
     sd as (select PLAN_HASH_VALUE, '1,Loads: '||q.LOADS||'; 2,Load Versions: '||q.LOADED_VERSIONS||'; 3,First Load Time: '||q.FIRST_LOAD_TIME||'; 4,Last Load Time: '||q.LAST_LOAD_TIME||'; 5,User Openings: '||q.USERS_OPENING||'; 6,Parse Calls: '||q.PARSE_CALLS||'; 7,Executions: '||q.EXECUTIONS||'; 8,Sorts(Average): '||round(q.SORTS/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||'; 9,Fetches(Average): '||round(q.FETCHES/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||'; 10,Disk Reads(Average): '||round(q.DISK_READS/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||'; 11,Buffer Gets(Average): '||round(q.BUFFER_GETS/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||'; 12,Elapsed Time(Average): '||ROUND(q.ELAPSED_TIME/1000/1000/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||' seconds; 13,CPU Time(Average): '||ROUND(q.CPU_TIME/1000/1000/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||' seconds; 14,Run Time Memory(Average): '||ROUND(q.RUNTIME_MEM/1024/1024/decode(nvl(q.EXECUTIONS,0),0,1,q.EXECUTIONS),3)||'M' str, 
                   ';' spliter 
            from (select PLAN_HASH_VALUE, sum(LOADS) LOADS, min(FIRST_LOAD_TIME) FIRST_LOAD_TIME, max(LAST_LOAD_TIME) LAST_LOAD_TIME, 
                         sum(LOADED_VERSIONS) LOADED_VERSIONS, sum(USERS_OPENING) USERS_OPENING, sum(EXECUTIONS) EXECUTIONS, 
                         sum(PARSE_CALLS) PARSE_CALLS, sum(SORTS) SORTS, sum(FETCHES) FETCHES, sum(DISK_READS) DISK_READS, 
                         sum(BUFFER_GETS) BUFFER_GETS, max(RUNTIME_MEM) RUNTIME_MEM, sum(CPU_TIME) CPU_TIME, 
                         sum(ELAPSED_TIME) ELAPSED_TIME 
                  from v$sql
                  where sql_id=:sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue)) 
                  group by PLAN_HASH_VALUE
                  union
                  select PLAN_HASH_VALUE, max(LOADS_TOTAL) LOADS, null FIRST_LOAD_TIME, null LAST_LOAD_TIME, 
                         max(LOADED_VERSIONS) LOADED_VERSIONS, 0 USERS_OPENING, max(EXECUTIONS_TOTAL) EXECUTIONS, 
                         max(PARSE_CALLS_TOTAL) PARSE_CALLS, max(SORTS_TOTAL) SORTS, max(FETCHES_TOTAL) FETCHES, 
                         max(DISK_READS_TOTAL) DISK_READS, max(BUFFER_GETS_TOTAL) BUFFER_GETS, 0 RUNTIME_MEM, 
                         max(CPU_TIME_TOTAL) CPU_TIME, max(ELAPSED_TIME_TOTAL) ELAPSED_TIME 
                  from dba_hist_sqlstat
                  where sql_id=:sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue))
                  and not exists (select 1 from v$sqlarea where sql_id = :sqlid and (:planHashValue is NULL or PLAN_HASH_VALUE=to_number(:planHashValue)))
                  group by PLAN_HASH_VALUE) q
           where EXECUTIONS is not null and CPU_TIME is not null and ELAPSED_TIME is not null),
     ss as (select /*+materialize*/*
              from (select PLAN_HASH_VALUE, max(temp_size) temp_size, 0 pga_size 
                      from (select t.SESSION_ADDR,nvl(q.PLAN_HASH_VALUE,99999999999999) PLAN_HASH_VALUE, 
                                   nvl(sum(t.BLOCKS*to_number(p.value)/1024/1024/1024),0) temp_size
                              from v$sort_usage t, v$parameter p, v$session s, v$sql q 
                             where p.name = 'db_block_size' and t.sql_id=:sqlid 
                               and t.SESSION_ADDR=s.saddr(+) and t.sql_id=s.sql_id(+) 
                               and s.sql_id=q.sql_id(+) and s.sql_child_number=q.child_number(+)
                               and (:planHashValue is NULL or q.PLAN_HASH_VALUE is null or q.PLAN_HASH_VALUE=to_number(:planHashValue))
                             group by t.SESSION_ADDR,nvl(q.PLAN_HASH_VALUE,99999999999999))
                     group by PLAN_HASH_VALUE
                     union all
                    select nvl(q.PLAN_HASH_VALUE,99999999999999) PLAN_HASH_VALUE,0 temp_size, nvl(max(PGA_MAX_MEM/1024/1024/1024),0) pga_size 
                      from v$process p, v$session s, v$sql q 
                     where s.paddr=p.addr and s.sql_id = :sqlid
                       and s.sql_id=q.sql_id(+) and s.sql_child_number=q.child_number(+)
                       and (:planHashValue is NULL or q.PLAN_HASH_VALUE is null or q.PLAN_HASH_VALUE=to_number(:planHashValue))
                     group by nvl(q.PLAN_HASH_VALUE,99999999999999)
                     union all
                    select pa.PLAN_HASH_VALUE,nvl(max(TEMP_SPACE_ALLOCATED/1024/1024/1024),0) temp_size, 
                           nvl(max(PGA_ALLOCATED/1024/1024/1024),0) pga_size 
                      from pa
                     group by pa.PLAN_HASH_VALUE))
select /*+no_monitoring*/xxx
  from (
        select 0 PLAN_HASH_VALUE, 1 seq, 0 ID, 'SQL ID: '||:sqlid xxx from dual
        union
        select 0 PLAN_HASH_VALUE, 1 seq, 1 ID, chr(10)||'------------- Last Monitored Binds --------------' xxx from dual where exists (select 1 from mb) and instr(:showOptions,'B')>0
        union
        select 0 PLAN_HASH_VALUE, 2 seq, to_number(sid||'.'||session_serial#||'000001') ID, 
               '--SID: '||sid||','||session_serial#||chr(10)||LISTAGG('var '||substr(b.name,2)||' '||b.data_type,chr(10)) WITHIN GROUP (ORDER BY b.name) xxx 
        from mb b
        where instr(:showOptions,'B')>0
        GROUP BY sid,session_serial#,sql_id
        union 
        select 0 PLAN_HASH_VALUE, 2 seq, to_number(sid||'.'||session_serial#||'000002') ID, 
               '--SID: '||sid||','||session_serial#||chr(10)||LISTAGG('exec '||b.name||':='||decode(instr(b.data_type,'NUMBER'),0,''''||b.value||''';',b.value),chr(10)) WITHIN GROUP (ORDER BY b.name) xxx
        from mb b
        where instr(:showOptions,'B')>0
        GROUP BY sid,session_serial#,sql_id
        union 
        select 0 PLAN_HASH_VALUE, 3 seq, 1 ID, chr(10)||'------------- Last Captured Binds --------------' xxx from dual where exists (select 1 from cb) and instr(:showOptions,'B')>0 and not exists (select 1 from mb)
        union 
        select 0 PLAN_HASH_VALUE, 3 seq, 2 ID, var xxx from cb
        where instr(:showOptions,'B')>0 and not exists (select 1 from mb)
        union 
        select 0 PLAN_HASH_VALUE, 3 seq, 3 ID, exe xxx from cb
        where instr(:showOptions,'B')>0 and not exists (select 1 from mb)
        union
        select 0 PLAN_HASH_VALUE, 10 seq, 0 ID, chr(10)||'------------- SQL Text --------------' xxx from dual
        where instr(:showOptions,'T')>0
        union
        select *
        from (select /*+no_merge*/0 PLAN_HASH_VALUE, 11 seq, level ID, to_char(substr(sql_fulltext,(level-1)*2000+1,2000)) sql_text
              from q
              where instr(:showOptions,'T')>0
              connect by level<=ceil(length(sql_fulltext)/2000))
        UNION
        select distinct PLAN_HASH_VALUE, 30 seq, -1 ID, chr(10)||'------------- SQL Plan (Plan Hash Value:'||PLAN_HASH_VALUE||'; Parsed by schema:'||PARSING_SCHEMA_NAME||') --------------' xxx
        from p
        where instr(:showOptions,'P')>0
        UNION
        select *
        from (SELECT /*+no_merge*/PLAN_HASH_VALUE, 31 seq, ID,
               lpad(nvl2(access_predicates,'*','')||nvl2(filter_predicates,'#','')||ID,6,' ')||lpad('('||nvl(PARENT_ID||'',' ')||')',6,' ')||LPAD(' ',(LEVEL-1))||OPERATION||DECODE(OTHER_TAG,NULL,'','*')||DECODE(OPTIONS,NULL,'',' ('||OPTIONS||')')||DECODE(OBJECT_NAME,NULL,'',' OF '''||OBJECT_NAME||'''')||DECODE(OBJECT_TYPE,NULL,'',' ('||OBJECT_TYPE||')')||DECODE(ID,0,DECODE(OPTIMIZER,NULL,'',' Optimizer='||OPTIMIZER))||DECODE(COST,NULL,'',' (Cost='||COST||DECODE(CARDINALITY,NULL,'',' Card='||CARDINALITY)||DECODE(BYTES,NULL,'',' Bytes='||BYTES)||')') xxx --,OBJECT_NODE OBJECT_NODE_PLUS_EXP
              FROM P
              where instr(:showOptions,'P')>0
              START WITH ID=0
              CONNECT BY PRIOR ID=PARENT_ID AND PRIOR SQL_ID=SQL_ID AND PRIOR PLAN_HASH_VALUE=PLAN_HASH_VALUE)
        UNION
        select distinct PLAN_HASH_VALUE, 33 seq, 0 ID, chr(10)||'------------- Stored Outline (Plan Hash Value:'||PLAN_HASH_VALUE||') --------------' xxx
        from OL
        where instr(:showOptions,'O')>0
        UNION
        select PLAN_HASH_VALUE, 33 seq, 1 ID, '/*+' xxx from OL
        where instr(:showOptions,'O')>0
        UNION
        select PLAN_HASH_VALUE, 33 seq, 2 ID, lpad(' ',3,' ')||'BEGIN_OUTLINE_DATA' xxx from OL
        where instr(:showOptions,'O')>0
        UNION
        select PLAN_HASH_VALUE, 33 seq, 3 ID,lpad(' ',3,' ')||hint xxx from OL
        where instr(:showOptions,'O')>0
        union
        select PLAN_HASH_VALUE, 33 seq, 4 ID, lpad(' ',3,' ')||'END_OUTLINE_DATA' xxx from OL
        where instr(:showOptions,'O')>0
        UNION
        select PLAN_HASH_VALUE, 33 seq, 5 ID, '*/' xxx from OL
        where instr(:showOptions,'O')>0
        UNION
        select distinct PLAN_HASH_VALUE, 35 seq, 0 ID, chr(10)||'------------- Peeked Binds (Plan Hash Value:'||PLAN_HASH_VALUE||') --------------' xxx
        from pb
        where instr(:showOptions,'K')>0
        UNION
        select PLAN_HASH_VALUE, 35 seq, 1 ID,
               LISTAGG('var '||substr(name,2)||' '||data_type,chr(10)) WITHIN GROUP (ORDER BY name) xxx
        from pb
        where instr(:showOptions,'K')>0
        group by PLAN_HASH_VALUE
        UNION
        select PLAN_HASH_VALUE, 35 seq, 2 ID,LISTAGG('exec '||name||':='||decode(instr(data_type,'NUMBER'),0,''''||value||''';',value),chr(10)) WITHIN GROUP (ORDER BY name) xxx
        from pb
        where instr(:showOptions,'K')>0
        group by PLAN_HASH_VALUE
        UNION
        select distinct PLAN_HASH_VALUE, 36 seq, -1 ID, chr(10)||'------------- Predicate Information (Plan Hash Value:'||PLAN_HASH_VALUE||') --------------' xxx
        from P 
        where ((access_predicates is not null) or (filter_predicates is not null))
        and instr(:showOptions,'D')>0
        UNION
        select PLAN_HASH_VALUE, 36 seq, ID,lpad(id,3,' ')||' Access: '||access_predicates xxx
        from P
        where (access_predicates is not null)
        and instr(:showOptions,'D')>0
        union
        select PLAN_HASH_VALUE, 36 seq, ID,lpad(id,3,' ')||' Filter: '||filter_predicates xxx
        from P
        where (filter_predicates is not null)
        and instr(:showOptions,'D')>0
        union
        select distinct P.PLAN_HASH_VALUE, 50 seq, -1 ID, chr(10)||'------------- Plan Loading (Plan Hash Value:'||P.PLAN_HASH_VALUE||') --------------' xxx
        from P, PL
        where P.PLAN_HASH_VALUE=PL.PLAN_HASH_VALUE and p.ID=SQL_PLAN_LINE_ID
        and total_waits>0
        and instr(:showOptions,'L')>0
        UNION
        select P.PLAN_HASH_VALUE, 50 seq, PL.TOTAL_WAITS-PL.WAITS ID, 
               lpad(P.ID,3,' ')||': '||RPAD(PL.sql_plan_op,50,' ')||rpad('#',round(pl.waits/pl.total_waits*50),'#')||'('||round(pl.waits/pl.total_waits*100,2)||'%)' xxx
        from P, PL
        where P.PLAN_HASH_VALUE=PL.PLAN_HASH_VALUE and p.ID=SQL_PLAN_LINE_ID
        and PL.total_waits>0
        and instr(:showOptions,'L')>0
        union
        select distinct PLAN_HASH_VALUE, 55 seq, -1 ID, chr(10)||'------------- Waits Events (Plan Hash Value:'||PLAN_HASH_VALUE||') --------------' xxx
        from we
        where total_waits>0
        and instr(:showOptions,'W')>0
        UNION
        select PLAN_HASH_VALUE, 55 seq, TOTAL_WAITS-WAITS ID, 
               rpad(event||' on '||wait_object,75,' ')||rpad('#',round(waits/total_waits*50),'#')||'('||round(waits/total_waits*100,2)||'%)' xxx
        from we 
        where total_waits>0
        and instr(:showOptions,'W')>0
        union
        select PLAN_HASH_VALUE, 60 seq, 1 ID, chr(10)||'------------- Statistics Data '||decode(PLAN_HASH_VALUE,99999999999999,'','(Plan Hash Value:'||PLAN_HASH_VALUE||')')||'--------------' xxx from sd
        where instr(:showOptions,'S')>0
        union
        select PLAN_HASH_VALUE, 60 seq, 
               10+to_number(substr(str,1,instr(str,',')-1)) ID, substr(str,instr(str,',')+1) xxx
          from (select PLAN_HASH_VALUE, trim(regexp_substr(str, '[^'||spliter||']+', 1, level)) str from sd 
                connect by level <= length (regexp_replace (str, '[^'||spliter||']+'))  + 1)
        union
        select PLAN_HASH_VALUE, 60 seq, 101 ID, 
               'PGA Size(Maximum): '||round(max(nvl(pga_size,0)),3)||'G' xxx 
          from ss
         where instr(:showOptions,'S')>0
         group by PLAN_HASH_VALUE
        union
        select PLAN_HASH_VALUE, 60 seq, 102 ID, 
               'Temp Space(Maximum): '||round(max(nvl(temp_size,0)),3)||'G' xxx 
          from ss
         where instr(:showOptions,'S')>0
         group by PLAN_HASH_VALUE
         order by PLAN_HASH_VALUE, SEQ, ID, XXX)
;

undef 1 2 3
set head on
clear columns

          




          
]]>          
					
		
		
			          
		
		EXECUTANDO DATAPUMP EXPORT (EXPDP) NO ORACLE RDS
		https://furushima.com.br/blog/executando-datapump-export-expdp-no-oracle-rds/
		
		
		Tue, 02 Apr 2024 18:50:37 +0000
				
		
		
		
		https://dev.furushima.com.br/?p=2174

					
										
          




          Neste tutorial, vamos explorar como realizar uma exportação de dados utilizando o Datapump Export via a API DBMS_DATAPUMP no Oracle Database. Este método é altamente flexível e permite exportar dados de forma eficiente e controlada.
          




          Etapa 1: Configurando a Exportação
          




          Antes de iniciar a exportação, certifique-se de executar este código no banco de dados de origem, onde deseja realizar o export:
          




          DECLARE
    Bkp NUMBER;
    s VARCHAR2(30000);
BEGIN
    -- Abrindo um job de exportação no Data Pump
    Bkp := DBMS_DATAPUMP.OPEN(
        operation => 'EXPORT',
        job_mode => 'SCHEMA',
        job_name => NULL
    );

    -- Adicionando arquivo de exportação
    DBMS_DATAPUMP.ADD_FILE(
        handle    => Bkp,
        filename  => 'datapump_source_DATA_F.dmp',
        directory => 'DATA_PUMP_DIR',
        filetype  => dbms_datapump.ku$_file_type_dump_file,
        reusefile => 1
    );

    -- Adicionando arquivo de log
    DBMS_DATAPUMP.ADD_FILE(
        handle    => Bkp,
        filename  => 'datapump_source_DATA_F.log',
        directory => 'DATA_PUMP_DIR',
        filetype  => dbms_datapump.ku$_file_type_log_file
    );

    -- Selecionando owners para exportação
    SELECT LISTAGG('''' || owner || '''', ', ') WITHIN GROUP (ORDER BY owner) 
    INTO s
    FROM (
        SELECT username AS owner
        FROM dba_users
        WHERE username NOT IN (
            'ANONYMOUS', 'SYS', 'SYSTEM', 'SYSAUX',
            'APPQOSSYS', 'AUDSYS', 'CTXSYS', 'DBSNMP',
            'DIP', 'GSMADMIN_INTERNAL', 'GSMCATUSER', 'GSMUSER',
            'ORACLE_OCM', 'SYSBACKUP', 'SYSDG', 'SYSKM',
            'XDB', 'XS$NULL', 'RDSADMIN', 'SYSRAC',
            'SYS$UMF', 'REMOTE_SCHEDULER_AGENT', 'GGSYS',
            'DBSFWUSER'
        )
    );

    -- Aplicando filtro para exportação dos schemas selecionados
    DBMS_DATAPUMP.METADATA_FILTER(Bkp, 'SCHEMA_LIST', s);

    -- Iniciando o job de exportação
    DBMS_DATAPUMP.START_JOB(Bkp);
END;
/

          




          




          Etapa 2: Acompanhando o Progresso da Exportação
          




          Para verificar o progresso da exportação, execute o seguinte comando no banco de dados de origem:
          




          SELECT text
          FROM TABLE(rdsadmin.rds_file_util.Read_text_file (
          p_directory => 'DATA_PUMP_DIR',
          p_filename => 'datapump_source_DATA_F.log'
          ));
          




          




          Etapa 3: Verificando o Arquivo Gerado
          




          Para verificar o arquivo gerado no diretório, utilize o seguinte comando no banco de dados de origem:
          




          SET LINES 200 PAGES 200
          COL filename FORMAT A100
          SELECT filename,
          ROUND(filesize / 1024 / 1024 / 1024) AS SIZE_GB
          FROM TABLE(rdsadmin.rds_file_util.Listdir('DATA_PUMP_DIR'))
          WHERE filename LIKE 'datapump_source_DATA_F%'
          ORDER BY mtime;
          




          




          Para as próximas etapas sobre transferência para o ambiente de destino e criação de DBLINK e DIRECTORY, sugiro verificá-las diretamente na documentação oficial da Oracle , pois podem variar dependendo da configuração e políticas de segurança do ambiente.
          




          




          Criado por : Carlos Furushima
          




          




          




          




          
]]>