Arquivo do Autor: andre

Novidades do 11

Publicado em por
Responder

Novidades do 11G

Outro dia, conversando com um amigo DBA, ele me informou que não houve muitas mudanças no 11G. Então me questionou se eu havia pesquisado ou estudo sobre o assunto, foi ai que eu vi a necessidade de me informar sobre a nova versão. Aqui no Brasil, ao contrario do que já escutei de alguns americanos, o 11G ainda não entrou totalmente no gosto de todas as empresas até onde eu sei. Bom, talvez simplesmente pelo fato de aguardar a release 2 para evitar que um novo patch tenha que ser aplicado ? Todas as versões do oracle tem se mostrado muito a altura dos requisitos empresarias, inclusive até mesmo excedendo as expectativas. Assim, vamos la:

PARAMETRIZAÇÕES

DIAGNOSTICO

No 11G, foram substituídos os antigos parâmetros:
• USER_DUMP_DEST
• BACKGROUND_DUMP_DEST
• CORE_DUMP_DEST
Como todos sabemos, estes parametros serviam para designer o local de log, alterta, trace, e erros do usuario sempre eram gerados arquivos nestas pastas.
Agora usaremos o parâmetro DIAGNOSTIC_DEST que por padrão fica na pasta $ORACLE_HOME/diag.

GERENCIAMENTO AUTOMATICO DE UNDO

Sem maiores surpresas, o gerenciamento de undo é agora por padrão como automático, cuidado, altere este parâmetro ao efetuar a migração.

CONTROL_MANAGEMENT_PACK_ACCESS

Este parâmetro devera estar como DIAGNOSTIC+TUNING (padrão), para que as ferramentas de diagnostico, AWR, ADDM e a de tuning SQL tuning advisor, sql access advisor sejam alimentadas com informações e estejam disponíveis para uso.

HOT PATCH – PATCH A LIVE

Uma nova modalidade de se aplicar um patch, dessa forma não é necessário a parada do banco de dados. Os usuários continuam acessando a base e você poderá aplicar o patch normalmente. Utilizando ainda o comando opatch via linha de comando para aplicar correções ao banco oracle, sem a necessidade de paradas, recompilação do binário do oracle ou reinicialização da instancia. O patch do tipo HOT PATCH esta disponível em linux e solaris, e ainda existe um consumo extra de memória ao ser executado.

NOVIDADES PARA O ASM

Quando um dos discos pertencente a um grupo de discos ASM era perdido ou danificado, eram movidos todas as extensões para os discos restantes o disco em seguida era automaticamente removido. A opção FAST MIRROR reduz significativamente o tempo requerido para esta re-sincronização. Assim, o fast mirror faz com que somente a informação alterada seja mapeada para depois ser novamente aplicada neste disco a partir do ponto em que estiver disponível novamente.

A operação pode ser monitorada através do EM:

Exemplo de instrução SQL que devera ser executado na instancia ASM:

ALTER DISKGROUP SET ATTRIBUTE ‘DISK_REPAIR_TIME’=’1D4H50M’ ;

DISCOS PREFERENCIAIS DE ESPELHAMENTO

Discos Preferenciais podem ser designados atraves do parametro ASM_PREFERRED_READ_FAILURE_GROUPS. É um parâmetro dinâmico que informa quais são os grupos de discos preferenciais para se executar o espelhamento. Para visualizar a configuração, pode também se ler uma nova coluna que foi adicionada a view V$ASM_DISK – PREFERRED_READ, que mostra se o grupo de discos é preferenciais no caso de uma falha. Este parâmetro foi adicionado na pagina de administração do ASM, na aba de configuração.

MELHORIAS COM RELAÇÃO AS EXTENSÕES

Agora são criadas extensões do tamanho do arquivo, o ASM suporta agora extensões de tamanhos variáveis para reduzir a utilização da shared pool, e suportar o maior tamanho possível de arquivos. Não é necessária nenhum controle manual da desfragmentação.

ATRIBUIÇÃO SYSASM

Uma nova atribuição (role) foi criada para que fosse atribuída aos DBAs que necessitem administrar as instancias ASM. A responsabilidade SYSDBA foi descontinuada para o gerenciamento das instancias ASM no 11G. Somente na release 1 ainda é usado o sysdba, portanto utilize o sysasm ao invés do sysdba.

