Geral

Curso Oracle 10g – Página 1

CURSO

10 g

WWW.IPED.COM.BR

http://WWW.IPED.COM.BR/


Instalando Oracle10g


Escolher name como: Oracle10gR2 Escolher Path como: C:oracleproduct

Esta mensagem de erro ocorre pois setamos a variável ORACLE_BASE com o mesmo valor que a variável ORACLE_HOME assume. Selecionar Yes e seguir em frente.


Escolher Criar BANCO

Escolher a opção Avançado


Checar Summary para ver se todas as configurações foram conforme o planejado.

Escoher Install.

Acompanhar progresso da instalação conforme tela abaixo:


Na tela acima, escolher Custon Database e teclar Next. Na tela abaixo, escolher o Global Database Name e o SID.


Não escolher a opção Configure the Database with Enterprise Manager somente caso queira.

Desmarcar a opção conforme tela abaixo.

Na tela abaixo escolher Use Different Passwords, conforme padrão Bovespa.


Na próxima tela escolher a opção File System.

Exemplo: F:oracle


Na tela abaixo, demarcar a opção Specify Flash Recovery Área.

Na aba Database Components, desmarcar todas as opções. Clicar em Standard Database Components e desmarcar todas também, conforme tela abaixo !!!


Na tela abaixo, temos várias configurações a fazer:

Memory: Escolher Percentage 60% Sizing: Escolher Block Size: 8192 e Process: 150. Character Sets: Escolher as seguintes opções: Database Character Set: WE8ISO8859P1 National Character Set: UTF8 Default Language: American Default Date Format: United States Conection Mode: Dedicated Server Mode


Na tela a seguir, definir o STORAGE conforme as versões anteriores. Conferir o caminho de todos os objetos e escolher Next !!! Não esquecer de criar as tablespace de sistema como: Esquecer de tirar os números dos tablespace Ex: system01.dbf System : Minimo 600Mb UndoTBS : 2Gb no storage maxsize 2gb Temp : 600Mb Sysaux : 300Mb

Na tela a seguir, escolher Create Database e Generate Database Creation Scripts (conferir o caminho!).


Na tela a seguir, conferir em CUSTOM DATABASE se está conforme nossas configurações. Se estiver tudo certo, teclar OK.

Ele vai confirmar a geração dos scripts no caminho selecionado. Apenas escolher OK.


Acompanhar o progresso da instalação.

A tela abaixo, conferir os dados e clicar em Exit;


A seguinte tela deve ser exibida para terminar a instalação: Selecionar Exit e em seguida Yes.

Atribuições de um DBAO uso de aplicativos via Internet aumenta a cada dia e, consequentemente, cresce significativamente o surgimento de empresas de TI disponibilizando serviços de bancos de dados. Isto implica em contratação de serviços de administração de bancos de dados. Quais são as principais atividades de um DBA. Abaixo temos uma lista de atribuiçoes, a quais considero fundamentais para o dia-a-dia desse especialista.

Avaliação de Recursos de Hardware Esta diretamente ligada a aquisições de hardware para suprir eventuais faltas de recursos ou atualização tecnológica. O papel do DBA é avaliar o impacto da mudança sobre os serviços de bancos de dados.

Instalação de Produtos Embora os principais servidores de bancos de dados possuam excelentes programas instaladores, ainda é necessário que o DBA participe ativamente da instalação e configuração desses produtos.

Planejamento de Recursos de Banco É importante entender como a estrutura lógica de um banco afeta o desempenho do sistema e de diversas operações de gerenciamento de banco de dados. Por exemplo, antes de criar as tablespaces é necessário definir quais e como os discos serão utilizados.

Criação e Disponibilização de Serviços A criação de um banco ocorre quando há implementações de novos projetos, migrações e atualização de versões.A disponibilização de serviços de banco é realizada pela gestão de ambientes TI, baseada em roteiros de comandos de inicialização de servicos.


Cópias de Segurança (Backup) Embora a tecnologia de armazenamento em discos tenham evoluído bastante, antes de vender serviços de TI, certifique-se de que esses podem ser salvos em fitas backup.Há diversos métodos de execução de backup. É importante que o método escolhido esteja de acordo com a política de backup definida no acordo de nível de serviços.

Controle de Acesso Para administrar e ter controle de acesso aos serviços de banco de dados é necessário que o DBA tenha privilégios de superusuário, e, conseqüentemente ter condições de controlar os acesso dos demais usuários.Ter privilégios de superusuário não significa ter acesso às informações de negócio, mas condições de realizar todas as tarefas de administração de de bancos de dados.

Implementação de Projetos de Banco Implementar projetos de banco significa preparar o banco para uso a partir de aplicativos, criando ou atualizando os objetos desse aplicativo, tais como: tabelas, índices, procedimentos catalogados.

Desempenho de Serviços de Banco Produzir e analisar relatórios sobre a saúde do banco de dados é uma das tarefas mais importantes, realizadas pelo DBA.O principal objetivo dessa atividade é verificar se indicadores de desempenho estão de acordo com os níveis de serviços contratados pelo cliente.

Instalação de Patches Não existem programas de computadores cem por cento corretos. Portanto, eventualmente é necessário corrigir esses programas instalando correções distribuídas pelos fabricantes.Essa atividade pode ser realizada por demanda ou automaticamente, mas depende da análise do DBA sobre o impacto da mudança.

Clonagem e Migração de Serviços A clonagem de serviços de banco muito utilizada em ambientes de TI que possuem vários servidores utilizando a mesma versão de produtos de banco.Nas grandes empresas de prestação de serviços de TI, ocorre pelo menos uma migração de serviços de banco por semana. Portanto se você é um DBA, então já migrou ou vai migrar pelo banco de dados. As atribuições listadas acima podem sofrer modificações, tudo depende da evolução tecnológica. Todavia, as grandes empresas são avessas à mudanças que possam comprometer seus negócios.

MER (Modelo Entidade Relacionamento) O MER (Modelo Entidade Relacionamento), também conhecido apenas como modelo de dados ou diagrama de entidade-relacionamento, é a principal documentação de um banco de dados. Neste diagrama são relacionadas as principais entidades (tabelas) e seus relacionamentos, além de alguns detalhes a respeito das entidades, como nome das colunas nas tabelas, tipos de dados e constraints. Geralmente utiliza-se uma ferramenta CASE para modelagem deste diagrama, sendo o ER-Win um dos softwares mais utilizados para elaborar este diagrama. Independente do software utilizado é imprescindível que o DBA conte com ao menos um MER para cada uma das bases que ele administra.


Padrões de Variáveis (Tabelas, colunas etc) e Documentação Uma das boas práticas de desenvolvimento é contar com padrões. Saber colocar nomes significativos e explicativos em funções, variáveis, classes etc está se tornando cada vez mais um pré-requisito para quem trabalha com desenvolvimento. No que tange à banco de dados, a idéia não é diferente: possuir um padrão de nomes para tabelas, colunas, constraints e objetos de bancos de dados é muito importante. Aqui a idéia não é apenas possuir um padrão e utilizá-lo largamente, mas possuir um padrão eficaz que seja fácil de ser utilizado, além de fazer sentido no contexto de banco de dados. Para formalizar a adoção de um padrão, recomenda-se montar um documento explicando todos os detalhes deste padrão como, por exemplo, se o padrão é baseado na notação húngara, se os nomes devem ser em português ou se há um limite no tamanho da coluna.

Capacity Plan A necessidade de prever recursos de hardware é uma das grandes responsabilidades de um DBA. Além de economizar recursos, a previsão mostra que há um controle não apenas para os recursos que estão sendo utilizados, mas também para os recursos que podem ser necessários no futuro. Para ajudar nesta previsão, o DBA deve ser responsável pela elaboração de um documento chamado Capacity Plan, ou Plano de Capacidade. Este documento deve listar as necessidades de espaço de armazenamento, utilização de CPU, largura de banda e outros requisitos técnicos que possam impactar o banco de dados. Com certeza, este é um documento que envolve muitos aspectos e deve ser elaborado com cuidado. Por questões práticas, muitas vezes é necessário fazer uso de estimativas e tendências ao invés de contar com informações precisas. Deste modo, o documento não precisa estar 100% correto, mas deve conter uma boa base e previsão dos principais recursos computacionais relacionados ao banco de dados.

Dicionário de dados O Dicionário de dados é um documento que complementa o MER. Este documento deve conter mais detalhes a respeito das tabelas e seus relacionamentos. Por exemplo, além de listar todas as colunas de uma tabela, o documento deve fornecer também uma pequena descrição do significado desta coluna, quais são os valores possíveis, a quantidade típica de valores armazenados e quais constraints agem sobre esta coluna. Além das informações sobre colunas, este documento apresenta o nome dos objetos que dependem da tabela, como stored procedure, triggers, views, funções etc, e suas respectivas funções, além dos parâmetros necessários e o que é retornado. É importante notar que este documento deve sempre estar alinhado e atualizado com a base de dados atual, para evitar desencontros e desentendimentos.

Política de segurança

O documento contento a política de segurança é um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas. Geralmente este documento contém uma política de usuários e senhas, que especificam várias regras, como as definidas abaixo:

• Troca de senha a cada três meses; • Desabilitar as contas padrão; • Forçar senhas com letras, números e caracteres especiais que tenham um tamanho mínimo de 10 posições;

Outras políticas gerais de senha, como o cancelamento após um algumas tentativas e horários definidos para certos usuários, também deve constar neste documento, sempre tendo em mente a utilização de sistemas e bancos de dados.


N.D.A (non-disclosure agreement) - Compromisso de sigilo

Imaginem a seguinte situação:

Somos responsáveis por uma base de dados que deve ser integrada com um sistema externo à empresa. Para discutir os detalhes desta integração, uma reunião é marcada com a equipe externa à empresa que desenvolve o sistema. Durante esta reunião são apresentadas informações sigilosas da empresa que trabalhamos, com o objetivo de discutir os aspectos da integração. Vamos supor que na situação apresentada acima os profissionais da equipe externa hajam da má fé e utilizem as informações fornecidas para seu próprio benefício, seja comercialmente ou não. Este tipo de situação pode gerar diversos problemas, podendo chegar ao ponto onde a equipe que agiu de má fé ser acusada de roubo.

Para e proteger de situações como estas, é comum fazer uso de um documento chamado NDA (non-disclousure agreement), também conhecido como compromisso de sigilo. Este é o tipo de documento que protege todo mundo: tanto quem assina como quem solicita a assinatura. Em termos práticos, que assina compromete-se a não revelar nenhum detalhe da informação que lhe vai ser comunicada sob pena de ser alvo de procedimento legal.

S.L.A. (Service Level Agreement) - Acordo de nível de service (ANS)

O SLA, também conhecido como Acordo de nível de serviço - ANS, é um acordo entre a área prestadora de serviços e seus clientes. Este acordo deve deixar claro quais serviços estão sendo oferecidos (serviços específicos) e o nível de cada serviço (horas de funcionamento, downtime, horário do suporte etc). Geralmente este acordo é colocado na forma de um contrato que deve ser assinado na contratação do serviço. Para banco de dados, em particular, pode-se utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback) ao solicitante. Notem que este retorno não quer dizer, necessariamente, a resolução do problema ou o conserto, mas sim que o DBA está ciente da solicitação.

Diagrama de arquitetura

Atualmente é comum encontrar nas empresas diversos ambientes de bancos de dados. Estes ambientes são separados de acordo com a sua finalidade, isto é, seu principal objetivo. Por exemplo, é comum encontrar ambientes de desenvolvimento, onde os programadores/analistas executam diversos testes durante o processo de desenvolvimento, e ambientes de programação, onde os usuários finais trabalham com os dados reais dos sistemas. Para documentar e organizar o gerenciamento destes ambientes, o DBA deve elaborar um diagrama de arquitetura, que indica, de forma gráfica, quais servidores pertencem ao ambiente de desenvolvimento e ao ambiente de produção, como eles estão localizados em relação aos usuários com informações sobre link, rede, zonas desmilitarizadas (DMZ), firewalls, roteadores, etc. Este tipo de diagrama contém informações relacionadas à estrutura arquitetural dos ambientes e é extremamente útil para quem não conhece a organização física e lógica dos componentes da rede e dos servidores. É importante lembrar que este documento pode ser flexível, ou seja, pode incluir detalhes específicos, como endereços I.P. e senhas, ou apresentar uma visão de alto nível, onde apenas os principais servidores são apresentados.


Procedimento para controle de chamados ou O.S. (ordem de serviço)

Este último item não é exatamente um documento, mas sim um procedimento que deve ser adotado para o controle de solicitações de serviço (ou chamados) ao DBA. Este tipo de controle evita problemas de comunicação entre quem solicitou e que realiza uma tarefa. Deixar este controle apenas a cargo do envio de e-mails é um primeiro passo, mas investir em um sistema para controlar o acesso às pessoas é algo fundamental, uma vez que este procedimento está diretamente relacionado com as regras definidas no SLA. Obviamente, este tipo de controle deve ser utilizado de forma sensata, pois existem diversos tipos de solicitações que podem exigir tratamentos diferentes, como apenas uma olhada no estado de um servidor. Mais uma vez, a idéia aqui é estabelecer um mecanismo de controle tanto para quem solicita a tarefa como para quem a executa.

