Instalação e Configuração Oracle
Instalação do banco de dados Oracle, configuração da base de dados, ferramenta de banco, backup, etc...
- Analisando o tamanho e espaço da tablespace
- Backup e Restauração da base de dados
- Licenciamento Oracle
- Limpar cache do Oracle (V$SQL)
- Parâmetros de sessão
- Realizando Backup no Oracle com EXP
- SQL's que mais consomem o banco de dados
Analisando o tamanho e espaço da tablespace
Algumas ferramentas de banco de dados não conseguem mostrar o consumo do tablespace do oracle, o que de certa forma é bem critico, pois quando o tablespace estoura o tamanho o funcionamento das aplicações fica comprometido.
Conectar no banco com um usuário que tenha os privilégios, ou como SYSDBA e executar o comando abaixo:
SELECT T.TABLESPACE,
T.TOTALSPACE AS " TOTALSPACE(MB)",
ROUND ( (T.TOTALSPACE - FS.FREESPACE), 2) AS "USED SPACE(MB)",
FS.FREESPACE AS "FREESPACE(MB)",
ROUND ( ( (T.TOTALSPACE - FS.FREESPACE) / T.TOTALSPACE) * 100, 2)
AS "% USED",
ROUND ( (FS.FREESPACE / T.TOTALSPACE) * 100, 2) AS "% FREE"
FROM ( SELECT ROUND (SUM (D.BYTES) / (1024 * 1024)) AS TOTALSPACE,
D.TABLESPACE_NAME TABLESPACE
FROM DBA_DATA_FILES D
GROUP BY D.TABLESPACE_NAME) T,
( SELECT ROUND (SUM (F.BYTES) / (1024 * 1024)) AS FREESPACE,
F.TABLESPACE_NAME TABLESPACE
FROM DBA_FREE_SPACE F
GROUP BY F.TABLESPACE_NAME) FS
WHERE T.TABLESPACE = FS.TABLESPACE
ORDER BY T.TABLESPACE;
Caso identifique alguma tablespace com o "Used Space(MB)" próximo a 32gb, pelos padrões, você poderá alertar a equipe responsável pela manutenção da base de dados.
Backup e Restauração da base de dados
Para soluções de backups automatizados fornecidos pela Ema Software, solicite ao nosso comercial orçamento do Ema Cloud Backup
Oracle 11G R2 Enterprise ou Standard
Data Pump
O Data Pump é um dos recursos de backup disponibilizados no Oracle.
Para realizar o backup utilizando o recurso EXPDP, do Data Pump, devem ser executados os seguintes procedimentos iniciais:
- Acessar o Prompt de Comando do Windows: Menu Iniciar -> Executar -> cmd.exe [Enter]
- Logar na linha de comando do Oracle utilizando a seguinte sintaxe: sqlplus sys as sysdba [Enter]
- Informe a senha do Oracle [Enter]
- Uma vez conectado na linha de comando do Oracle, é necessário criar o diretório onde será armazenado o arquivo de backup, utilizando a os seguintes comandos abaixo:
CREATE OR REPLACE DIRECTORY NOME AS 'CAMINHO_DO_DIRETÓRIO';
GRANT READ, WRITE ON DIRECTORY NOME TO USUÁRIO;
EXECUTE DBMS_METADATA_UTIL.LOAD_STYLESHEETS;
- Em DIRECTORY a palavra NOME deve ser substituída por um nome de sua preferência, para identificação do diretório onde os backups serão exportados.
- Em CAMINHO_DO_DIRETÓRIO deve-se informar o diretório em que os backups serão salvos.
- Já em USUÁRIO deve-se informar o nome do usuário utilizado pelo sistema no Oracle, que por padrão é o usuário EMA.
Eis um exemplo:
CREATE OR REPLACE DIRECTORY DATAPUMP AS 'C:\EMA SOFTWARE\FERRAMENTAS\';
GRANT READ, WRITE ON DIRECTORY DATAPUMP TO EMA;
EXECUTE DBMS_METADATA_UTIL.LOAD_STYLESHEETS;
EXPDP - Exportação de Base de Dados
O EXPDP realiza a exportação dos dados (backup) de usuários específicos no Oracle.
Após a realização dos procedimentos de configuração do Data Pump, é possível utilizar o EXPDP para realizar o backup do sistema. Esta é a sintaxe que deve ser executada no Prompt de Comando do Windows para iniciar o processo:
EXPDP USUARIO/SENHA SCHEMAS=USUARIO DIRECTORY=NOME_DIRETORIO DUMPFILE=NOME_BACKUP.DMP LOGFILE=NOME_LOG.LOG
As palavras em destaque devem ser substituídas pelas informações corretas.
- Em USUÁRIO/SENHA deve-se informar um usuário e senha do Oracle com permissões administrativas. Como usuário EMA possui permissões administrativas, ele pode ser utilizado. O usuário SYSTEM, um dos administradores padrões do Oracle, também pode ser utilizado.
- Na opção SCHEMAS o usuário do Oracle que possui os dados do sistema deve ser informado. Por padrão utiliza-se o usuário EMA.
- Em NOME_DIRETORIO informa-se o nome do diretório criado na pré configuração, da qual seguindo o exemplo citado anteriormente, foi defino como datapump.
Por fim, definimos o nome do arquivo de backup e do seu log. Segue um exemplo da sintaxe completa:
EXPDP EMA/123 SCHEMAS=EMA DIRECTORY=DATAPUMP DUMPFILE=BKP-EMA.DMP LOGFILE=EXPORT.LOG
Com esta sintaxe, estamos gerando o backup do usuário EMA, onde o arquivo de backup recebeu o nome de BKP-EMA.DMP, no diretório DATAPUMP, criado nas configurações iniciais, do qual irá salvar a exportação do backup em C:\EMA SOFTWARE\FERRAMENTAS\.
Para facilitar a execução do backup, disponibilizamos abaixo a sintaxe para criação de um script que irá realizar a exportação da base de dados, após as configurações iniciais terem sido realizadas conforme o exemplo. O script deve ser criado a partir do Bloco de Notas do Windows.
Após acessar o bloco de notas, é preciso informar os seguintes comandos para exportação, e posteriormente salvar o arquivo com a extensão .bat:
del "C:\Ema Software\Ferramentas\bkp-ema.dmp"
del "C:\Ema Software\Ferramentas\export.log"
expdp ema/senha directory=datapump dumpfile=bkp-ema.dmp schemas=EMA logfile=export.log
O script irá manter apenas a última cópia da base de dados. Ele também poderá ser utilizado pelo profissional responsável por sua infraestrutura de TI para criação de rotinas de backup automatizadas.
***OBSERVAÇÃO: A senha do banco de dados deve ser obtida através do setor responsável, geralmente o T.I. da sua empresa. É preciso editar o script de backup para informar a senha da base de dados, bem como para realizar as configurações iniciais. O EXPDP não está disponível para uso na versão Oracle 11G R2 XE. O script deve ser executado diretamente no servidor da base de dados.
IMPDP - Importação da Base de Dados
Permite importar usuários específicos (Schemas), tablespaces ou tabelas. Neste caso, o propósito é importar o usuário inteiro.
IMPDP USUARIO/SENHA DIRECTORY=NOME_DIRETORIO DUMPFILE=NOME_BACKUP.DMP REMAP_SCHEMA=SCHEMA_ORIGEM:SCHEMA_DESTINO EMAP_TABLESPACE=TABLESPACE_ORIGEM:TABLESPACE_DESTINO
Exemplo:
IMPDP EMA/123 DIRECTORY=DATAPUMP DUMPFILE=BACKUP.DMP REMAP_SCHEMA=EMA:CARLESSO REMAP_TABLESPACE=USERS:USERS2
Licenciamento Oracle
Guia prático de licenciamento da Oracle |
Sabendo que os clientes têm dificuldades em entender as regras de licenciamento, a Oracle elaborou um manual de licenciamento, chamado Software Investment Guide (SIG), que contém as explanações básicas sobre as métricas de licenciamento para os diferentes tipos de produtos e cenários.
Regras bastantes polêmicas de licenciamento como failover, stand by, backup, quantidade de usuários e etc estão explicadas de forma detalhada e com exemplos de aplicações destas regras em cenários semelhantes ao mundo real.
No link abaixo, além do SIG você também irá encontrar uma planilha de controle de inventário de licenças que já vem preparada com as métricas e produtos da Oracle. Seu uso não é obrigatório, mas ajuda bastante quando não há nenhum outro tipo de controle.
Software Investment Guide: http://www.oracle.com/us/corporate/pricing/software-investment-guide/index.html
Principais pontos sobre licenciamento Oracle |
A Oracle hoje possui uma gama muito vasta de produtos e serviços que vai muito além do banco de dados. Hoje a Oracle possui em seu portfólio produtos que vão desde a camada de aplicação, passando por middleware, banco de dados, virtualização, sistema operacional, servidores e até storage.
Por isso, quando vamos checar a forma de licenciar um produto, precisamos estar atentos que cada linha de produto possui uma forma específica de licenciamento, Como os pontos mais comuns do dia a dia são com relação ao licenciamento de banco de dados, é nesse tópico que eu vou focar, mas o SIG também possui informações sobre os demais produtos.
O primeiro ponto importante na escolha do software de banco de dados a ser licenciado é a escolha da funcionalidade desejada. Dependendo das necessidades da empresa, em termos de negócio, uma ou outra tecnologia pode ser mais adequada.
O banco de dados Oracle é comercializado de acordo com a disponibilidade destes recursos para atender necessidades específicas. A versão mais básica do banco de dados Oracle é a versão Express (também conhecida como XE).
- O Oracle XE é gratuito, porém é o que possui menos recursos e têm maiores limitações em termos de hardware. Independente da maquina onde estiver rodando, ele fica limitado a utilizar apenas um núcleo (core) de processador e 1 GB de memória RAM.
- O Oracle Standard Edition One (SE1) é a versão comercial entry-level do banco de dados, ele é limitado a rodar num hardware com no máximo 2 (dois) processadores físicos (sockets) e não tem opção de trabalhar em cluster (funcionalidade onde duas ou mais máquinas trabalham em conjunto para atender o mesmo banco de dados).
- O Oracle Standard Edition (SE), por sua vez, possui o limite de hardware de até 4 processadores físicos (sockets) e tem a possibilidade de trabalhar em cluster através da tecnologia Oracle RAC (Oracle Real Application Clusters). Note que ao optar por utilizar o RAC, continua valendo o limite de 4 processadores para o cluster inteiro (exemplo: duas máquinas com dois processadores).
A partir de dezembro de 2015, a Oracle parou de comercializar os produtos Oracle SE1 e Oracle SE e lançou um novo produto, o Oracle Database Standard 2 (SE2). O Oracle SE2 possui a mesma arquitetura dos produtos antecessores, porém com as seguintes características:
- Limite de hardware de até 2 processadores físicos.
- Possibilidade de configuração em cluster com Oracle RAC.
- Limite de software de 8 threads simultâneas por instância.
Na prática, isto significa que o SE2 funciona como era o antigo Oracle SE1, mas com a opção de usar o Oracle RAC. Isto permite ao cliente três possibilidades de instalação:
- Uma máquina com um processador - uma licença de SE2
- Uma máquina com dois processadores - duas licenças de SE2
- Duas máquinas com um processador - duas licenças de SE2
Note que a configuração duas máquinas com dois processadores já viola o limite de 2 processadores no cluster, e portanto, não é valida para o SE2.
Isto quer dizer que clientes que possuem a licença Standard Edition com configurações como esta (duas máquinas com dois processadores cada) devem tomar muito cuidado na hora de atualizar o ambiente, pois eventualmente vão cair no requisito de utilizar o banco de dados Enterprise.
Além disto, é importante destacar a limitação de threads simultâneas. Isto é um fato novo que não existia nos produtos anteriores. Na prática isto significa que não adianta comprar processadores com muitos cores (hoje temos processadores x86 com 16 cores, em alguns casos até mais) que o software não vai conseguir aproveitá-los.
Finalmente, o banco Oracle Enterprise Edition (EE) é o produto top de linha desta categoria, contendo inúmeras características que o torna ideal para negócios extremamente críticos e dinâmicos.
Ao contrário da crença popular de que as única diferenças entre as edições de banco de dados Oracle são as limitações de hardware (e o preço!), o Oracle EE possui muitas funcionalidades que não estão disponíveis nas versões mais simples.
Entre elas, podemos destacar recursos como o Data Guard, a ferramenta de continuidade de negócios do banco de dados, e o paralelismo, recurso que permite otimizar o uso de recursos de hardware.
O Oracle Enterprise Edition é adequado para empresas que não podem parar (operam 24x7) e também não podem correr risco de perder os seus dados, além de outras características como melhor performance, segurança e escalabilidade. Além dos recursos padrões, o Oracle EE também possui as chamadas options, que são produtos que podem ser adquiridos a parte para estender as funcionalidades do banco de dados.
Em termos de licenciamento, o Oracle Enterprise Edition possui uma métrica diferenciada. O processador do EE é calculado de acordo com o número de núcleos (cores) que a máquina possui, aplicado um fator de conversão que é tabelado.
Fica mais fácil de entender na prática. Vamos tomar como exemplo um servidor padrão de mercado hoje, com dois processadores x86 octa-core (8 cores cada, 16 cores no total).
O fator de conversão para x86 é 0,5. Logo, o número de processadores a serem licenciados de banco EE é:
- 16 (total de cores) x 0,5 (fator x86) = 8 processadores. (Note que a mesma máquina em SE1, SE2 ou SE necessitaria de 2 (duas) licenças de processador, uma para cada socket)
Para conhecer todos os fatores de conversão, basta consultar a tabela Oracle Processor Core Factor Table. Hoje, os mais relevantes são: 0,5 para x86 e SPARC e 1,0 para processadores RISC não-Oracle.
Licenciamento por Usuários Nomeados (named User Plus) |
Além do licenciamento por processador, algumas linhas de produtos podem ser licenciadas por usuários nomeados, os chamados Named User Plus. Para a linha de produtos de banco de dados, isto também é possível, desde que se considere as seguintes regras:
- Usuários humanos e não-humanos precisam ser contáveis (ex.: 30 sensores + 400 operadores)
- Existem quantidades mínimas de usuários que precisam ser respeitadas, que variam por produto. Para os produtos banco de dados SE1, SE2 e SE, o mínimo de usuários nomeados é 5 por processador. Para o banco de dados EE, o mínimo é 25 usuários por processador.
- Para calcular os mínimos, primeiro calcula-se o número de licenças de processador necessárias para o hardware específico e depois aplicam-se os multiplicadores de cada produto.
- Se o número de usuários contados for maior que o mínimo, licencia-se por usuários contados. Se não, licencia-se pelo mínimo calculado.
Considerando a máquina de referência do exemplo acima, 2 processadores físicos com 8 cores cada um, os mínimos respectivos são:
- SE1, SE2 e SE: 2 processadores x 5 usuários = 10 usuários nomeados
- EE: 2 processadores x 8 cores x 0,5 (fator x86) x 25 usuários = 200 usuários nomeados
Tópicos Especiais de Licenciamento |
Os cenários de licenciamento descritos acima vão cobrir a maioria dos casos que encontramos no dia-a-dia. No entanto, a medida que precisamos fazer usos mais avançados do software a complexidade da solução aumenta e as regras precisam ser estendidas para contemplar esta nova complexidade.
Dois tópicos muito quentes são o licenciamento de disaster recovery e o licenciamento de ambientes virtualizados. Com relação ao disaster recovery (DR), entendemos por isso um ambiente onde exista o banco de dados Oracle instalado pronto para assumir a carga do ambiente de produção caso ocorra um evento que indisponibilize o mesmo.
Ou seja, é um conjunto de hardware e software adicional que através de alguma forma de replicação mantém uma cópia do banco de dados para eventos de desastres ou outros tipos de paradas, sejam estas planejadas ou não planejadas.
Todo servidor onde houver o software da Oracle instalado precisa ser licenciado logo, sim, é preciso licenciar o site DR.
Uma pergunta muito comum é: posso licenciar o site de produção por processador e o DR por usuário? A resposta é NÃO. Independente do tipo de replicação utilizado, se a finalidade é DR, os servidores precisam obrigatoriamente seguir a mesma métrica.
Agora se estivéssemos falando de ambientes distintos, como por exemplo, produção e homologação ou QA, aí sim, neste caso pode ser licenciado produção por processador e homologação por usuários.
Para esclarecer de uma vez por todas as regras de licenciamento de sites de disaster recovery, backup, etc, incluindo esta e outras regras, o documento oficial é o Licensing Data Recovery Environments.
Sobre o tema de virtualização, gostaria de destacar que é preciso tomar muito cuidado com este tópico, em especial para não ficar irregular. Todo processador que roda o código Oracle precisa ser licenciado.
Em um servidor bare metal (não virtualizado), todo o processamento fica disponível para o banco de dados e, portanto, toda a máquina precisa ser licenciada.
Agora, em ambientes virtualizados, nem sempre temos o controle sobre quais processadores vão executar quais tarefas, podendo elas estar distribuídas em múltiplos servidores em momentos distintos - a exemplo da tecnologia de live migration.
Nestes casos, farms de VMs, onde o banco pode estar executando hora em uma máquina, hora em outra, é necessário licenciar TODA a farm de VMs. Sim, toda. Mesmo que você esteja usando só 2 processadores de cada vez.
Existem exceções a esta regra? Sim. Quando a tecnologia de virtualização tem a capacidade de fazer o chamado hard partitioning ou "CPU pin", ou seja, fixar a execução da VM em um determinado core ou grupo de cores, como se efetivamente estivéssemos "fatiando" uma máquina.
Note que não são todas as tecnologias de virtualização que suportam isso, e mesmo que as que suportam, precisam ser homologadas pela Oracle para que o licenciamento seja válido.
Esta regra pode ser vista na íntegra no documento Partitioning (não confundir com a option de banco Partitioning, este partitioning se refere a divisão de uma máquina física em máquinas virtuais menores). A documentação completa sobre os tópicos especiais (além dos dois previamente citados) pode ser encontrada no site da Oracle, na seção Specialty Topics.
Palavras Finais |
O objetivo deste artigo era chamar a atenção para estes tópicos de licenciamento que são bastante polêmicos e muito comuns de encontrarmos no dia-a-dia.
Vale lembrar também que regras de licenciamento são muito dinâmicas e podem variar ao longo dos anos, então por este motivo fiz questão de apontar sempre as referências oficiais, assim mesmo que este texto algum dia fique desatualizado, aí estão os links para a consulta do material direto na fonte.
Fonte: https://pt.linkedin.com/pulse/tudo-que-voc%C3%AA-queria-saber-sobre-licenciamento-oracle-petruzalek
Preços |
De acordo com o artigo supracitado, é evidente que o licenciamento do banco de dados Oracle é muito complexo e cheio de pegadinhas. O valor do investimento a ser realizado, depende principalmente do tipo de hardware que irá suportar o Oracle e do cenário que a empresa pretende implementar.
Para análise do tipo de licenciamento que irá se encaixar no seu ambiente, bem como no seu orçamento, é necessário o apoio de especialistas.
A Ema possui parceria com a empresa Seven Keys, especializada na comercialização e implementação de soluções Oracle. Mediante a situações que necessitem de análise, indicamos o contato com a Seven Keys.
Eis alguns valores de referência da versão Standard Edition 2, cotados no mês de janeiro de 2018:
Licenciamento por processador
- Anual: R$ 12.486,00
- 2 anos: R$ 21.850,00
- 3 anos: R$ 31.215,00
- Perpétua: R$ 76.163,00
Licenciamento por usuários nomeados
- Anual: R$ 260,00 por usuário
- 2 anos: R$ 452,73 por usuário
- 3 anos: R$ 647,00 por usuário
- Perpétua: R$ 1.606,18 por usuário
Para o licenciamento por usuário nomeado, é necessário adquirir no mínimo 10 licenças.
Limpar cache do Oracle (V$SQL)
O comando visa apoiar os programadores com os testes de desempenho. A descarga do cache do buffer de dados é uma ótima ferramenta de teste e evita que você precise devolver (parar e reiniciar) sua instância de banco de dados entre as execuções de teste.
NÃO recomendamos que você limpe o cache do buffer de dados em um sistema de produção!
alter system flush buffer_cache;
alter system flush shared_pool;
OPCIONAL:
EXECUTE dbms_result_cache.flush;
Nota: A liberação do cache do buffer de dados impõe uma sobrecarga séria de desempenho, especialmente nos bancos de dados RAC. O uso do cache do buffer de liberação foi destinado apenas ao sistema de teste.
Parâmetros de sessão
Quando os serviços da Ema são configurados em um ambiente com banco de dados Oracle, todas as execuções de scripts são executadas com alguns parâmetros de sessões definidos.
Para que seus testes no SQL Developer ou outro gerenciador de banco sejam equivalentes à execução do DOX, você deve rodar os scripts abaixo na sessão do banco logada (todas as vezes que for iniciado uma sessão no SGBD terá que ser executado).
ALTER SESSION SET NLS_NUMERIC_CHARACTERS = '.,';
ALTER SESSION SET NLS_DATE_FORMAT = 'RRRR-MM-DD HH24:MI:SS';
ALTER SESSION SET NLS_TIMESTAMP_FORMAT = 'RRRR-MM-DD HH24:MI:SS';
ALTER SESSION SET NLS_TIMESTAMP_TZ_FORMAT = 'RRRR-MM-DD HH24:MI:SS';
ALTER SESSION SET NLS_SORT=BINARY_AI;
ALTER SESSION SET NLS_COMP=LINGUISTIC;
Após ter executado estes scripts na sessão logada no SGBD, todos os comandos serão executados com os mesmos parâmetros que o DOX executa.
*** Importante verificar se os comandos acima são comitados.
Realizando Backup no Oracle com EXP
Um dos modos de realizar a exportação de dados (backup) de uma base do Oracle, é utilizando o EXP, conforme exemplo abaixo.
Para iniciar, abra o prompt de comando, no Iniciar do Windows, e utilize a seguinte sintaxe:
exp usuario/senha@orcl file=c:\temp\teste.dmp full=y
- “usuario”: Nome do usuário do banco Oracle.
- “senha”: Senha do usuário do banco.
- “orcl”: Nome da instância do banco (sempre digitar @ entre a senha e a instância).
- “file”: Insira o caminho que deseja colocar o arquivo exportado, barra (\) e o nome que deseja para o arquivo e a extensão .dmp no final
SQL's que mais consomem o banco de dados
O SQL disponibilizado abaixo trará os SQL's que mais consomem o banco, desse modo fica mais simples de verificar se tem algum SQL processando sem necessidade, ou que possa ser arrumado. Copie esse SQL na sua ferramenta de banco Oracle e execute-o.
SELECT "SQL_TEXT",
"PARSING_SCHEMA_NAME",
"SQL_ID",
"ELAPSED_TIME_MIN",
"PERC_ELAPSED_TIME_MIN",
"EXECUTIONS",
"FIRST_LOAD_TIME",
"LAST_ACTIVE_TIME"
FROM ( SELECT SQL_TEXT,
PARSING_SCHEMA_NAME,
SQL_ID,
CAST (ELAPSED_TIME / 1000000 / 60 AS NUMERIC (18, 2))
AS ELAPSED_TIME_MIN,
CAST (
(RATIO_TO_REPORT (ELAPSED_TIME) OVER ()) * 100 AS NUMERIC (18, 2))
PERC_ELAPSED_TIME_MIN,
EXECUTIONS,
FIRST_LOAD_TIME,
TO_CHAR (LAST_ACTIVE_TIME, 'DD/MM/YYYY HH24:MI:SS')
AS LAST_ACTIVE_TIME
FROM V$SQL
WHERE PARSING_SCHEMA_NAME IN ('EMA')
ORDER BY CAST (ELAPSED_TIME / 1000000 / 60 AS NUMERIC (18, 2)) DESC)
WHERE ROWNUM <= 100;