Pode se verificar na view V$PWFILE_USERS através da nova coluna SYSASM, indicando se o usuário poderá se conectar através do privilegio SYSASM ou não.

Novos atributos para o ASM DISKGROUP

Estes atributos se configurados nos discos, poderão ser consultados através da view V$ASM_ATTRIBUTE.

AU_SIZE – Tamanho da unidade de alocação, podendo ser 1,2,4,8,16,32,64MB
Compatible.rdbms – Parâmetro útil em ambientes heterogenios, para informar a versão do banco de dados. Determina o formato da mensagem entre a instancia ASM e a instancia Oracle.
DISK_REPAIR_TIME – Quantidade de tempo antes da remoção de um disco para offline.
TEMPLATEname.REDUNDANCY – Redundância para um template.
TEMPLATEname.STRIPE – Atributo de stripping do tipo coarse e fine para o template.

Comandos úteis ASM:

Para verificar a consistência de um diskgroup, verifique a partir do comando:
ALTER DISKGROUP DATA CHECK;

ALTER DISKGROUP DATA REPAIR;

ALTER DISKGROUP DATA DISMOUNT;

ALTER DISKGROUP DATA MOUNT RESTRICT;
O modo de montagem restrito é uma novidade no 11G, assim os clients nao podem conectar a este diskgroup, assim o poder de balanceamento é melhorado.

ALTER DISKGROUP DATA MOUNT;

ALTER DISKGROUP DATA MOUNT FORCE;

O padrao é sempre NOFORCE, mas se for necessário pode se utilizar o comando FORCE para tentar montar um grupo de discos, se algum dos discos esteja offline. Isso faz com que correções de configurações sejam executadas, como ASM_DISKSTRING. Mas se os discos não ficarem online, mesmo assim não será possível monta-los.

DROP DISKGROUP DATA FORCE INCLUDING CONTENTS;
Este commando força a remocao de um diskgroup. Força a remoção de um diskgroup que não é possível de se montar. É necessário incluir, com a opção force – including contents.

COMANDOS UTEIS ASMCMD

Através do prompt de comando ASMCMD é possível executar alguns comandos úteis, para isso utilize o asmcmd help;
Cp. Lsdsk, md_backup, md_restore full ou nodg ou newdg.

Os commandos md_backup permitem que seja executado o backup de metadados da instancia ASM.

BANCO DE DADOS STAND BY

Outra novidade muito bem vinda no 11G é o stand by database, que alem das atribuições normais de uma banco de dados standby ainda permite com que seja efetuadas consultas ou alterações no banco de dados standby. A partir do banco de dados físico, recebe informações de redo continuamente. Muito legal essa funcionalidade ! Digam qual o banco que podemos fazer isso ?

NOVA FUNCIONALIDADE – PERFORMANCE ANALYZER

O performance analyzer é uma nova funcionalidade que ao que eu entendo vai desbancar as ferramentas de performance de sql. Ele é integrado ao SQL tuning advisor e ele constroi varias versões de uma única consulta (opa que legal) e de quebra ainda faz a avaliação de estatísticas e performance de cada uma das consultas.

Bom, pra nós simples mortais – mostra uns relatórios comparativos entre as consultas. O que significa que nos ajuda demais no trabalho de comparação de performance entre as consultas executadas, é o máximo.

DBCA – PREPARADO PARA ASMM

O dbca já esta preparado para o gerenciamento automático de memória. Isso faz com que ele seja preparado para o gerenciamento automático no ato da criação do banco de dados.

DUPLICAR O BANCO DE DADOS

Conseguimos agora, duplicar o banco de dados com o enterprise manager, e o que é muito legal porque as
sim podemos criar um banco de dados de teste em minutos ! Esta tarefa devera ser feita com o RMAN.

IMPORTAR O CATALOGO
Podemos importar o catalogo de recuperação do rman de outros catálogos de recuperação. Isso nos ajuda bastante no ato da recuperação, visto que se caso no arquivo de controle não houver nenhuma informação de metadados de backup, então teremos que importar as informações seja de conjuntos de backup ou ainda de outro catalogo de backup.

No rman com a versão 11G ainda é possível criar uma versão de catalogo privado, fazendo com que o somente o usuário que estiver com a permissão RECOVERY_CATALOG_OWNER poderá então lista as informações sobre os metadados.

Alterar o sqlprompt ou prompt do sqlplus

Publicado em por
Responder