Outros tipos de documentos são necessários para quem trabalha com desenvolvimento de sistemas. Atas de reunião, manuais de implementação de sistemas e help-online são apenas alguns exemplos disto. Em geral, o DBA é o profissional que menos tem que lidar com este tipo de documentação. Apesar disso, é importante que o profissional que trabalha com banco de dados, e também com desenvolvimento de sistemas, tenha consciência que esta documentação não necessariamente é burocracia, mas sim que ela é um artefato extremamente importante para todos os profissionais envolvidos.

TESTE PRÁTICO



Backups Inteligentes

Realizar cópias de segurança é fácil. Difícil é restaurar e recuperar rapidamente os dados contidos em fitas backup. Principalmente quando o conteúdo das cópias de segurança são transformados pelo utilitário de backup no momento em que as cópias são geradas.

Processos de backup mudaram muito pouco nos últimos trinta anos. Esses basicamente copiam e restauram arquivos, sem envolver-se com regras de negócio ou preocupar-se com as questões relacionadas a disponibilidade.

Está muito na moda oferecer serviços 24×7 disponíveis. Manter serviços de banco de dados disponíveis o tempo todo nos dias de hoje é fácil. Difícil é acordos de nível de serviço desta natureza, quando ocorre algum incidente o qual a resolução dependa de recuperação de dados.

Atualmente já existem empresas optando por replicação dinâmica de bases de dados, utilizando técnicas de espelhamento remoto. A principal vantagem é o rápido restabelecimento de serviços, mesmo para bases de dados gigantescas. Cabe ressaltar que com espelhamento de bases de dados, o tempo de recuperação de bancos de dados não está relacionado ao tamanho do banco, mas uma infraestrutura com processo de recuperação de serviços bem-definida.

Backups Inteligentes

Realizar cópias de segurança é fácil. Difícil é restaurar e recuperar rapidamente os dados contidos em fitas backup. Principalmente quando o conteúdo das cópias de segurança são transformados pelo utilitário de backup no momento em que as cópias são geradas.

Processos de backup mudaram muito pouco nos últimos trinta anos. Esses basicamente copiam e restauram arquivos, sem envolver-se com regras de negócio ou preocupar-se com as questões relacionadas a disponibilidade.

Está muito na moda oferecer serviços 24×7 disponíveis. Manter serviços de banco de dados disponíveis o tempo todo nos dias de hoje é fácil. Difícil é acordos de nível de serviço desta natureza, quando ocorre algum incidente o qual a resolução dependa de recuperação de dados.

Atualmente já existem empresas optando por replicação dinâmica de bases de dados, utilizando técnicas de espelhamento remoto. A principal vantagem é o rápido restabelecimento de serviços, mesmo para bases de dados gigantescas. Cabe ressaltar que com espelhamento de bases de dados, o tempo de recuperação de bancos de dados não está relacionado ao tamanho do banco, mas uma infraestrutura com processo de recuperação de serviços bem-definida.

Administração de Banco de Dados Oracle 10G

O Oracle Database 10g representa grandes mudanças. Há mais modificações nesta versão do que se imagina.

Você pode instalar o Oracle Database 10g e tratá-lo desde o início quase da mesma maneira como trataria um banco de dados Oracle9i. Você utiliza o SQL*Plus para se conectar a ele ( para felicidades daqueles que, desde então, ouviram rumores de que o SQL*Plus desapareceria!) e ainda o inicia com o comando startup e o fecha com o comando shutdown. Você pode migrar do Oracle8 ou Oracle9i com pouco esforço, mas tenha cuidado e sem lidar com muitos novos recursos como por exemplo SYSAUX ( novos espaços de tabelas ). Em resumo, até um certo ponto, muitos desses novos recursos são opcionais, mas eles oferecem um desempenho aprimorado, um gerenciamento mais fácil e mais funcionalidades.


O que é GRID ?

Oracle Database 10g - g significa, ele é uma abreviação do relativamente obscuro conceito de "GRID". O GRID representa as sinergias que podem ser alcançadas alinhando as tecnologias Oracle às capacidades de Hardware existentes e futuras.

Beneficiar-se dos componentes disponíveis para o Grid - Por meio do Oracle Real Application Clusters, Automatic Storage Management (ASM) e Ultra-Large Data Files.

Balanceamento de carga por toda a empresa - Tecnologias do Oracle Real Application Clusters, Oracle Streams e dos bancos de dados distribuídos da Oracle suportam esses conceitos.

Compartilhar informações independentemente da localização - Esse conceito é suportado por meio dos novos recursos de espaço de tabelas transportáveis, Oracle Streams ( exemplo - Replication ), tabelas externas e consultas SQL distribuídas.

Agendar recursos no Grid - Os novos recursos do Oracle Sheduler e do Oracle Database Resource Manager ajudam o DBA a efetivamente aproveitar melhor o GRID.

O GRID está cheio de novos recursos que o alinha mais completamente aos conceitos de GRID.

Arquitetura Cliente/Servidor

As principais estruturas são a SGA (System Global Area ou Área Global do Sistema) e a PGA (Program Global Area ou Área Global de Programa).


A PGA é o buffer de memória que contém dados e algumas informações de controle de uma sessão de um usuário. A PGA é criada e alocada quando um novo processo é inicializado no servidor. As suas informações dependem da configuração do ORACLE. Assim, existe uma área de memória PGA para cada usuário que está executando seus trabalhos no ORACLE. Dentro da PGA existem três estruturas: uma contendo um espaço para a pilha (para armazenar as variáveis e matrizes), outra contendo dados sobre a sessão do usuário e uma terceira com as informações dos cursores usados. A PGA não é compartilhada entre os usuários; ela é única para cada sessão.

A SGA é uma região de memória compartilhada por todos os usuários e alocada pelo ORACLE. Contém os dados e as informações de controle de uma instância. Ela é alocada quando uma nova instância é inicializada e liberada quando a mesma é finalizada. Os dados na SGA são compartilhados pelos usuários que estiverem conectados ao banco de dados e, para otimizar a performance, as entradas na SGA devem ser as maiores possíveis para guardar a maior quantidade de dados e minimizar o I/O em disco, uma das causas críticas que tornam um banco de dados lento. As informações na SGA estão organizadas em diversos tipos de estruturas de memória, incluindo o buffer do banco de dados e o buffer para recuperação do banco, por exemplo. As estruturas têm tamanho fixo e são criadas durante a inicialização da instância. O grupo de buffers do banco de dados em uma instância são chamados de database buffer cache. Esses buffers podem conter os dados modificados que ainda não foram escritos em disco, para os arquivos de dados apropriados. Desse modo o I/O é minimizado e há uma melhora significativa da performance. Essa estrutura é compartilhada entre todos os usuários conectados a um banco de dados e os blocos de dados que são armazenados no database buffer cache têm seus tamanhos determinados pelo parâmetro DB_BLOCK_SIZE. O número de blocos em memória é determinado pelo parâmetro DB_BLOCK_BUFFERS.

O conteúdo do database buffer cache é organizado em duas listas: a lista de blocos alterados e a lista dos blocos menos recentemente utilizados (LRU - Least Recently Used). Essa segunda lista contém os blocos livres, aqueles que estão em uso e os blocos alterados. Quando um processo servidor precisa ler dados de um bloco do disco para o database buffer cache, ele pesquisa a LRU para localizar um bloco livre e, quando encontrar um bloco alterado, movimenta-o para a lista de blocos alterados. Esse processo termina quando um bloco livre é localizado ou quando um número específico de blocos são pesquisados sem encontrar um bloco livre.

Durante uma operação de SELECT, o ORACLE requer que os blocos que contêm a informação desejada esteja em memória. Assim, a lista LRU é pesquisada e, se os blocos não estiverem em memória, o produto efetua as leituras físicas necessárias. Caso o bloco esteja em memória, são efetuadas leituras lógicas. Lembremo-nos de que nenhuma tabela pode ocupar menos de dois blocos de dados: um bloco para o cabeçalho e pelo menos outro bloco de dados.

O redo log buffer cache da SGA armazena todas as alterações feitas em um banco de dados em memória. Todas as entradas redo log neste buffer são escritas nos arquivos redo log, que são usados para a recuperação do banco de dados, se necessário.

A shared pool é uma porção de memória compartilhada que contém as áreas chamadas shared SQL, estruturas de memória compartilhadas que contêm os comandos SQL que estão sendo executados pelos múltiplos usuários


conectados a um banco de dados. Essas áreas compartilhadas shared SQL contêm informações como o texto e a forma interpretada dos comandos SQL, a fase de análise dos comandos SQL e seus planos de execução, informações do dicionário de dados e de geradores de números seqüenciais. Uma única área shared SQL pode ser compartilhada por diversas aplicações que usam o mesmo comando definido na área compartilhada de comandos SQL, deixando assim mais área em memória disponível para os outros usuários e melhorando a performance de execução de um comando, já que o plano de execução já está definido e o ORACLE não precisa defini-lo novamente.

A shared pool contém ainda o data dictionary cache, com as informações do dicionário de dados, e o sequence cache, com as informações dos geradores de números seqüenciais. Um cursor é um nome ou ponteiro para a memória associada a um comando específico. Muitas aplicações ORACLE tiram proveito dos cursores.

O Banco de Dados Oracle é composto por uma estrutura lógica de dados, armazenadas em arquivos físicos do sistema operacional. Existem basicamente 3 tipos de arquivos: Os arquivos de dados que contêm todos os dados do banco;

Os arquivos de redo log, que registram todas as alterações feitas, permitindo recuperação em caso de falha no arquivo de dados; E os arquivos de controle utilizados para manter a integridade entre a instância, arquivo dados e arquivos de redo. Os arquivos auxiliares, podem ser de parâmetros pois eles definem características de carga da instancia, por exemplo.

Podem ainda ser arquivos de senhas utilizados para os usuários que tem permissão para inicializar as instancias e, finalmente, os arquivos que contém cópias do Redo Log, garantindo assim, maior segurança das informações.

ProcessosOs processos podem ser vistos como programas que trabalham em memória (em background) e executam outras tarefas específicas para o ORACLE. Um processo é uma forma de controle ou um *mecanismo no sistema operacional que pode executar uma série de passos e normalmente tem sua área particular de memória. Alguns sistemas operacionais usam o termo job ou tarefa.


Existem dois tipos gerais de processos: os processos dos usuários e os processos do próprio ORACLE.

Um processo de usuário é criado e mantido para executar o código da aplicação (por exemplo um programa Pro*C) ou uma ferramenta ORACLE (por exemplo o SQL*Plus). Os processos dos usuários também gerenciam a comunicação com os processos do servidor ORACLE através do program interface.

Os processos ORACLE são chamados por outros processos para executar algumas funções específicas. O produto cria os processos servidores (server process) para controlar as requisições dos processos dos usuários conectados a um banco de dados. Assim, os processos servidores são incumbidos de comunicar-se com os processos dos usuários e interagir com o ORACLE para acessar seus recursos. Por exemplo, se um usuário pesquisa alguns dados que não estejam no database buffer cache da SGA, o processo servidor lê os dados apropriados dos blocos de dados dos arquivos e os coloca na SGA, para uso dos usuários. Dependendo da configuração do ORACLE, um processo servidor pode ser compartilhado por diversos usuários.

Todos os comandos SQL são processados pelos processos servidores que se utilizam de três fases para o processamento: análise, execução e busca dos dados. O plano de cada comando é armazenado na SGA, nas áreas que contêm comandos SQL a serem compartilhados entre os usuários. O ORACLE cria um conjunto de processos que rodam em background para cada instância. Esses processos executam diversas tarefas. São eles: DBWR, LGWR, CKPT, SMON, PMON, ARCH, RECO, Dnnn e LCKn.

O processo database writer (DBWR) escreve os blocos modificados do database buffer cache para os arquivos de dados físicos. O DBWR não precisa escrever os dados a cada comando COMMIT, pois é otimizado para minimizar o I/O. Geralmente o DBWR escreve os dados para o disco se muitos dados são lidos para o database buffer cache na SGA e não existe espaço livre para esses novos dados. Os dados menos recentemente usados são escritos para os arquivos de dados em primeiro lugar.

O processo log writer (LGWR) escreve todas as entradas de redo log para o disco. Os dados de redo log são armazenados em memória no redo log buffer cache, na SGA. No momento em que uma transação for efetivada com o comando COMMIT e o redo log buffer estiver preenchido, o LGWR escreve as entradas de redo log nos arquivos redo log apropriados.

A um tempo específico, todos os dados do database buffer cache modificados são escritos em disco pelo processo DBWR; este evento é chamado de checkpoint. O processo checkpoint é responsável para informar ao processo DBWR o momento de gravar os dados em disco. O DBWR também atualiza os arquivos de controle do banco de dados para indicar o mais recente checkpoint. O processo CKPT é opcional; se ele não estiver presente, o LGWR assume sua responsabilidade.



O processo system monitor (SMON) efetua a recuperação da instância em caso de falhas, durante a sua inicialização. Em um sistema com múltiplas instâncias (como na configuração Oracle Parallel Server, por exemplo), o processo SMON de uma instância também pode executar a recuperação de outras instâncias que podem ter falhado. Ele também limpa os segmentos temporários que não estão sendo usados, liberando memória, e recupera qualquer transação pendente no caso de uma falha em arquivos físicos ou mesmo no disco. O processo de recuperação dessas transações é executado pelo processo SMON quando a tablespace afetada volta a ficar disponível.