Para isso iremos alterar um arquivo chamado login.sql, e essa tarefa nos ajudara porque mostrara informacoes importantes, como o nome do banco que voce esta logado, para diferenciar da producao e da homologacao por exemplo. Assim iremos adiante:

Alterar o codigo original do arquivo glogin.sql:

$ORACLE_HOME/sqlplus/admin/glogin.sql

Aqui iremos adicionar as linhas:

SET SQLPROMPT “TESTE> “

Sendo que assim que voce se conectar ira informar em qual cliente esta usando, se e o da producao. Isso serve simplesmente para alterar o nome do prompt. Pode se ainda tentar alterar o prompt para o nome, mas isso serviria no cliente e nao no banco visto que sempre tem que se informar usuario e string de conexao.

SET SQLPROMPT “&_USER’@’&_CONNECT_IDENTIFIER > “

Criar uma rotina bkp oracle

Publicado em por
Responder

SQL> conn / as sysdba
Conectado.
SQL> shutdown immediate;
Banco de dados fechado.
Banco de dados desmontado.
InstΓncia ORACLE desativada.
SQL> startup mount;
InstΓncia ORACLE iniciada.

Total System Global Area 494927872 bytes
Fixed Size 1288240 bytes
Variable Size 180357072 bytes
Database Buffers 310378496 bytes
Redo Buffers 2904064 bytes
Banco de dados montado.
SQL> alter database archivelog;

Banco de dados alterado.

SQL> alter database open;

Banco de dados alterado.

SQL> archive log list;
Modo log de banco de dados Modo de Arquivamento
Arquivamento automßtico Ativado
Destino de arquivamento USE_DB_RECOVERY_FILE_DEST
A seqⁿΩncia de log on-line mais antiga 2179
Pr≤xima seqⁿΩncia de log a arquivar 2180
SeqⁿΩncia de log atual 2180
SQL> show parameter DB_RECOVERY_FILE_DEST

NAME TYPE VALUE
———————————— ———– ——————————
db_recovery_file_dest string C:oraclexeapporacleflash_r
ecovery_area
db_recovery_file_dest_size big integer 10G
SQL>

Conteudo do arquivo bkdiariorman.rc
run {
backup database plus archivelog delete all input;
delete noprompt obsolete;
crosscheck archivelog all;
delete noprompt expired archivelog all;
delete noprompt expired backup;
}

Conteudo do arquivo BAT
rman target / @C:bkpORACLEbkdiariorman.rc

Configurar o RMAN

C:Documents and SettingsAdministrator>rman target /

Gerenciador de Recuperaτπo: Release 10.2.0.1.0 – Production on Sßb Mar 15 16:07:
45 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

conectado ao banco de dados de destino: XE (DBID=2477763744)

RMAN> quit

C:Documents and SettingsAdministrator>rman target /

Gerenciador de Recuperaτπo: Release 10.2.0.1.0 – Production on Sßb Mar 15 16:11:
43 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

conectado ao banco de dados de destino: XE (DBID=2477763744)

RMAN> show all;

usar o arquivo de controle do banco de dados de destino em vez do catßlogo de re
cuperaτπo
os parΓmetros de configuraτπo RMAN sπo:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128’; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘C:ORACLEXEAPPORACLEPRODUCT10.2.0SE
RVERDATABASESNCFXE.ORA’; # default

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

novos parΓmetros de configuraτπo RMAN:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
os novos parΓmetros de configuraτπo RMAN foram armazenados com sucesso

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

novos parΓmetros de configuraτπo RMAN:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
os novos parΓmetros de configuraτπo RMAN foram armazenados com sucesso

RMAN>

Recompilar todos objetos invalidos de todos esquemas

Publicado em por
Responder

Use sempre a $ORACLE_HOME/rdbms/admin/ultrp.sql

sqlplus / as sysdba

sql>@$ORACLE_HOME/rdbms/admin/ultrp.sql;

Conectado a:
Oracle Database 10g Express Edition Release 10.2.0.1.0 – Production

SQL> @C:oraclexeapporacleproduct10.2.0serverRDBMSADMINutlrp.sql

TIMESTAMP
—————————————————————————–

COMP_TIMESTAMP UTLRP_BGN 2008-03-15 16:01:59

DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like ‘UTL_RECOMP_SLAVE_%’;
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like ‘UTL_RECOMP_SLAVE_%’;
DOC>#

Procedimento PL/SQL concluφdo com sucesso.