O process monitor (PMON) executa a recuperação do processo de um usuário quando esse processo falha. Limpa a área de memória e libera os recursos que o processo do usuário estava usando. O PMON também verifica o processo despachante (dispatcher) e os processos servidores (server processes) e os reinicializa se tiver acontecido qualquer falha.

O processo archiver (ARCH) copia os arquivos redo log para fita ou mesmo outro disco, no momento em que um deles torna-se completo. Esse processo geralmente está presente quando o banco de dados está sendo utilizado no modo ARCHIVELOG. Os arquivos redo log nada têm a ver com auditoria. Eles são usados somente para a recuperação de um banco de dados.

O processo recoverer (RECO) é usado para resolver transações distribuídas pendentes causadas por uma falha na rede em um sistema de bancos de dados distribuídos. A certos intervalos de tempo, o processo RECO do banco de dados local tenta conectar-se ao banco de dados remoto para automaticamente completar e efetivar a transação (COMMIT) ou descartar (ROLLBACK) a porção local de uma transação pendente em um sistema distribuído.


Os processos em background dispatchers (Dnnn) são opcionais e estão presentes somente quando a configuração do Oracle Multi-thread Server é usada. Pelo menos um processo dispatcher é criado para cada protocolo de comunicação em uso (D000, D0001, ..., Dnnn). Cada processo dispatcher é responsável pelo direcionamento das requisições dos processos dos usuários conectados ao banco de dados para o processo servidor disponível e pelo retorno da resposta de volta para o processo do usuário apropriado.

Por sua vez, os processos lock (LCKn) são usados para controlar o lock entre instâncias em uma configuração Parallel Server.

Checkpoint

Durante um CHECKPOINT, o DBWR grava todos os buffers “sujos” da DATABASE BUFFER CACHE no disco, garantindo que todos os blocos de dados modificados desde o ultimo CHECKPOINT, sejam gravados no disco.

O CHECKPOINT ocorre :

• Em cada log switch, • Quando atinge um numero determinado de segundos após o ultimo CHECKPOINT, • Quando um numero pré-determinado de blocos do redo log são gravados no disco, desde o ultimo CHECKPOINT, • Em um shutdown da instance, • Quando forçado pelo DBA, e • Quando a tablespace e colocada offline.


O parâmetro LOG_CHECKPOINT_TIMEOUT determina o intervalo de tempo entre CHECKPOINTS. O parâmetro LOG_CHECKPOINT_INTERVAL determina o número de blocos de redo log recentemente preenchidos que são necessários para iniciar um checkpoint.

Deve-se observar que no caso da necessidade de recuperação de uma instance, será necessário refazer somente as alterações desde o ultimo checkpoint. O checkpoint permite que um redo log on-line seja reusado, garantindo que todas as alterações armazenadas em um redo log estejam gravadas nas respectivas tabelas de dados.

Processo CKPT

Os checkpoints asseguram que todos os buffers, de base de dados, modificados são gravados no disco. As tabelas são marcadas com a data corrente da gravação e o checkpoint e gravado no arquivo de controle (control file).

O processo CKPT :

• Regravara os headers de dados e control files após um checkpoint haver sido completado.

• Checkpoints realizados com maior freqüência, irão reduzir o tempo necessário para uma recuperação no caso de uma falha de instance, agilizando sua performance.

• O processo de checkpoint sera habilitado pelo parâmetro CHECKPOINT_PROCESS.


Program interface.

O program interface é o mecanismo pelo qual um processo do usuário se comunica com o processo servidor. Serve como um método de comunicação padrão entre a porção cliente de uma aplicação ou uma ferramenta e o próprio servidor ORACLE.

O program interface age como um mecanismo de comunicação, através da formatação dos dados requisitados, trafegando esses dados, verificando e retornando possíveis erros. Também executa conversões de dados, particularmente entre diferentes tipos de computadores ou tipos de dados usados pelos usuários.

Se o usuário e os processos servidores estão em diferentes computadores de uma rede ou se o processo dispatcher estiver sendo usado para conectar processos de usuários e processos do servidor, então o program interface inclui um software de comunicação chamado SQL*Net, que faz a comunicação e transferência de dados entre computadores.

Como o ORACLE trabalha

Conhecendo os processos e estruturas de memória, fica bastante fácil para que entendamos o modo como ORACLE trabalha:

1. Consideremos que uma instância esteja sendo executada em um computador (servidor de um banco de dados).

2. Um computador usado para executar uma aplicação (porção cliente ou front end) executa uma aplicação de um usuário. Essa aplicação cliente tenta estabelecer uma conexão com o servidor usando o driver apropriado do SQL*Net.

3. O servidor está executando o driver apropriado do SQL*Net e detecta a requisição de conexão da aplicação cliente e cria um processo servidor dedicado ao usuário.

4. O usuário executa um comando SQL e efetiva a transação com o comando COMMIT.

5. O processo servidor recebe o comando e verifica se as áreas shared SQL, armazenadas na shared pool area, contêm um comando idêntico ao emitido pelo usuário. Se localiza uma área shared SQL com um comando idêntico, o processo servidor verifica os privilégios de acesso do usuário aos dados requisitados e o plano de execução definido é usado para buscar os dados solicitados. Se o comando emitido pelo usuário não estiver presente nessa área, uma nova estrutura para o comando é alocada e então ele pode ser analisado e processado.

6. O processo servidor recupera qualquer valor armazenado nos arquivos de dados ou os busca da memória, se lá estiverem, no database buffer cache.

7. O processo servidor modifica os dados na SGA. O processo DBWR escreve os dados modificados em disco, quando necessário. No momento do comando COMMIT, o processo LGWR escreve imediatamente os registros das transações no arquivo redo log que estiver sendo usado no momento. Se a transação for bem sucedida, o processo servidor manda uma mensagem através da rede para a aplicação. Se não for bem sucedida, uma mensagem de erro é então emitida.


Respostas

1 – É um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas.

Explicação: O documento contento a política de segurança é um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas. Geralmente este documento contém uma política de usuários e senhas, que especificam várias regras, como as definidas abaixo: • Troca de senha a cada três meses; • Desabilitar as contas padrão; • Forçar senhas com letras, números e caracteres especiais que tenham um tamanho mínimo de 10 posições;

2 – É uma região de memória compartilhada por todos os usuários e alocada pelo ORACLE. Contém os dados e as informações de controle de uma instância.

Explicação: A SGA do Oracle é a área de memória alocada na inicialização pelo Oracle que contém as estruturas de memória para armazenar dados e controlar informações. O conjunto compartilhado reside na SGA da instancia do ORACLE

3 – É o mecanismo pelo qual um processo do usuário se comunica com o processo servidor. Serve como um método de comunicação padrão entre a porção cliente de uma aplicação ou uma ferramenta e o próprio servidor ORACLE.

Explicação: O program interface age como um mecanismo de comunicação, através da formatação dos dados requisitados, trafegando esses dados, verificando e retornando possíveis erros. Também executa conversões de dados, particularmente entre diferentes tipos de computadores ou tipos de dados usados pelos usuários.


Acesso aos Dados

Antes que os dados possam ser acessados, um processo servidor criado para um determinado usuário conectado ao ORACLE traz os blocos dos arquivos fisicamente armazenados nos discos para dentro do database buffer cache. Cada comando SQL é armazenado na estrutura de memória shared pool e são compartilhados entre todos os usuários conectados a uma instância. Em certo momento, os blocos de dados modificados pelos comandos dos usuários que se encontram no database buffer cache são escritos novamente para os arquivos de dados. Isso é feito pelo processo em background DBWR.

Portanto, toda manipulação dos dados dá-se na memória principal, ou seja, na SGA. É por isso que os dados precisam ser trazidos do disco para a memória antes de serem manipulados.

Usamos dois termos para referenciarmos ao acesso aos dados: cache miss e cache hit. O termo cache miss é usado para identificar as vezes que um processo experimenta acessar uma informação e o bloco que a contém precisa ser lido do disco. O termo cache hit é usado para identificar as vezes que um processo encontra uma informação na memória. Assim, um acesso através de um cache hit é mais rápido do que através de um cache miss.

Uma simples rede (LAN), como a exemplificada acima, é suficiente para comportar um banco de dados relacional (DBMS) de tecnologia Cliente/Servidor (C/S) como por exemplo o Oracle.

Em linhas gerais, esta tecnologia tem como característica principal a divisão de tarefas entre o cliente, a estação de trabalho que ordena através das aplicações o acesso aos bancos de dados, e o servidor, que executa tarefas, tais como: atualizações, deleções, procura de dados e todas as outras tarefas próprias do gerenciamento de banco de dados, porém, sob as ordens da estação de trabalho (Cliente).

A vantagem é evidente: dividindo o processamento em dois sistemas, temos de saída a diminuição do tráfego de dados na rede. Com isto, o desempenho aumenta pois evitaremos de processar os dados, fazendo-os transitar pela rede, entre a estação de trabalho e o servidor, pelo menos duas vezes. Ao invés disso, armazenamos os dados variáveis do processo em alguns parâmetros e os enviamos ao servidor.

Estes ao chegarem são recepcionados pelo Oracle que os envia para Stored Procedure, que então inicia o processamento desejado até seu final de dentro do servidor, limitando-se a avisar a estação de trabalho o término do processo, com sucesso ou não. Porém, nem tudo são flores, existem também as desvantagens e a principal delas é o fato das estações de trabalho (Clientes) se localizarem em pontos geográficos distantes do servidor.

Embora este problema possa hoje ser minimizado pela adoção das arquiteturas de processamento distribuído, por outro lado não sem um considerável investimento em equipamentos, aplicativos auxiliares e a contratação de especialistas. Este investimento acompanhado de despesas de manutenção constantes embora não signifique propriamente um retorno aos custos de um computador de grande porte, é porém um gasto significativo e que dependendo do tamanho e da complexidade da rede podemos até alcançar os custos de um grande porte.

3.1 – Separação das Tarefas de Solicitação e processo

A primeira efetuada pela estação de trabalho e a última é feita no servidor, ou seja: as tarefas de tratar e manipular os dados. Como já dissemos o tráfego na Rede diminui sensivelmente, pois só é entregue os dados necessários solicitados pela pesquisa do cliente, e estes depois de tratados são atualizados ao final da transação no servidor. Ao contrário dos Sistemas de Bancos de Dados sem a tecnologia Cliente/Servidor, que disponibiliza todo o banco de dados, indiferente a necessidade quando da solicitação pelo Cliente. A tecnologia Cliente/Servidor é antes de tudo uma incrementadora de performance sem igual.


3.2 – Independecia da Estação de trabalho

Os usuários não ficam restritos a um tipo de sistema ou plataforma.

3.3- Preservação da Integridade dos dados

Mesmo quando são efetuados Back-ups em tempo real ou até a encriptação dos dados. Nestes casos o DBMS, ultiliza o espelhamento dos dados enquanto eles são acessados, gravando sempre a última fotografia dos dados antes da cópia de segurança.

3.4- Processamento de transações.

A grande vantagem deste método e guardar durante um certo tempo tempo as modificações efetuadas no Banco de Dados. Podendo, recuperá-las em caso de queda de energia ou mesmo quando o usuário do Banco desiste da modificação.

Desvantagens: 1- A maior delas é o aumento do custo administrativo e a contratação de pessoal especializado para dar suporte e manter o Banco de Dados sempre ativo. Nasce o profissional Administrador de Bancos de Dados (DBA).

2- O aumento do custo de hardware, também é significativo, pois parte integrante desta tecnologia Cliente/Servidor, exige a distribuição do processamento, quando a rede for grande.

3- Quando da utilização do Processamento Distribuído a complexidade aumenta, o número de equipamentos diversos também aumenta, e nem sempre podemos encontrar profissionais no mercado com um conhecimento tão diversificado

3.5 – Utilitários Oracle

Para manipular e administrar as estruturas de Bancos de Dados Relacionais criadas no Oracle10g, A Oracle possui um ambiente com algumas ferramentas que veremos abaixo:

SQL (Structured Language Query): Linguagem padrão, extremamente simples e faz a maior e mais expressiva parte do trabalho de criação e manutenção de estruturas de dados. Porém sua limitação é não ser procedural, ou seja, não permite agrupar as palavras chaves sob a forma de programas executáveis. É uma linguagem puramente interativa de construção e submissão de comandos individuais, embora os comandos sejam macro comandos muito poderosos.

SQL*PLUS: É o ambiente que permite tornar procedural os comando individuais do SQL. Este ambiente é composto, como veremos a seguir de um editor de textos, que permite reunir grupos de frases SQL, que podem ser gravadas sob a forma de arquivo e então executadas.


ORACLE NAVIGATOR: Conjunto de recursos por intermédio telas(forms), onde o desenvolvedor do Baco de Dados, cria, altera e exclui objetos. De forma que possa administrar a manutenção de objetos da sua Base de Dados.

PL/SQL: É a linguagem procedural do SQL do ORACLE, composta essencialmente de todos os comandos SQL padrão e mais um grupo adicional que permite utilizar o SQL de forma procedural. Ao ser acionado com um duplo click, o editor é ativado solicitando para sua operação a identificação do usuário e seu código de acesso, seguido do “drive” lógico, que no caso do uso “Stand Alone”, foi convencionado 2: Caso estivermos trabalhando em uma rede local o drive lógico seria por exemplo o X:, mais as informações da localização física do Banco de Dados.

Gerenciando Usuários no Oracle 10g

O Oracle 10g gerencia e controla a segurança dos objetos criados em cada conta de usuários. Isso inclui:

• Clusters • Índices • Tabelas • Views • Sequences


Cada banco de dados Oracle possui uma lista de usuários válidos, identificados por USERNAMES.

Todos os usuários são cadastrados no Dicionário de Dados do Banco em tabelas e views consultados pelo DBA. Quando o usuário do Banco de Dados é criado, um Schema correspondente com mesmo nome é criado para o usuário.

Um Schema é o conjunto de informações sobre o USERNAME. Isso inclui:

• Username • Password • Privilégios permitidos • Tablespaces de seus objetos • Quotas nas Tablespace • Profile • Role

Agora que já entendemos o que vem a ser um usuário no Oracle, veremos como criar, alterar, excluir e monitorá-los.

Criando um novo usuário: SQL> CREATE USER [Usuário] IDENTIFIED BY [Senha/Externally/Globally as] DEFAULT TABLESPACE [Nome Default] TEMPORARY TABLESPACE [Nome Temporária] PROFILE [Nome Profile] QUOTA [K/M/Unlimited] ON [Tablespace] PASSWORD EXPIRE ACCOUNT [Lock/Unlock] Onde: • Usuário - Nome do usuário a ser criado. • Senha - Especifica a senha do usuário. • Externally - Verifica o acesso do usuário através do sistema operacional. • Globally As - Especifica que o usuário será autenticado por um sistema externo de Gerenciamento de Segurança (Oracle Security Server) ou outro Sistema de Gerenciamento de autenticação. • Default Tablespace - Identifica a Tablespace onde serão criados os objetos dos usuários. • Temporary Tablespace - Identifica a Tablespace para segmentos temporários. • Profile - O nome do Profile associado ao usuário. • Quota - Especifica o valor da quota na Tablespace • Unlimited - Permite ao usuário alocar espaço dentro de uma Tablespace sem limites. • On - Especifica o nome da Tablespace cujo espaço será controlado peça Quota. • Password Expire - Torna a senha do usuário extinta, solicitando uma nova senha no próximo login. • Lock - Desabilita o login. • Unlock - Habilita o login.


Exemplo: SQL> CREATE USER SILVESTRE IDENTIFIED BY IPED DEFAULT TABLESPACE User_Data TEMPORARY TABLESPACE User_Temp PROFILE [Nome Profile] QUOTA 15M ON User_Data QUOTA 10M ON User_Temp PASSWORD EXPIRE ACCOUNT Unlock PROFILE Default;

Alterando um Usuário:

SQL> ALTER USER <Usuário> <Opções a serem alteradas> <Novo Valor> DEFAULT TABLESPACE [Nome Default] Exemplo: SQL> ALTER USER SILVESTRE QUOTA 5M ON User_Data;

Excluindo um Usuário:

<Opções a serem alteradas> <Novo Valor>

DEFAULT TABLESPACE [Nome Default]

Onde:

CASCADE Permite a exclusão de todos os objetos associados ao usuário. Essa opção somente será usado em raras exceções. Quando o usuário é excluído com a opção CASCADE, o Username e seu Schema associado são removidos do Dicionário de Dados e todos objetos contidos no usuário são imediatamente excluídos.

Exemplo:

Monitorando Usuários: O Oracle armazena, no Dicionário de Dados, informações completas de todos os usuários do banco.


Views do Dicionário de Dados: • DBA_USERS - Descreve todos os usuários do Banco de Dados • ALL_USERS - Lista os usuários visíveis ao usuário atual, mas não os descreve • USER_USERS - Descreve somente o usuário atual • DBA_TS_QUOTAS - Descreve as quotas da Tablespace • USER_TS_QUOTAS - Descreve as quotas da Tablespace • USER_PASSWORD_LIMITS - Descreve os parâmetros do perfil da senha que são atribuídos ao usuário • USER_RESOURCE_LIMITS - Indica os limites do recurso para o usuário atual • DBA_PROFILES - Indica todos os perfis e seus limites • RESOURCE_COST - Lista o custo para cada recurso • VSESSION - Lista a informação da sessão para cada sessão atual, incluí o nome do usuário • VSESSTAT - Lista as estatísticas da sessão do usuário • PROXY_USERS - Descreve os usuários que podem assumir a identidade de outros usuários

Todas as consultas às tabelas ou visões do Dicionário de Dados só serão possíveis com privilégio adequado.

Exemplo: Mostrando informações dos usuários, a partir do Dicionário de Dados:


Mostrando informações sobre a quantidade de espaço que um usuário pode usar nas Tablespaces, a partir do Dicionário de Dados: SQL> SELECT * FROM DBA_TS_QUOTAS WHERE USERNAME =’SILVESTRE’;

Como usar comando SQL.

Vamos ao exemplo de como criar uma tabela, observe os detalhes em relação aos parênteses, nome das colunas ,data type e constraints.

Após criarmos a tabela vamos inserir dados a mesma, em um comando INSERT


Veja acima que depois de fazer um insert e preciso um COMMIT para validar.

Inserindo Registros na Tabela Criada Usando o cmdo INSERT.


Outro Exemplo de Como Criar uma Tabela:


Inserindo Valores na Nova Tabela

Vamos fazer um delete:


Fazer um update, mas veja abaixo os dados da tabela.

Veja o Update e o resultado alterado.


Veja os dados da nova tabela.

Observe um select de um determinado numero da coluna acima usando a clausula WHERE.


Shrink segmentos em objetos

A nova versão do Oracle 10g disponibilizou o conhecido comando para encolhermos os segmentos de dados alocados em alguns objetos,denominado SHRINK SPACE. Quando utilizado, conseguimos obter uma considerável melhora na performance de alguns comandos SQL e também reduzimos a fragmentação do banco de dados. Vejamos então, como utilizá-lo.

Para utilizar a opção de SHRINK SPACE em alguns objetos, devemos configurar o parâmetro COMPATIBLE com valor igual ou superior a 10.0.0 no arquivo de parâmetros SPFILE.

SQL>ALTER SYSTEM SET COMPTATIBLE=10.0.0 SCOPE=SPFILE;

Configurando parâmetro COMPATIBLE no arquivo de parâmetros SPFILE. Este procedimento requer o reboot da instance. O usuário que fará a execução do comando necessitará dos direitos de ALTER object. A tablespace onde reside a tabela a ser encolhida, deve ser AUTO SEGMENT SPACE MANAGEMENT.

É possível executar a operação de SHRINK SPACE nos seguintes objetos:

Tabela Indice Lob View Materializada IOT

Como proceder

Para utilizarmos o SHRINK SPACE em uma determinada tabela, devemos inicialmente, executar o comando abaixo, para habilitar o SHRINK SPACE.

SQL> ALTER TABLE SILVESTRE.ALUNO ENABLE ROW MOVEMENT;

Tabela Alterada.

O Comando SHRINK SPACE possui as seguintes opções:

Sem opção – Encolhe os segmentos da tabela e a High Water Mark

SQL> ALTER TABLE SILVESTRE.ALUNO SHRINK SPACE;

Tabela Alterada.

COMPACT – Encolhe os segmentos mas não reduz a High Water Mark

SQL> ALTER TABLE SILVESTRE.ALUNO SHRINK SPACE COMPACT;

Tabela Alterada.

CASCADE – Encolhe os segmentos da tabela, a High Water Mark e todos os índices dependentes.


Também é possível, encolher os segmentos não utilizados por índices, utilizando a sintaxe abaixo:


Conclusão

Shrink Space pode ser utilizado de forma online, porém no momento de realocar os segmentos, será efetuado um lock exclusivo, podendo ocorrer erros em sua aplicação! Desta forma, agende esta tarefa fora do horário normal de funcionamento desta tabela.

Monitorando o uso de índices

Quando desenhamos um sistema, implementamos índices em tabelas para obtermos uma performance no uso da aplicação, porém, por muitas vezes, estes índices não são utilizados e acabam atrapalhando a performance das aplicações que utilizam o banco de dados Oracle, utilizam espaço em disco desnecessário, aumentam o everhead das operações DML.

Diante disso, é possível identificarmos se um índice criado em uma tabela está sendo utilizado ou não. Vejamos como fazer isto.

A verificação da utilização de um índice em uma determinada tabela é efetuada através da ativação do monitoramento do índice, onde identificamos se um determinado índice está ou não sendo utilizado. A sintaxe utilizada para ativar o monitoramento de um índice é:

ALTER INDEX INDEX_NAME MONITORING USAGE

A partir deste ponto, o Oracle irá armazenar todas as vezes que o índice foi utilizado, nesta sessão. Para visualizar se o índice está sendo utilizado na sessão, utilize a view do dicionário de dados denominada V$OBJECT_USAGE. Exemplo:

SQL> SELECT INDEX_NAME, USED FROM V$OBJECT_USAGE;

INDEX_NAME USED --------------------------------------------------------------- IDX_02 YES IDX_01 NO

Observe que a consulta efetuada na sessão onde os índices IDX_02 e IDX_01 foram ativados, apresentam os valores YES e NO. Desta forma, foi possível identificar que o índice IDX_02 está sendo utilizado pelas consultas executadas na sessão durante o monitoramente, porém o índice IDX_01 não foi utilizado.

Toda vez que iniciar a monitoração de um índice, a view V$OBJECT_USAGE será redefinida, ou seja, os dados referentes monitorações de índices anteriores serão excluídos.

Para desativar o monitoramento do índice, execute a seguinte sintaxe:

ALTER INDEX INDEX_NAME NOMONITORING USAGE;

Antes de tomar qualquer ação no banco de dados, certifique-se que o período monitorado foi suficiente para colher as informações necessárias de verificação de uso do índice! Mantenha sempre seu backup do banco de dados atualizado e testado, assim como os scripts de criação dos objetos( índices por exemplo ), caso você tenha que restaurá-lo em uma situação emergencial!


Data Guard: Pre-Requisitos do DGMGRL

Um dos pre-requisitos para uso do DGMGRL é que os bancos primário e modo espera (standby) já tenham sido criados. O parâmetro de inicialização tem que ser modificado para TRUE em todos os bancos da configuração Data Guard. Além disso é obrigatório o uso de arquivos SPFILE ao invés de arquivos PFILE.

Para converter arquivos de parâmetros de inicialização de banco (PFILE) em arquivos SPFILE, execute no SQL*Plus o seguinte comando:

CREATE SPFILE FROM PFILE=’nome_file’;

Se as instâncias de banco foram anteriormente iniciadas sem o uso do SPFILE, reinicie essas instâncias utilizando-o.

Em seguida modifique o parâmetro de inicialização DG_BROKER_START para TRUE, utilizando om comando ALTER SYSTEM. Essa modificação é salva no arquivo SPFILE. Da próxima vez que a instância de banco foi iniciada, não será necessário modificar esse parâmetro novamente.



Tabelas Temporárias

Tabelas Temporárias são úteis em aplicações onde os dados necessitam ser preservados durante uma ou diversas transações dentro de uma sessão.

Uma tabela temporária possui praticamente as mesmas caracteristicas de uma tabela permanente. A diferença é que os dados são vistos somente pelo usuário dono da sessa que inseriu os dados. Esse dados são descartados ao encerrar a sessão do usuário.

Utilize o comando CREATE GLOBAL TEMPORARY TABLE para criar tabelas temporárias. A cláusula ON COMMIT define se os dados da tabela são exclusivos da transação (CREATE GLOBAL TEMPORARY TABLE … ON COMMIT DELETE ROWS) ou da sessão (CREATE GLOBAL TEMPORARY TABLE … ON COMMIT PRESERVE ROWS).

Podem ser criados em tabelas temporárias e a duração dos dados do índice depende da duração dos dados da tabela temporária.

Por definição, tabelas temporárias são criadas em tablespaces temporárias. Entretanto o DBA pode definir uma tablespace. Utilize este recurso se os segmentos da tabela temporária tiverem um crescimento não compatível os da tablespace temporária.

Os dados de uma tabela temporária, por definição, são temporários. Backups e recuperação de dados dessas tabelas são estão disponíveis em uma eventual falha de sistema.

Visão Geral do Oracle ASM

Automatic Storage Manager (ASM) é um gerenciador de volumes e ao mesmo tempo um sistema de arquivos para banco de dados Oracle o qual suporta configurações do tipo single-instance e RAC. O ASM é uma solução alternativa


de gerenciamento de volume de discos, sistemas de arquivos e raw devices.

O ASM utiliza agrupamento de discos para armazenar arquivos de dados; um ASM disk group nada mais é do que uma coleção de discos os quais o ASM gerencia como se fosse apenas uma unidade de disco. Dentro de um disk group, os arquivos de banco de dados Oracle são apresentados em uma interface semelhante ao sistema de arquivos unix e linux. O conteúdo dos arquivos são eventualmente redistribuidos para evitar gargalos e garantir estabilidade de desempenho. Seu desempenho é semelhante ao desempenho de raw devices.