TIMESTAMP
—————————————————————————–

COMP_TIMESTAMP UTLRP_END 2008-03-15 16:02:05

Procedimento PL/SQL concluφdo com sucesso.

DOC> The following query reports the number of objects that have compiled
DOC> with errors (objects that compile with errors have status set to 3 in
DOC> obj$). If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC>#

OBJECTS WITH ERRORS
——————-
0

DOC> The following query reports the number of errors caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC>#

ERRORS DURING RECOMPILATION
—————————
0

Procedimento PL/SQL concluφdo com sucesso.

AdvertΩncia: VocΩ nπo estß mais conectado ao ORACLE.
SQL>
Conectado.
SQL> select count(*) from user_objects;

COUNT(*)
———-
195

SQL> select count(*) from user_objects where status = ‘INVALID’;

COUNT(*)
———-
0

SQL> select count(*) from user_objects where status = ‘INVALID’;

COUNT(*)
———-
0

SQL>

retençao no AWR

Publicado em por
Responder

Para reduzir a retenção do AWR

EXEC dbms_workload_repository.drop_snapshot_range (low_snap_id=>1107, high_snap_id=>1108);
— Reduzir a retencao para dois dias.

exec dbms_workload_repository.modify_snapshot_settings(retention => 2880, interval => 60, topnsql => ‘DEFAULT’);

— Verificar o status da retencao atual do AWR

select
extract( day from snap_interval) *24*60+
extract( hour from snap_interval) *60+
extract( minute from snap_interval ) “Snapshot Interval”,
extract( day from retention) *24*60+
extract( hour from retention) *60+
extract( minute from retention ) “Retention Interval”
from dba_hist_wr_control;

retention = snapshot interval (1 hr ) X 24 X X 7 days
For each week it’s 10080

– Retain data for 21 days ( 3 weeks )
exec dbms_workload_repository.modify_snapshot_settings(retention => 30240, interval => 60, topnsql => ‘DEFAULT’);