Você pode adicionar ou remover discos de um disk group sem interromper o serviço de banco de dados. Quando você remove ou adiciona discos de um disk group, o ASM automaticamente redistribui os arquivos e, conseqüentemente elimina a necessidade de parada de serviços para redistribuição de conteúdos.

O gerenciador ASM possui flexíveis opções de espelhamento. ASM normal e alta redundância de disk groups, espelhamentos tipo two-way e three-way respectivamente. Permite o uso de redundância externa do tipo RAID.

O ASM também utiliza o Oracle Managed Files (OMF) para simplificar o gerenciamento de arquivos banco de dados. O OMF automaticamente cria os arquivos em sua respectivas pastas. Além disso, atribui nomes aos arquivos e remove-os, defragmentando áreas de disco, quando as tablespaces ou arquivos são excluídos.

O ASM simplifica as tarefas de administração de storage consolidando os dados de storage em um reduzido grupo de discos. Isso possibilita a unificação do storage para diversos bancos de dados e oferece melhorias de desempenhos dos processos de leitura e gravação em discos. Os arquivos ASM podem ser configurados com outros gerenciadores de storage , como raw devices e sistemas de arquivos de terceiros. Isto simplifica a integração do ASM com os demais sistemas de armazenamento já existentes.

Buffer Cache, Shared Pool e o Log Buffer

É bem verdade que as interfaces GUI como o Spotlight, o Database/Grid Control(10g), o OEM(9x) entre outras, são muito úteis, e facilitam em muito a identificação de problemas de performance. Mas, como nem sempre teremos essas ferramentas à mão, é interessante saber utilizar as visões V$ para identificar problemas de performance.

Por isso, nesse artigo iremos falar um pouco da utilização de views para realizar o ajuste do BUFFER CACHE, SHARED POOL e LOG BUFFER. Buffer Cache

O buffer cache é utilizado para armazenar os blocos lidos a partir dos discos. Significa que um buffer cache pequeno irá fazer com que o Oracle precise remover do cache os blocos de dados seguindo a lista LRU (LAST RECENTLY USED), e dependendo da frequência com que isso acontece, poderá gerar uma queda na performance.

Não existe uma mágica para dimensionar o buffer cache, o que normalmente se faz é estimar um tamanho inicial e monitorar o acerto, caso não esteja dentro do ideal, você precisará aumentar e repetir o ciclo de monitoramento.

Um detalhe importante é que quando a instância é inicializada, o buffer cache está vazio, portanto, qualquer consulta irá gerar misses no buffer. Significa dizer que validar as taxas de acerto no buffer logo após o startup é errado, você provavelmente terá uma taxa de acerto muito baixa. O buffer é calculado usando a seguinte fórmula:


1 - (physical_reads/(db_block_gets consistent_gets))

consistent gets é o número de vezes que uma leitura consistente foi requisitada para um bloco do buffer cache.

db block gets from é o número de vezes que um bloco foi requisitado para o buffer cache. physical reads é o número total de blocos de dados lidos do disco para o buffer cache.

SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS, (PHYSICAL_READS / (DB_BLOCK_GETS CONSISTENT_GETS)) "Hit Ratio" FROM V$BUFFER_POOL_STATISTICS;

NAME PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS Hit Ratio --------------- -------------- ------------- --------------- ---------- DEFAULT 2382927 85639921 46004325 .981898738

1 row selected.

No exemplo acima, a taxa de acerto foi de 98 no buffer cache.

Uma consulta semelhante pode ser feita na V$SYSSTAT:

O buffer cache também pode ser ajustado com base na view VDB_CACHE_ADVICE. Para que essa view seja populada é necessário que o parâmetro DB_CACHE_ADVICE esteja ON.


A declaração abaixo consulta a respectiva view, retornando estimativas de buffer e de acerto.


Lembrando que, quando falamos de memória, estamos falando de memória física, um servidor Oracle, não deve fazer swap.

Para utilizar o buffer cache de forma eficiente, as declarações SQL da aplicação devem estar ajustadas para evitar consumo desnecessário de recursos. Isso é feito verificando as declarações SQL executadas com mais freqência e as que fazem uso de uma maior quantidade de buffers.

A consulta abaixo retorna as 50 maiores consultas consumidoras de BUFFERS.

SELECT * FROM (SELECT SQL_FULLTEXT, BUFFER_GETS FROM V$SQL ORDER BY BUFFER_GETS DESC) WHERE ROWNUM <= 50

Existem duas formas de melhorar o acerto no buffer: • Otimizando as consultas de forma a retornarem menos blocos, e dessa forma utilizar menos buffer. • Aumentando o buffer cache.


Detalhes do Exercício

Pergunta 1: O que podemos obter ao utilizar o comando SHRINK SPACE?

Sua resposta:O desempenho aumenta pois evitaremos de processar os dados, fazendo-os transitar pela rede, entre a estação de trabalho e o servidor, pelo menos duas vezes.

Resposta Correta:Uma considerável melhora na performance de alguns comandos SQL e também reduzimos a fragmentação do banco de dados.

Explicação:

A nova versão do Oracle 10g disponibilizou o conhecido comando para encolhermos os segmentos de dados alocados em alguns objetos,denominado SHRINK SPACE. Quando utilizado, conseguimos obter uma considerável melhora na performance de alguns comandos SQL e também reduzimos a fragmentação do banco de dados.

Pergunta 2: Onde podemos usar as Tabelas Temporárias?

Sua resposta:Nas aplicações onde os dados necessitam ser preservados durante uma ou diversas transações dentro de uma sessão.

Resposta Correta:Nas aplicações onde os dados necessitam ser preservados durante uma ou diversas transações dentro de uma sessão.

Explicação:Tabelas Temporárias são úteis em aplicações onde os dados precisam ser preservados durante uma ou diversas transações dentro de uma sessão.

Pergunta 3: O que é o Automatic Storage Manager?

Sua resposta:É um gerenciador de volumes e ao mesmo tempo um sistema de arquivos para banco de dados Oracle o qual suporta configurações do tipo single-instance e RAC.

Resposta Correta:É um gerenciador de volumes e ao mesmo tempo um sistema de arquivos para banco de dados Oracle o qual suporta configurações do tipo single-instance e RAC.

Explicação:

Automatic Storage Manager (ASM) é a ferramenta que administra volumes e ao mesmo tempo um sistema de arquivos para banco de dados Oracle o qual suporta configurações do tipo single-instance e RAC. O ASM é uma solução alternativa de gerenciamento de volume de discos, sistemas de arquivos e raw devices.

Shared Pool

O Oracle utilize a SHARED POOL para armazenar declarações PL/SQL e SQL, dados do dicionário entre outros.

Da mesma forma que o BUFFER CACHE, é impossível determinar um tamanho inicial para uma base nova. Você deve seguir o mesmo principio do BUFFER CACHE, colocar um valor e avaliar o ambiente. Lembrando que a SHARED POOL inicia vazia, e à medida que os usuários vão submetendo as declarações SQL ela vai sendo preenchida.

Para isso, observe o seguinte:

• Utilize sempre que possível bind variables ao invés de caracteres literais nas declarações. Isso faz com que o Oracle armazene apenas uma declaração SQL. As declarações, apesar de semelhantes, ocupam duas áreas distintas na SHARED_POOL:

Substitua: SELECT employee_id FROM employees WHERE department_id = 10; SELECT employee_id FROM employees WHERE department_id = 20;

Por: SELECT employee_id FROM employees WHERE department_id = :dept_id;

• As aplicações devem evitar os usuários possam criar suas próprias instruções.


• Crie padrões para as bind variables e para os espaços nas declarações SQL blocos de PL/SQL. Por exemplo:

SELECT employee_id FROM employees WHERE department_id = :dept_id

É diferente de:

SELECT employee_id FROM employees where department_id = :dept_id

O objetivo do tuning na SHARED_POOL é fazer com que uma declaração SQL que está no cache possa ser reutilizada o maior número de vezes possível.

Utilize a declaração abaixo para identificar a taxa de hit ratio da shared pool:

A consulta mostrou que 99,65 dos códigos de SQL e PLSQL estão sendo reaproveitados.

A declaração abaixo mostra a quantidade de bytes livres na SHARED_POOL.


A consulta abaixo também auxilia na descoberta da taxa de acerto da SHARED POOL.


Também é possível utilizar a view V$SHARED_POOL_ADVICE. Para isso é preciso que o parâmetro STATISTICS_LEVEL esteja configurado como ALL ou TYPICAL. show parameter statistics_level;

statistics_level string TYPICAL

A saída acima mostra que o tamanho da shared pool é de 3922M. Mostra também que, se o tamanho da shared pool fosse ajustado para 3072M, teria a mesma eficiência.Log Buffer

Aplicações que inserem, modificam ou excluem um grande volume de registros normalmente não utilizam o tamanho default de log buffer. Apesar do tamanho do log buffer ser bem menor frente ao tamanho total da SGA, ele tem grande impacto na performace de sistemas que realizam atualização no volume dos dados.

Um tamanho inicial para o log buffer é:

MAX(0.5M, (128K * número de CPUs))

A maioria dos sistemas que possuem log buffer maior que 1M não possuem ganhos de performance.

A análise da performance do log buffer é feita por intervalo. Deve ser coletado em intervalos, e verificar se existe um aumento do valor. O ideal é que não existam alterações.


Se o valor aumentar de forma consistente, é necessário ajustar o tamanho do log buffer.

Arquived Logs

Neste Tópico iremos falar dos ARCHIVED LOGS. Compreenderemos sua utilidade, como habilitá-lo e daremos alguns exemplos de como eles podem ser úteis. A maioria dos SGDB"s possuem um mecanismo de log, que armazena todas as alterações realizadas no base de dados, como por ex: insert"s, update"s, delete"s, create table. Esses eventos vão preenchendo esses arquivos de log. No Oracle, por default, são criados 3 grupos de redologs, cada grupo com 3 membro. A consulta abaixo, mostra a existência de 3 grupos, cada grupo com um 2 membro.


Esta outra consulta, mostra quem são esse membros, e onde eles estão armazenados.

A utilização desses REDO LOGS é cíclica, significa dizer que, quando um REDO LOG estiver cheio, o Oracle utilizará o seguinte. No exemplo acima o GROUP 1 está CURRENT. Como ele é o último, quando estiver cheio, o banco voltará a utilizar o GROUP 2, e simplemente irá sobrescrever, se efetuar nenhuma cópia do arquivo de log INACTIVE.

Os archives se, quando configurados, fazem com que o Oracle realize uma cópia para que possa ser utilizada posteriormente em operações de BACKUP e RECOVER antes de sobrescever o REDOLOG.

No exemplo acima, a base de dados está no modo NO ARCHIVE , e a localização default de arquivamento está %ORACLE_HOME%RDMS .

O parâmetro LOG_ARCHIVE_FORMAT é utilizado para formatar o filename do archive, normalmente o formato ARC%S_%R.%T é suficiente.

Iremos então mudar o lugar do armazenamento e em seguida habilitar archive log. Podemos ter até 10 locais diferentes de armazenamento.

Para alterar o modo para ARCHIVE LOG, devemos colocar a base de dados em modo EXCLUSIVE, utilizando o comando STARTUP MOUNT EXCLUSIVE .

Em seguida, utilizando o comando ALTER DATABASE ARCHIVELOG , vamos habilitar o arquivamento dos logs.

O comando ARCHIVE LOG LIST, agora mostra a base em modo ARCHIVE.

Se quiser confirmar a correta configuração, utilize o comando ALTER SYSTEM SWITCH LOGFILE, para forçar o arquivamento do log.

Em versões anteriores a 10g, era necessário setar o parâmetro LOG_ARCHIVE_START para TRUE .


Agora que habilitamos o ARCHIVE, vamos entender como ele pode nos ajudar a manter o ambiente.

Imagine um ambiente que funciona 8(horas)x(5)dias, quem em hipotese alguma poder existir a perca de informações, quando muito, aceita-se a perca de 30 minutos.

Se sua base está em modo NO ARCHIVE, e seu HD foi para o espaço, logo no final do dia, a única coisa que te resta, é fazer o restore FULL do último backup, e torcer para que ele esteja consistente. Imaginando que vc fez o backup na noite anterior, você vai perder ALÉM DO EMPREGO, 1 dia de movimento.

Com o ARCHIVE e um pouco de sorte, perderia apenas os REDOLOGS que não haviam sido arquivados ainda.

Por isso, aconselha-se a não colocar os archives no mesmo device da base de dados (CONTROLFILES, REDOLOGS, DATAFILES), além de que esse processo gera uma carga de I/O adicional.

Tablespace Temporária

Tablespace Temporária, um ponto que pode chegar a virar um grande problema para o DBA ou desenvolvedor da empresa.

A Tablespace Temporária, ou como nós conhecemos, TEMP, é utilizada para armazenar informações de ordenação (SORT) ou para armazenar dados de tabelas temporárias (CREATE TEMPORARY TABLE). A principio, a Tablespace Temporária tem seu lugar físico reservado no servidor, determinado pelo DBA, porém, sua principal função no banco de dados é auxiliar a memória do Oracle (SGA), em seu principal componente, o SORT_AREA_SIZE.