– Retain data for 28 days (4 weeks

SQL> desc dba_hist_snapshot;
Nome Nulo? Tipo
—————————————– ——– —————————-

SNAP_ID NOT NULL NUMBER
DBID NOT NULL NUMBER
INSTANCE_NUMBER NOT NULL NUMBER
STARTUP_TIME NOT NULL TIMESTAMP(3)
BEGIN_INTERVAL_TIME NOT NULL TIMESTAMP(3)
END_INTERVAL_TIME NOT NULL TIMESTAMP(3)
FLUSH_ELAPSED INTERVAL DAY(5) TO SECOND(1)

SNAP_LEVEL NUMBER
ERROR_COUNT NUMBER

SQL>

Drop AWR snapshots in range

declare
v_max number;
v_min number;
begin

select max(snaP_id) ,min(snap_id)
into v_max, v_min
from dba_hist_snapshot;

dbms_workload_repository.drop_snapshot_range (low_snap_id=>v_min, high_snap_id=> v_max);
end;

MAX(SNAP_ID) MIN(SNAP_ID)
———— ————
14360 14176

Drop AWR snapshots in range

EXEC dbms_workload_repository.drop_snapshot_range (low_snap_id=>14176, high_snap_id=>14360);

Criar coleta de estatisticas no 10G

Publicado em por
Responder

create procedure ESTATISTICA
is
begin
— Usuarios que serao contemplados.
DBMS_STATS.gather_schema_stats(‘ADMUSER’);
DBMS_STATS.gather_schema_stats(‘PRIVUSER’);
DBMS_STATS.gather_schema_stats(‘TSMSYS’);
end;
/
— Criar o JOB

DECLARE
job NUMBER;
BEGIN
DBMS_JOB.SUBMIT(job,’begin ESTATISTICA; END;’,sysdate,’sysdate+24′);
END;
/

FLUSH na SGA

Publicado em por
Responder

Quando a area de buffer cache, log buffer e shared pool esta cheia ou,
precisamos dar uma “limpada” nestas areas para que o analise do performance seja feito, precisamos então executar o comando alter system flush.
Com a consulta abaixo você consegue enxergar quais sao os objetos atualmente no buffer cache.

SELECT o.owner,
o.object_type,
substr(o.object_name,1,10)
objname,
b.objd,
b.status,
count(b.objd)
FROM v$bh b, dba_objects o
WHERE b.objd = o.data_object_id
AND o.owner not in (‘SYS’,’SYSTEM’,’SYSMAN’)
GROUP BY o.owner,
o.object_type,
o.object_name,
b.objd,
b.status;

Se caso, alguns objetos persistem em ficar na memória, iremos entao fazer a limpeza dessa area:

SQL> alter system flush buffer_pool;

Com o bloco abaixo conseguimos verificar se o pool atingiu mais de 70% e então se caso necessario podemos acionar a limpeza..

CREATE OR REPLACE VIEW sys.sql_summary AS SELECT
username,
sharable_mem,
persistent_mem,
runtime_mem
FROM sys.v_$sqlarea a, dba_users b
WHERE a.parsing_user_id = b.user_id;

BEGIN

CURSOR get_share IS
SELECT SUM(sharable_mem)
FROM sys.sql_summary;

CURSOR get_var IS
SELECT value
FROM v$sga
WHERE name like ‘Var%’;

CURSOR get_time is
SELECT SYSDATE
FROM dual;

todays_date DATE;
mem_ratio NUMBER;
share_mem NUMBER;
variable_mem NUMBER;
cur INTEGER;
sql_com VARCHAR2(60);
row_proc NUMBER;

BEGIN

OPEN get_share;
OPEN get_var;

FETCH get_share INTO share_mem;
DBMS_OUTPUT.PUT_LINE(‘share_mem: ‘||to_char(share_mem));

FETCH get_var INTO variable_mem;
DBMS_OUTPUT.PUT_LINE(‘variable_mem: ‘||to_char(variable_mem));

mem_ratio:=share_mem/variable_mem;
DBMS_OUTPUT.PUT_LINE(‘mem_ratio: ‘||to_char(mem_ratio));

IF (mem_ratio>0.3) THEN
DBMS_OUTPUT.PUT_LINE (‘Flushing Shared Pool … Limpeza a vista’);
cur:=DBMS_SQL.open_cursor;
sql_com:=’ALTER SYSTEM FLUSH SHARED_POOL’;
DBMS_SQL.PARSE(cur,sql_com,dbms_sql.v7);
row_proc:=DBMS_SQL.EXECUTE(cur);
DBMS_SQL.CLOSE_CURSOR(cur);
END IF;
END;
/

Inserir linha nula para verificar o comportamento das funções de agrupamento no Oracle

Publicado em por
Responder

Como todos sabem, as funções de agrupamento não levam em consideração os atributos que estão com valor NULL nas linhas. Assim fizemos um teste para comprovar a atuação do count(*). O resultado era esperado que quando utilizassemos a função de agrupamento count(*) ele entao iria verificar que a linha estava nula e nao contabilizasse essa linha. Mas o Oracle armazena duas pseudo colunas que são: ROWID e ROWNUM, e quando executo count(*) estas colunas sao contempladas para efeito de calculo e o retorno de total de linhas inseridas com valor nulo é retornado.

SQL> create table TOTO (CODIGO NUMBER);

Tabela criada.

SQL> insert into TOTO VALUES(NULL);

1 linha criada.

SQL> /

1 linha criada.

SQL> /

1 linha criada.

SQL> /

1 linha criada.

SQL> /

1 linha criada.

SQL> select * from toto;

CODIGO
———-

SQL> select count(*) from toto;

COUNT(*)
———-
5

SQL>
SQL> select count(codigo) from toto;

COUNT(CODIGO)
————-
0

SQL> select rowid, rownum, codigo from toto;

ROWID ROWNUM CODIGO
—————— ———- ———-
AAAMrXAABAAAOpaAAA 1
AAAMrXAABAAAOpaAAB 2
AAAMrXAABAAAOpaAAC 3
AAAMrXAABAAAOpaAAD 4
AAAMrXAABAAAOpaAAE 5

SQL>

Time out no ISQLPLUS

Publicado em por
Responder

Para aumentar o timeout do isqplus faça a seguinte alteracao:

Va ate o arquivo:

C:oracleproduct10.2.0db_1oc4jj2eeoc4j_applicationsapplicationsisqlplusisqlplusWEB-INF

abra o arquivo: web.xml

encontre a entrada abaixo:

15

aumente o valor de 15 minutos para um tempo maior.
O tempo pode ser aumentado de 1 to 1440 minutos.

Reinicie o isqplus com o comando no prompt do dos ou linux:

isqplusctl stop
isqplusctl start