Porque a Tablespace Temporária auxilia a memória do Oracle? Muita gente não sabe é que comandos como CREATE INDEX, ANALYZE, SELECTS com as funções DISTINCT, GROUP BY, ORDER BY, UNION, INTERSECT, MINUS, Junções de tabelas com HASH e MERGE irão utilizar a tablespace Temporário, coisa que muitos DBAs e Desenvolvedores e usuários utilizam em seu dia-a-dia. Imagine o tamanho que teríamos que ter em memória para poder armazenar criação de índices de tabelas de 100GB, ou melhor, imagine um usuário dentro de um Data Warehouse fazendo um SELECT com junção MERGE de duas tabelas de 300 Milhões de Linhas e outra de 500 Mil linhas. O Oracle nunca irá conseguir ordenar isso em memória, e quem irá fazer esse trabalho no lugar do SORT_AREA_SIZE será a nossa Tablespace Temporária. Percebe-se que quando se cria um usuário no banco de dados, sempre devemos especificar uma Tablespace Temporária (TEMPORARY TABLESPACE), isso significa que quando esse usuário executar qualquer comando que precise de SORT_AREA, peça ajuda para a Tablespace Temporária vinculada a esse usuário.

Criando e Gerenciando a Tablespace Temporária

Agora que conhecemos um pouco da Tablespace Temporária, vamos criar uma desde o início, lembrando que já deve existir uma Tablespace Temporário padrão, chamado TEMP, então mude o nome da nova tablespace.

Create temporary tablespace TEMP Tempfile ‘X:ORACLETEMP.DBF’ size 500m Autoextend on Next 100M Maxsize 2000M Extent management local Uniform size 100M;


Percebe-se que os comandos para criação da tablespace temporária é UM POUCO diferente do convencional, para Tablespaces de dados, notamos que na linha dois existe uma diferença que pode confundir muita gente, o TEMPFILES.

O TEMPFILES especifica que o arquivo DBF que está no servidor será de uso TEMPORARIO, podendo ou não ocupar toda sua capacidade.

Exemplo imaginamos que temos um Filesystem de 20GB, e estou criando uma outra tablespace temporária, chamada TEMP2. Quando eu crio minha tablespace especificando o tamanho, exemplo 10GB. No sistema operacional (Exemplo SOLARIS), irá acusar que o DBF é de 10GB, porém não irá ocupar esse espaço efetivamente. Com isso podemos ter problemas. Se eu criar mais 2 tempfiles de 10GB, o Oracle irá permitir a criação e o sistema operacional também. Notamos que já temos 30GB alocados. Agora que irá começar o problema, quando seu banco de dados começar a transacionar ou o usuários trabalharem muito com SORT, esse espaço temporário irá crescer, crescer, e crescer que começar aparecer ERRO DE I/O para o usuário. Com isso ele irá acionar o DBA.

Outro problema básico que alguns administradores enfrentam é quando procura pela Tablespace Temporário na view dinâmica DBA_DATA_FILES, é sempre válido lembrar que no Oracle nós temos duas opções de views, a DBA_DATA_FILES que mostra todos os datafiles de dados do banco de dados e o DBA_TEMP_FILES que mostra os datafiles “TEMPORARIOS”, que dizer, que faz parte de tablespaces temporárias.

Gerenciando minha Tablespace Temporária on-line

No Oracle temos algumas facilidades de manusear os arquivos temporários, utilizando comandos simples, veja:

Caso queira dropar uma tempfile pois o tamanho está exagerado siga os passos abaixo :

1 – Criar novo tablespace temp

Create temporary tablespace TEMP_2 Tempfile ‘X:ORACLETEMP_2.DBF’ size 500m Autoextend on Next 100M Maxsize 2000M Extent management local Uniform size 100M;

Tablespace created.


2– Consultar usuarios

SQL>spool c: este1.sql SQL> Select alter user ||username|| temporary tablespace temp_2; from dba_users;

alter user’||username||’temporary tablespace temp_2; (tirar cabeçalho para poder rodar) ------------------------------------------------------------------ Alter user SYS Temporary tablespace temp_2; Alter user SYSTEM Temporary tablespace temp_2; Alter user OPS$ORACLE Temporary tablespace temp_2; Alter user OPS$BACKSINA Temporary tablespace temp_2; Alter user CORRWIN Temporary tablespace temp_2; Alter user FUNDOWIN Temporary tablespace temp_2; Alter user CARTEIRAWIN Temporary tablespace temp_2; Alter user ZAPCNT Temporary tablespace temp_2; Alter user CONSULT Temporary tablespace temp_2; Alter user CONSULTING Temporary tablespace temp_2; Alter user ACOESWIN Temporary tablespace temp_2; Alter user CUSTWIN Temporary tablespace temp_2; Alter user OUTLN Temporary tablespace temp_2; SQL>spool off;

O resultado do arquivo deve ser rodado, o resultado do select acima tirando o cabeçalho e salvar como teste1.sql . Rodar o arquivo teste1sql com spool teste2.sql

Alter user SYS Temporary tablespace temp_2; User altered. Alter user SYSTEM Temporary tablespace temp_2; User altered. Alter user OPS$ORACLE Temporary tablespace temp_2; User altered. Alter user OUTLN Temporary tablespace temp_2; User altered.

3– SQL> alter database default temporary tablespace TEMP; database altered. Obs : esse comando vai apontar o tablespace atual.

4– Faça um consulta para verificar se esta todos os usuários como temp_2; SQL> select username, temporary_tablespace from dba_users;

5 – Dropar o tablespace temp antigo SQL> drop tablespace TEMP including contents; Tablespace dropped.


Gerenciando o Crescimento

Existe um meio eficaz de gerenciar o crescimento da tablespace temporária durante alguns processos de banco de dados, isso será através da view v$sort_usage, porém antes, devemos saber qual o tamanho do bloco de dados do banco de dados, e para isso precisa de uma consulta simples:

O SQL*PLUS irá retornar o tamanho que sua instância está usando. No nosso exemplo, no nosso exemplo, o db_block_size é 8172 bytes (8KB).

Um select para ajudar os DBAs.

O resultado é o tamanho total que está sendo ocupado dentro da tablespace Temporário, depois, poderá fazer um SELECT mais complexo e comparar o crescimento junto com o tamanho total da tablespace. Assim fica mais fácil para acompanhar.


Criando Bigfile Tablespaces no Oracle 10g

O Oracle 10g oferece a Bigfile Tablespace, ou seja, uma tablespace que pode suportar tamanhos superiores à 4GB. Agora você pode associar grandes datafiles a um Bigfile Tablespace que só pode ser gerenciado na modalidade locally managed. O tamanho máximo de um Bigfile varia com base no tamanho do bloco do banco de dados. Ele pode variar de 8 a 128 terabytes. Com um Bigfile você precisa gerenciar somente um data file por tablespace. Podendo suportar 8 exabytes em armazenamento.

criando um bigfile tablespace:

SQL> create bigfile tablespace Exemplo datafile /u02/oracle/data/exemplo01.dbf size 10G;

Você pode especificar o tamanho do bigfile tablespace em:

K – kilobytes

M – megabytes

G – gigabytes

T – terabytes

- Como posso alterar o tamanho de um Bigfile Ttablespace:

SQL> alter bigfile tablespace Exemplo RESIZE 8G;

ou

SQL> alter bigfile tablespace Exemplo AUTOEXTEND ON NEXT 5G;

- Como posso identificar os Bigfile Ttablespace:

As seguintes views possuem uma coluna BIGFILE que identificam a tablespace como uma Bigfile Tablespace:

- DBA_TABLESPACES - USER_TABLESPACES - V$TABLESPACE

Tablespaces

Como um banco de dados é um conjunto de arquivos de dados, é muito importante que você entenda como um banco de dados Oracle agrupa esses arquivos. Ele faz isso sob a proteção de um objeto de banco de dados chamado tablespace. Antes de inserir dados dentro de um banco de dados Oracle, primeiro você deve criar um tablespace e depois uma tabela dentro deste tablespace para conter os dados, então, uma tablespace é usada para agrupar outras estruturas lógicas relacionadas entre si.


O tamanho combinado dos arquivos de dados que formam uma tablespace ditam a sua capacidade de armazenamento. A combinação da capacidade de armazenamento de todas as tabespaces que formam um banco de dados forma a capacidade total de armazenamento desse banco de dados.

Uma tablespace pode estar acessível (on-line) ou não (offline), geralmente permanece on-line, disponível para os usuários. Entretanto para algumas tarefas administrativas ou em algumas situações especiais, é possível deixá-las offline.

Portanto, os dados de um banco de dados Oracle estão armazenados logicamente em tablespace e fisicamente nos arquivos de dados associados as tablespaces correspondentes. As tablespaces são usadas para:

• Controlar a alocação de espaço em disco para os dados de um banco de dados. • Assinalar quotas específicas de espaço para os usuários. • Controlar a disponibilidade dos dados. • Executar operações parciais de cópia e recuperação de um banco de dados. • Alocar o armazenamento dos dados entre diferentes dispositivos de armazenamento para melhorar a performace de um banco de dados.

O administrador de banco de dados pode criar novas tablespace, adicionar e remover arquivos de dados, configurar e alterar os parâmetros de armazenamento para os segmentos criados em uma tablespace e, naturalmente, pode removê-las sem maiores problemas.

Nomes de tablespace e conteúdo

Em um típico banco de dados existem algumas tablespaces padrões, mas lembre-se os nomes aqui discutidos são apenas uma cinvenção; não é obrigatório que o DBA da sua instituição os utilize. A função principal dos tablespaces é ajuda-lo a organizar seu banco de dados.

Tablespace System

O tablespace system é uma parte obrigatória de todo banco de dados Oracle. É onde o Oracle armazena todas as informações necessárias para o gerenciamento, como os nomes dos tablespaces e o que os arquivos de dados de cada tablespace contêm.

Tablespace Temp

O tablespace temp é onde o Oracle armazena todas as suas tabelas temporárias. É o quadro branco ou papel de rascunho do banco de dados. No caso de um banco de dados muito ativo, você pode ter mais de um tablespace temporário.

Tablespace Tools

O tablespace tools é onde você armazena os objetos de banco de dados necessários para suportar as ferramentas usadas com o banco de dados, como o SQL*PLUS, assim como qualquer aplicativo Oracle o SQL*PLUS precisa armazenar tabelas no banco de dados.


Tablespace Users

O tablespace users contém informações pessoais dos usuários.

Tablespace SYSAUX - No Oracle Database 10g, foi criada uma nova tablespace chamada SYSAUX. Esta tablespace é utilizada para armazenar uma série de informações relevantes para o funcionamento do banco de dados. Como o próprio nome sugere, ela é um auxiliar para a tablespace SYS e manterá uma série de informações de schemas específicos para o banco de dados.

Problemas com Espaço do UNDO

Alguma vezes a Tablespace UNDO fica com tamanho exagerado devido a não configuração correta ao limitar o tamanho dela. O bom e fazer esse procedimento fora do expediente para não causar algum trauma durante o dia.

Criar um novo tablespace UNDO

Create UNDO TABLESPACE UNDOTBS_02 DATAFILE ‘E:ORACLEORADATASIDUNDOTBS_02.DBF’ SIZE 200M AUTOEXTEND ON NEXT 5M MAXSIZE 200M;

alterar o tablespace para apontar para o novo

ALTER SYSTEM SET UNDO_TABLESPACE = UNDOTBS_02; Consulta para verificar se o undo esta online :

SELECT SEGMENT_NAME, STATUS, TABLESPACE_NAME from dba_rollback_segs WHERE STATUS=’ONLINE’ AND TABLESPACE_NAME =’UNDOTBS1’;

COLOCAR O TABLESPACE UNDO OFFLINE

ALTER TABLESPACE UNDOTBS1 offline;

Dropar a tablespace UNDOTBS1

Drop tablespace UNDOTBS1 including contents and datafiles;

CREATE UNDO TABLESPACE UNDOTBS1 DATAFILE ‘E:ORACLEORADATASIDundotbs.dbf’ SIZE 500M AUTOEXTEND ON NEXT 5M MAXSIZE 2000M ;

Alterar o tablespace para apontar para o UNDOTBS1

ALTER SYSTEM SET UNDO_TABLESPACE = UNDOTBS1;

Colocar offline o UNDOTBS_02

ALTER TABLESPACE UNDOTBS_02 offline; dropar undo UNDOTBS_02

drop tablespace UNDOTBS2 including contents and datafiles;


Obs : Verificar caso coloque o nome da Tablespace UNDO diferente do que esta no init.ora, caso esteja coloque o mesmo nome.

UNDO_TBS = nome da nova tablespace de undo que você criou

UNDO_MANAGEMENT = AUTO Para efetuar o startup do banco, no SQL*Plus, digite:

SQL> startup pfile=caminho completo do arquivo initSID.ora;

Depois de montado e aberto o banco, ainda no SQL*Plus

SQL> create spfile from pfile;

GRANT

O que são comandos para ceder privilégios para o sistema ou para objetos (cedido pelos donos do objeto). A utilização dos comandos GRANT é muito utilizado no trabalho do DBA, onde damos privilégios para usuários de redes visitar tal tabela ou utilizar apenas aquele objeto específico do database e não permitir acesso de outros usuários conectados na rede em nossas tabelas ou objetos. Os GRANT para objetos são autorizações para outros usuários a utilizar de forma específica o objeto escolhido, e para ceder o objeto, existe privilégios para o usuário onde o Oracle coloca a disposição o diversos privilégios, e vou citar apenas alguns mais utilizados:

Alter = Permite modificações nas tabelas ou sequences.

Exemplo: SQL > GRANT ALTER ON tabela TO usuario;

Index = Permite a criação de Index para as tabelas.

Insert = Permite a inclusão de linhas nas tabelas.

Update = Permite modificação nas linhas da tabela.

Delete = Permite que seja deletada linhas da tabela.

Select = Permite consulta na tabela.

Exemplo: SQL > GRANT Index, Insert, Update, Delete, Select ON tabela1 TO usuario1;

Read = Permite a leitura dos arquivos no diretório.

Write = Permita a gravação no diretório.

References = Autoriza a criação de restrições de integridade que façam referência a tabela ou view.

Exemplo: SQL > GRANT Read, Write, References ON DIRECTORY nome_diretorio TO usuario1;

Os GRANT de sistema são autorizações que o DBA fornece para o usuário fazer ações dentro do banco de dados, o pacote de privilégios de sistema é composto por Connect, Exp_Full_Database, Imp_Full_Database e DBA, ambos são "poderes" que o usuário poderá utilizar dentro do database, cada um dos privilégios citados acima vem com diversas opções de utilização.


Entendendo como os comandos GRANT de sistema funcionam dentro do database, vou relatar alguns exemplos de como ceder privilégios para o usuário fazer ações dentro do banco.

SQL > GRANT CONNECT TO usuario; SQL > GRANT CONNECT, DBA TO usuario; SQL > GRANT Exp_Full_Database, DBA, Imp_Full_Database, Connect TO usuario;

Agora depois de termos cedidos milhares de privilégios, vamos aprender também como retirar os privilégios dos usuários mal intensionado na rede, e para fazer isso temos umas linhas de comando bem simples, que acaba com a graça de todos.

SQL > REVOKE CONNECT FROM usuario; SQL > REVOKE CONNECT, DBA FROM usuario; SQL > REVOKE Exp_Full_Database, DBA, Imp_Full_Database, Connect FROM usuario;

Espero ter ajudado algumas pessoas que me mandaram e-mails dizendo como autorizar certos usuários no banco de dados e deixar outros de fora e ajudado o pessoal que está com dúvidas sobre o assunto.

Constraints

As CONSTRAINTS, nada mais são que restrições que você estabelece para uma coluna no banco de dados, e podem ter os seguintes tipos:

* Primary Key (PK) = Está restrição cria um índice único para um conjunto de colunas ou uma coluna para Chave Primaria.

* Unique = Está Contraint determina que uma coluna não poderá ter 2 linhas com o mesmo valor.

* Foreign Key (FK ou Chave Estrangeira) = Determina uma coluna ou um conjunto de colunas que possuem valores em outras tabelas, referente a uma referência ou um relacionamento.

* Check = Especifica a condição que a coluna precisa para salvar o registro.

* Not Null = Determina que a coluna tem preenchimento obrigatório.

Arquitetura de Armazenamento Lógico

Para começarmos a falar sobre este assunto, precisamos de um pequeno resumo sobre os quatro grandes componentes que compõe essa arquitetura, que são as tablespaces, segmentos, extensões e bloco de dados.

Este é um dos principais fundamentos para administração de banco de dados Oracle, saber seu funcionamento e conceito é uma grande vantagem na construção de modelo físico de banco de dados.

Primeiramente, devemos saber classificar cada um desses componentes, a fim de entender o funcionamento do armazenamento lógico do Oracle. A arquitetura lógica, como dita, é composta por quatro componentes, são eles:

Bloco de Dados (Data Block)

O bloco de dados corresponde a um número especifico de bytes do banco de dados para armazenado em disco. Sendo que esse valor é especificado durante a criação do banco de dados, pelo parâmetro db_block_size.


Então, o Oracle gerencia todo o espaço de armazenamento nos arquivos de dados (datafiles) através dessas pequenas unidades chamado blocos de dados, que carregam informações importantes como cabeçalho, diretório da tabela, diretório de linha, dados de tabelas ou índices e espaço livre para inserções ou atualizações de dados.

Extensões(Extent)

As extensões são unidades lógicas de armazenamento composta por um conjunto de blocos de dados, um ou mais extensões formam um segmento. As extensões são muito utilizadas para definir a característica de armazenamento de algum objeto, como um tabela ou índice. Eles podem influenciar muito na fragmentação de espaço ou ajudar a definir um bom plano de crescimento da base de dados.

Segmentos (Segment)

Os segmentos é um conjunto de extensões que possui todos os dados necessários para uma estrutura de armazenamento lógico, como as tablespaces.

Para cada tabela criada, o Oracle aloca um ou mais extensões para formar um segmento de dados, assim, também podemos dizer que o Oracle aloca um ou mais extensões para formar um segmento de índice.

Na arquitetura do Oracle, podemos encontrar quatro tipos de segmentos:

Espaços de tabela (Tablespace)

Os espaços de tabelas, ou mais conhecidas como Tablespaces, é dividido através de unidades lógicas de armazenamento chamadas segmentos. Uma tablespace pode conter um ou mais segmentos, segmentos do tipo de dados, índices, desfazer ou temporário.

A tablespace é a camada lógica do Oracle, ficando anexada a uma camada física, que são os arquivos de dados (datafiles), onde se origina o armazenamento físico dos dados.

Podemos perceber que existe uma relação entre os quatro componentes citados, analise o raciocínio: Sem o bloco de dados não temos extensões, sem extensões não temos segmentos, e sem segmentos não temos tablespaces e sem tablespaces não temos banco de dados Oracle.

Todos eles são responsáveis pela arquitetura lógica do banco de dados. Por isso que é fundamental o DBA ter esses conhecimentos. Abaixo podemos ver uma demonstração gráfica de como funciona o armazenamento lógico com e suas camadas:


Na figura acima, observamos que nosso bloco de dados em destaque é de 8KB, então concluímos que no momento da criação do banco de dados, o parâmetro db_block_size é de 8192 bytes (8Kb), esse parâmetro é estático não podendo ser alterado.

Percebemos também que a Extensão possui 24 blocos de dados, fazendo uma matemática simples, 24 (blocos de dados) x 8192 (bytes) temos o tamanho da extensão, que possui 196608 bytes (192Kb). Seguindo o mesmo exemplo, nosso segmento possui duas extensões, determinando que o tamanho do segmento seja de 384 Kb.

Assim podemos imaginar que se o segmento acima fosse um Segmento de Dados (Tabela), a nossa tabela teria um tamanho de 284Kb. Isso sem levar em consideração a configuração de storage desse segmento, que envolve os parâmetros de INITIAL, NEXT, MINEXTENTS, MAXEXTENTS e PCTINCREASE, que já é outro assunto mais detalhado.

O tamanho da tablespace não tem vinculo nenhum com os componentes citados, pois seu tamanho é especificado no momento de sua criação.Foi um breve resumo sobre sua arquitetura, espero que tenham gostado do assunto e que acrescente mais informações para os futuros Dbas.

Existem muitas particularidades sobre cada componente que não foi dito, porém, deixamos para outro momento. A principal conclusão é de como funciona toda a arquitetura de armazenamento lógico, um dos principais fundamentos do banco de dados Oracle.


Atividades


Detalhes do Exercício Pergunta 1: As tablespaces podem ser usadas para:

Sua resposta:Gerenciar dados idênticos com dispositivos de armazenamento para melhorar a interface de um banco de dados.

Resposta Correta: Executar operações parciais de cópia e recuperação de um banco de dados.

Explicação:

As tablespaces são usadas para: • Controlar a alocação de espaço em disco para os dados de um banco de dados. • Assinalar quotas específicas de espaço para os usuários. • Controlar a disponibilidade dos dados. • Executar operações parciais de cópia e recuperação de um banco de dados. • Alocar o armazenamento dos dados entre diferentes dispositivos de armazenamento para melhorar a performance de um banco de dados. O administrador de banco de dados pode criar novas tablespace, adicionar e remover arquivos de dados, configurar e alterar os parâmetros de armazenamento para os segmentos criados em uma tablespace e, naturalmente, pode removê-las sem maiores problemas.

Pergunta 2: Qual a utilidade das extensões?Sua resposta: são usadas para definir a característica de armazenamento de algum objeto.

Resposta Correta: são usadas para definir a característica de armazenamento de algum objeto.

Explicação:

As extensões são unidades lógicas de armazenamento composta por um conjunto de blocos de dados, muito utilizadas para definir a característica de armazenamento de algum objeto, como um tabela ou índice. Eles podem influenciar muito na fragmentação de espaço ou ajudar a definir um bom plano de crescimento da base de dados.

Pergunta 3: O que forma um segmento?Sua resposta: um ou mais extensões formam um segmento.

Resposta Correta: um ou mais extensões formam um segmento.

Explicação:Os segmentos é um conjunto de extensões que possui todos os dados necessários para uma estrutura de armazenamento lógico, como as tablespaces.


Flashback - Novos Recursos

O Oracle 10g apresentou novos recursos de Flashback, como o Flashback Database, o Flashback drop e o Flashback Query. Nesse artigo será abortado mais sobre esses novos recursos.

Flashback Database

Esse recurso de Flashback Database permite recuperar o banco, fazendo que o mesmo possa ser voltado num ponto específico do tempo. Esse recurso pode ser útil para situações como corrupção de dados lógicos ou perda de dados feita por algum usuário de uma maneira não intencional.

Antes de aprofundarmos mais no assunto, gostaria de deixar claro que esse recurso não é um recurso de recuperação de banco de dados no caso de perda física ou corrupção física, mas sendo um meio mais rápido para uma recuperação de dados se comparado a outros, como backups lógicos e Logminer.

Estrutura

A estrutura do Flashback Database envolve alguns novos componentes: logs de Flashback Database e RVWR (Processo de segundo plano).

* Logs de Flashback Database: é um arquivo de log com a imagem anterior dos blocos do banco de dados Oracle. Esses logs devem ser criados na área de recuperação de flashback, ou seja, essa área deve ser configurada para esse armazenamento. Esses logs não servem para recuperação de banco, pois os mesmos não são arquivados como acontece com a área de redo.

* RVWR: Quando o Flashback Database está ativado, o processo de segundo plano RVWR é iniciado, sendo responsável por gravar nos logs os dados do Flashback Database.

RECYCLEBIN

Para suportar esse recurso o Oracle introduziu o conceito de lixeira que funciona semelhante ao do Windows, sendo nomeado de RECYCLEBIN.

Utilizando

Quando o usuário dá o comando drop table NOMEDATABELA, as tabelas vão para a lixeira do Oracle. Caso queira excluir a tabela sem que a mesma vá para a lixeira, basta dar um drop table NOMEDATABLEA purge;.

Na RECYCLEBIN, lixeira, o objeto tem seu nome alterado para evitar conflito nas atribuições de nomes dos objetos excluídos.

OBS: Note que os objetos não são excluídos e sim movidos para a área da lixeira quando "Dropado" sem o comando PURGE.

Caso queira excluir um objeto da lixeira e não lembra qual é seu nome identificado após a exclusão, utilize a visão do dicionário de dados RECYCLEBIN, nela conterá informações do nome original do objeto, nome após exclusão, tipo de operação, tipo de objeto, dentre outras informações.


Após identificar o nome, dê o comando purge table NOMEIDENTIFICADO;.

Para recuperar uma tabela excluída sem o comando PURGE, dê:

flashback table NOMEDATABELA to before drop;

Pode-se também recuperar uma tabela num ponto específico do tempo. Para isso há duas maneiras, TIMESTAMP ou SCN, conforme exemplos abaixo:

flashback table NOMEDATABELA to timestamp to_timestamp(11-Jan-2005 09:00:00, dd-MON-yyyy hh24:mi:ss); flashback table NOMEDATABELA to before scn 1901443;

FLASHBACK VERSIONS QUERY

Esse recurso dá a opção de visualizar num ponto específico do tempo versões de dados, ou seja, caso queira ver dados de um usuário cadastrado a um determinado tempo em sua base e ver, por exemplo, as mudanças desses dados como e-mail, endereço ou telefone.

No exemplo abaixo, mostraremos como utilizar esse recurso e examinar uma lista de telefones dos usuários e as alterações nos últimos trinta minutos. * select id, nome, sobrenome, telefone from usuários VERSIONS BETWEEN TIMESTAMP SYSTIMESTAMP - INTERVAL 30 MINUTE;

Só serão mostradas as alterações submetidas a COMMIT ou ROLLBACK. Um outro ponto importante é que esse recurso depende do tamanho do seu UNDO, ou melhor, do seu UNDO_RETENTION. É importante saber que ao informar um TIMESTAMP ou um SCN maior do possível, o Oracle te retornará um erro.

OBS: Esse Recurso não pode ser utilizado em Views e o usuário necessita de privilégios de Flashback e Select.

FLASHBACK TRANSACTION QUERY

Para finalizar o último novo recurso Flashback presente na versão 10g, que possibilita a reconstrução de instruções SQL previamente executadas no banco.

Para se fazer uso desse recurso será utilizado a visão V$flashback_transaction_query, mas como o recurso anterior, também depende do parâmetro UNDO_RETENTION.

Exemplo:

select undo_sql from v$flashback_transaction_query where table_owner = JOAO and table_name = USUARIOS and start_scn 1901443 and 1980475; Nesse exemplo estamos examinando instruções SQL realizadas entre o System Change Number 1901443 e 1980475. O único problema nessa feature é que a visão do dicionário não é indexada.

Uma observação final. Nunca esqueça de colocar um valor alto no parâmetro UNDO_RENTENTION, caso contrário, dependendo da situação, não conseguirá voltar ao ponto desejado.


Oracle Data Pump

No Oracle 10g você pode usar um utilitário de movimentação de dados chamado Data Pump para aumentar o desempenho no transporte de dados, pois o mesmo é 60% mais rápido do que os utilitários de export e import que ainda estão disponíveis no 10g.

O Data Pump utiliza recursos de processamento paralelos no transporte de dados e pode ler arquivos de exportação criados pelo utilitário export. Ele emprega a Tecnologia DIRECT PATH para carregar ou exportar dados. Diferentemente dos programas Import e Export que funciona no lado cliente de uma sessão do banco de dados, o Data Pump executa no servidor. Assim, você deve usar um diretório de banco de dados para especificar a localização de arquivos de Dump e Log.

O Data Pump pode ser chamado da linha de comando com os programas IMPDB e EXPDP ou através do PACKAGE DBMS_DATAPUMP. Você pode pedir ao expdp uma lista completa de parâmetros, especificando o parâmetro help=y.

Parâmetros Descrição

Full=y Modo de exportação de banco de dados

Schemas=schema_list Especifica exportação em modo schema

Tables=tables_list Exportação em Modo Tabela

Content=content_option Indica quando dados ou metadados serão exportados default ALL

Network_link=db_link Especifica um Banco de Dados Remoto com a origem de dados

Dumpfile=dir:fileNome do Arquivo Dump, Se o nome do Arquivo contiver %U ,este será

substituído por dois dígitos .

Filesize=size_limit Tamanho máximo do arquivo Dump e Log

Logfile=dir:file Localização e nome do Arquivo de Log

Directory=dir Localização para Arquivo Dump e Log

Nologfile=y Indica que não será gravado um arquivo de log.

Job_name=identifier Especifica um nome que pode ser utilizado por um job de importação

Parallel=degree Número máximo de processos de palalelismo.

Parfile=dir:file Localização e nome do arquivo de Parâmetros

Utilizando o Data Pump para Exportar dados

Você inicia uma exportação via Data Pump executando o Programa EXPDP ou executando um Programa PL/SQL que chama a procedure DBMS_DATAPUMP.O Enterprise Manager Também fornece uma interface gráfica para a execução do Data Pump.

Aprenderemos agora como Exporta dados utilizando a linha de comando com o Data Pump.

O programa de exportação do Data Pump pode funcionar de vários modos, incluindo banco de dados, Schema, Tabela, Tablespace. Em uma exportação de modo de banco de dados, o banco de dados inteiro é exportado para arquivo de sistema operacional incluindo contas de usuários, sinônimos públicos, roles e profiles.

Em uma exportação de modo schema, todos os dados e metadados de uma lista de schema são exportados. No modo de tabela, inclui os dados e metadados de uma lista de tabelas no modo tablespace, extrai tanto dados como metadados de todos os objetos em uma lista de tablespace bem como qualquer objeto dependente daquela lista de tablespaces especificada.


Os arquivos criados pelo Data Pump são chamados de DUMP FILES, um ou vários desses arquivos podem ser criados durante uma única execução do Data Pump. Múltiplos arquivos podem ser criados se a execução do Data Pump tiver um grau de paralelismo maior que um ou se um arquivo exceder o tamanho limite do parâmetro FILISEZE. Todos os arquivos de dump de uma execução são chamados de dump file set. Veremos agora como executar o data pump em seus diferentes modos de exportação. Entre com o usuário system, dê o privilégio create any directory para criar o diretório onde será guardado o dump file Conn system/password@orcl

Utilize a view dba_directories para consultar o que vc acabou de criar se realmente esta no caminho correto.


o export de tabelas com expdp Expdp scott/tiger@orcl tables=emp,dept directory=teste_dir Dumpfile=emp_dept.dmp logfile=expdppemp_dept.log nologfile =y content=metadata_only

O parâmetro nologfile=y diz ao DATA PUMP para não gravar um arquivo de log em disco. O parâmetro content=metadata_only diz ao DATA PUMP para exportar só os metadados, não os dados das tabelas. Para especificar somente dados, sem metadados, substitua o parâmetro metadata_only por data_only.

O parâmetro tables_exists_action=append permite importar dados para uma tabela que já tem dados .

Fazendo o export de schemas com expdp

Expdp system/oracle@orcl schemas=scott directory=teste_dir dumpfile=scott.dmp logfile=impdpscott.log


Fazendo o exporte das tablespaces

Expdp system/password@orcl directory=teste_dir dumpfile=db10tabelspace.dmp logfile=exptbs10g.log tablespaces=users

Para monitorar as operações realizadas pelo Data Pump, consulte as views:

Dba_datapump_jobs Dba_datapump_sessions Datapump_paths

Uma importação com o Data Pump pode ser iniciada com um programa PL/SQL, utilizando a procedure DBMS_DATAPUMP ou pelo Oracle Enterprise Manager. Veremos como importar dados com o Data Pump.

Executando uma importação utilizando a linha de comando

O programa de importação DATA PUMP, impdp, tem vários modos de operação, incluindo FULL, SCHEMA, TABLE, TABLESPACE. No modo FULL, o conteúdo inteiro de um conjunto de arquivos especificado é carregado. Modo SCHEMA, todo o conteúdo de uma lista de esquemas especificados é carregado. O conjunto de arquivos especificado de uma importação no modo SCHEMA pode ser de banco de dados ou de uma exportação de modo TABLE, no modo TABLE, só a Tabela especificada e os objetos dependentes são carregadas do conjunto de arquivos de exportação. Com uma importação no modo TABLESPACE, todos os objetos no conjunto de exportação que estiverem na lista de tablespace especificada são carregados.

Em todos estes modos, a origem pode ser um banco de dados, ao invés de um conjunto de arquivo. A tabela abaixo mostra os modelos de importação suportados por diversos modos de exportação.


Modo de Exportação Modo de Importação

Database, Schema, Tabela, Tablespace. Full

Database, Schema Schema

Database, Schema, Tabela, Tablespace. Tabela

Database, Schema, Tabela, Tablespace. Tablespace

A Role IMP_FULL_DATABASE é requerida se a origem for um banco de dados ou se a sessão de exportação exigir a role EXP_FULL_DATABASE.Vários parâmetros controlam Data Pump na importação. Esses parâmetros são listados na Tabela

Digite: help = y

Parâmetros de Importação do Data Pump

Full=Y Especifica uma Importação full

Schema Especifica uma importação no modo Schema

Tables=tabela_list Especifica importação no modo Table

Tablespace=tablespace_list Especifica importação no modo Tablespace

Content=cont_option Indica que serão carregados dados, metadados ou ambos

Network_link=db_linkIndica que o banco de dados especificado no Database link será utilizado como origem de dados

Dumpfile=dir:arq Localização e o nome do arquivo de dump

Logfile= Localização e o nome do arquivo de log

Directory=dir Diretório para localizar os arquivos de Dump e Log

Nologfile=y Não grava arquivos de log

Sqlfile= Especifica um arquivo para gravar comandos DDL

Job_name=identifier Nome para tarefa de import

Parallel Número máximo de processos para importação

Parfile= Localização dos arquivos de Parâmetro

Reuse_datafiles=optionIndica se arquivos deverão ser sobrepostos com o camando: Create Tablespace

Remap_datafiles=source:target Indica como renomear arquivos de dados

Remap_schema Determina a carga de um schema

Remap_tablespace Instrução para fazer Remap de tablespace

Include Determina que tipo de objeto serão incluídos na importação

exclude Determina que tipo de objeto serão excluídos na importação

Status

Streams_configuration Permitem o carregamento da ação do metadata

Table_exists_action Exemplos de objetos importados

TransformMetadata transformam para aplicar-se aos objetos aplicáveis. Válido transforme keywords

Transport_datafile Passa os datafiles a serem importados

Transport_full_check verificam segmentos do armazenamento de todas as tabelas

Transport_tablespace Determina a tablespace a ser importada


Exemplo da utilização do Importe do Data Pump

Fazendo o import de tabelas com impdp

Imp scott/tiger tables=emp,dept directory=teste_dir dumpfile=emp_dept.dmp logfile=impdpemp.log

Fazendo import de schemas com impdp

Impdp system/password schemas=scott directory=teste_dir dumpfile=scott.dmp logfile=impdpscott.log


Fazendo o import full do Banco de Dados com impdp

impdp system/passwordl full=y directory=teste_dir dumpfile=db10g.dmp logfile=impdpdb10g.log

Obs.: Na imagem, estão aparecendo algumas mensagens de erro. Estas mensagens são devidas a existência de algumas tablespaces e esquemas.Fazendo o import tablespaces

Você usa Tablespaces transportável quando você quer mover um tablespace inteiro dos dados de uma base de dados do Oracle para outra.

Tablespaces transportável permite que os arquivos de dados do Oracle sejam desconectados de uma base de dados, movidos ou copiados a uma outra posição, e plugged então em uma outra base de dados. Os dados movidos que usam Tablespaces transportável podem ser muito mais rápidos do que executando uma exportação ou a importação dos mesmos dados, porque transportar um tablespace requer somente a cópia dos datafiles e integrar a informação do dicionário do tablespace. Mesmo ao transportar um tablespace, a exportação e a importação são usadas e ainda segurar a extração e a recreação do metadata para esse tablespace.

impdp system/password directory=teste_dir dumpfile=db10tabelspace .dmp logfile=exptbs10g.log tablespaces=users


Chegamos ao Fim de mais um Curso do Grupo IPED.




Relatório de Aproveitamento - Registrado para este Exercício

Nome: Giesley Coelho dos SantosCurso: Curso de Oracle 10g

Detalhes do Exercício Pergunta 1: O que é um tablespace system?

Sua resposta:É onde o Oracle armazena todas as informações necessárias para o gerenciamento, como os nomes dos tablespaces e o que os arquivos de dados de cada tablespace contêm.

Resposta Correta:É onde o Oracle armazena todas as informações necessárias para o gerenciamento, como os nomes dos tablespaces e o que os arquivos de dados de cada tablespace contêm.

Pergunta 2: O que são Constraints? Sua resposta: São restrições que você estabelece para uma coluna no banco de dados.

Resposta Correta: São restrições que você estabelece para uma coluna no banco de dados.

Pergunta 3:Para se referir ao acesso aos dados, podemos utilizar dois termos: cache miss e cache hit. Para que podemos usar o termo cachê hit?

Sua resposta: Para identificar as vezes que um processo encontra uma informação na memória. Resposta Correta: Para identificar as vezes que um processo encontra uma informação na memória.

Pergunta 4: O que é um Schema?Sua resposta: É o conjunto de informações sobre o USERNAME.

Resposta Correta: É o conjunto de informações sobre o USERNAME.

Pergunta 5: O que é SGA?

Sua resposta:É uma região de memória compartilhada por todos os usuários e alocada pelo ORACLE. Contém os dados e as informações de controle de uma instância.

Resposta Correta:É uma região de memória compartilhada por todos os usuários e alocada pelo ORACLE. Contém os dados e as informações de controle de uma instância.

Pergunta 6: O que é o Automatic Storage Manager?

Sua resposta:É um gerenciador de volumes e ao mesmo tempo um sistema de arquivos para banco de dados Oracle o qual suporta configurações do tipo single-instance e RAC.

Resposta Correta:É um gerenciador de volumes e ao mesmo tempo um sistema de arquivos para banco de dados Oracle o qual suporta configurações do tipo single-instance e RAC.

Pergunta 7: O que seria o documento que contém a política de segurança?

Sua resposta:É um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas.

Resposta Correta:É um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas.

Pergunta 8: O que é o Program interface?


Sua resposta:É o mecanismo pelo qual um processo do usuário se comunica com o processo servidor. Serve como um método de comunicação padrão entre a porção cliente de uma aplicação ou uma ferramenta e o próprio servidor ORACLE.

Resposta Correta:É o mecanismo pelo qual um processo do usuário se comunica com o processo servidor. Serve como um método de comunicação padrão entre a porção cliente de uma aplicação ou uma ferramenta e o próprio servidor ORACLE.

Pergunta 9: Onde podemos usar as Tabelas Temporárias?

Sua resposta:Nas aplicações onde os dados necessitam ser preservados durante uma ou diversas transações dentro de uma sessão.

Resposta Correta:Nas aplicações onde os dados necessitam ser preservados durante uma ou diversas transações dentro de uma sessão.

Pergunta 10: O que podemos obter ao utilizar o comando SHRINK SPACE?

Sua resposta:Uma considerável melhora na performance de alguns comandos SQL e também reduzimos a fragmentação do banco de dados.

Resposta Correta:Uma considerável melhora na performance de alguns comandos SQL e também reduzimos a fragmentação do banco de dados.

Documents

Geral