BLOG RODRIGO ALMEIDA

Olá,

Acompanhando o twitter do Eddie Awad, ele postou um link super interessante sobre básicas diferenças entre o Oracle Server e MS SQL Server, vale a pena dar uma olhada e analisar os pontos que um DBA que trabalha com ambas bases de dados descreveu como fundamentais.

O link para acompanhar a discussão está aqui: Basic Differences between Oracle and SQL Server.

Quem tiver mais sugestões, dúvidas e ideias, vamos comentando abaixo.

Abraços,

Olá,

Uma das táticas mais “sujas”, diga-se de passagem, é a alteração de senha do usuário sem a sua permissão, pois pode ocorrer em diversos momentos do dia-a-dia, por exemplo:

• O cara saiu de férias, é deixou algum objeto no owner dele.
• Preciso pegar algumas informações da tabela do FULANO.
• É necessário fornecer algumas permissões do usuário X para Y.
• Ou a MELHOR! Existe um owner na aplicação que foi criado em 1900 e bolinhas, e agora, precisa de manutenção e ninguém tem acesso a esse usuário, porque ninguem sabe a senha.

Bom, para resolver esses “probleminhas”, existe uma técnica no Oracle que podemos utilizar para ter acesso completo a um específico usuário, um pequeno “hack” no dicionário Oracle, mas para conseguir a façanha, é necessário que tenha acesso a view DBA_USERS, que foi utilizado nesse exemplo.

LEMBRANDO

Lógicamente, que todos os exemplos que citei acima, poderiam ser feitos pelo DBA da empresa ou alguém que tenha acesso a usuários gerenciais do banco de dados, como SYSTEM, usuários com role de DBA e etc. Isso é apenas um exemplo de como se aplicar a técnica.

Agora, vou passar o exemplo prático de como funciona.

1) Vamos criar um usuário.

@id


HORA EXECUTADA
-------------------
09-09-2008 11:45:57

INSTANCE_NAME   HOST_NAME            STATUS
--------------- -------------------- ----------
xe              DBARODRIGO          OPEN

USER IS "SYS"

create user RODRIGO
identified by rodrigo;

Usuário criado.

grant create session to RODRIGO;

Concessão bem-sucedida.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

2) Teste a conexão do novo usuário no banco de dados.

conn rodrigo/rodrigo

Conectado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

3) Conectado com um usuário administrativo, faça um select básico na view DBA_USERS.

conn system

Informe a senha:

Conectado.

select username, account_status, password
    from dba_users
    where username = 'RODRIGO';

USERNAME ACCOUNT_STATUS PASSWORD

—————————— ——————————– ——————————

RODRIGO OPEN F697FBF0BB2DA2EC

4) Altere a senha do usuário desejado, no exemplo, vou alterar a senha para FERNANDA.

alter user RODRIGO identified by FERNANDA;

Usuário alterado.

5) Pegue o valor gerado para a nova senha.

select username, account_status, password
  from dba_users
  where username = 'RODRIGO';

USERNAME ACCOUNT_STATUS PASSWORD

—————————— ——————————– ——————————

RODRIGO OPEN FB34D454E9FFDE18

Observação
Pode parecer confuso, mais vamos recapitular os valores que são equivalentes as senhas:
F697FBF0BB2DA2EC = RODRIGO
FB34D454E9FFDE18 = FERNANDA

6) Para voltar a senha anterior, apenas utilize a opção VALUES junto com IDENTIFIED BYcom o valor da coluna password.

conn system

Informe a senha:

Conectado.

alter user RODRIGO identified by values 'F697FBF0BB2DA2EC';

O valor F697FBF0BB2DA2EC (gerado por um algoritmo HASH), é equivalente ao valor RODRIGO.
Agora, veja os testes.

conn rodrigo/fernanda

Conectado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

conn system

Informe a senha:

Conectado.

alter user RODRIGO identified by values 'F697FBF0BB2DA2EC';

Usuário alterado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

conn rodrigo/rodrigo

Conectado.

disco

Desconectado de Oracle Database 10g Express Edition Release 10.2.0.1.0 - Production

Como eu não alterei o valor para a senha FERNANDA, se eu tentar logar com essa senha, terei erros, veja.

conn rodrigo/fernanda

ERROR:

ORA-01017: invalid username/password; logon denied

FINISH!

Uma técnica de hack bem conhecida entre os DBAS, que até a versão 10gR2 (no Patchset 10.2.0.4) ainda continua, eu não sei ainda se nas versões 11g já possui algum tipo de segurança nesse ponto, então aprecie com moderação.

ATUALIZAÇÃO

Para as versões 11g essa técnica não é mais aplicada devido as alterações estruturais no banco de dados por parte de segurança, que ficou muito mais confiável. Então, essa técnica se aplica até a versão Oracle Database 10g Release 2.

Abraços,

Olá,

Semana passada o nosso velho e bom amigo Metalink ficou de cara nova, e também com um apelido novo, chamado agora de My Oracle Support (Site: http://metalink.oracle.com), criado boa parte em Flash e com novas funcionalidades integradas ao SCM (Software Configuration Manager), apresentou uma cara bem bonita e uma razoável navegação.

Abaixo mostro um pequeno screenshot da nova tela inicial do Metalink, ou My Orale Support.

Ao acessar o metalink, algumas novidades apareceram como: Dashboard, Community, Reports e Collector. O mais bacana das opções é o Dashboard, que sumariza todas as informações da sua conta em uma única tela, tais informações como seus SR (Service Request - ou TAR), informações sobre suas bases que estão coletando informação pelo SCM (Software Configuration Manager), inventário e Projects . O screenshot mostra a tela de dashboards.

O metalink sempre foi o canal para entrar em contato com o suporte da Oracle, para aqueles problemas difíceis de se resolver, a qualidade do suporte não mudou muita coisa, continua o mesmo (Quem usa sabe!), porém ao abrir um SR (ou TAR), você pode ter mais integração com o suporte e informação disponível da sua conta em um pequeno boxtext, como apresentado abaixo.

O My Oracle Support está com bons recursos, entre eles, podemos destacar:

MapView

Ao abrir um SR, você já pode mencionar em qual banco de dados está o problema, atribuindo as informações que estão armazenadas no repositório da Oracle ao SR. Essas informações são retiradas dos relatórios de RDA ou pelos coletores do SCM.

PowerView

Um recurso do My Oracle Support que permite filtrar informações por região do aplicativo, customizando as informações que acordo com o seu interesse. As regiões podem ser Knowledge base, Projects, System, System Health e Service Request.

System Health

Um monitor que analisa a saúde de seus bancos de dados e aplicativos, como Application Server e EBS (E-Bussiness Suite), monitora informações de segurança, patch e recomendações. Ótimo para equipes que querem atuar com pró-atividade.

Web Seminars

Dentro da região Knowledge, existe a opção Tools and Training > Training (Web Seminars). Uma ótima sacada da Oracle para seus profissionais. A intenção é fornecer seminários e treinamentos gratuitos para seus produtos de suporte, como RDA, SCM, E-Bussiness Diagnostics entre outros. Dessa forma, trabalhar de acordo com os padrões Oracle e entender todas as ferramentas e seus respectivos fluxos de chamado.

Esses são apenas alguns itens que gostei de comentar sobre a nova ferramente da Oracle de suporte, para quem já é assinante Metalink, vale a pena dar uma navegada no site e descobrir muito mais coisas. O site em sí ainda é meio lento, mesmo para quem usa conexão DSL ou dedicada está bom, mas, para quem não gostou mesmo do site e ainda prefere a versão antiga, em todas as páginas existe o Link para Classic Metalink.

ATUALIZAÇÃO - (13/01/2010)

Bom, como o post foi escrito há um tempo atrás, vou atualizar com algumas experiências que tive nesse tempo com o My Oracle Support, são elas:

SCM

A Oracle está investindo forte no uso do SCM (Software Configuration Manager) que trás todas as informações do banco de dados para um repositório web e agiliza a abertura de chamados junto ao suporte da Oracle. Esse integração é bem interessante e permite que o DBA controle as informações técnicas e gerenciais do banco de dados de forma simples e rápida, fornecendo uma pró-atividade da equipe.

O ponto ruim é configurar esse plug-in em bases de produção, pois necessita de configurações extras nos servidores para acesso a web pelo protocolo HTTP, e quando se necessita usar proxy, as coisas ficam mais complicadas.

PERFORMANCE DO My Oracle Support

Uma coisa que ninguem podia reclamar do antigo Metalink era a sua facilidade e performance. Como era bem simples e praticamente um HTML dinâmico, a nova versão do My Oracle Support em flash, realmente deixou bem pesado a navegação e acesso ao contéudo. Isso é devido a tecnologia que utilizam no desenvolvimento do software.

Abraços,

Olá,

Vou mostrar uma tática bem legal de diminuir um banco de dados Oracle físicamente, sem mexer em extents (por shrink table), rebuild de índices ou realizar desfragmentação de segmentos (por Export\Import Utility) no banco de dados.

O principal ponto que iremos atacar será os espaços livres desnecessários alocados na tablespace, que consomem espaços em disco preciosos no sistema operacional, toda essa tarefa será guiada atráves da marca d’água (HWM - High Water Mark) dos datafiles onde podemos realizar um RESIZE no datafile para um valor menor sem a perda de dados.

Lembrete

Essa tarefa envolve alguns conceitos de Oracle, como os de Marca D’água, ou HWM - High Water Mark, esse tema eu vou abordar em outro post para melhor entendimento. OK!

Para iniciarmos os trabalhos, vamos analisar o tamanho do nosso banco de dados e quanto ele está ocupando em disco, abaixo, vou fazer dois SELECTS que passa essas informações para nós e depois um print da quantidade em disco utilizado e livre no sistema operacional.

select sum(bytes)/1024/1024 as "TamanhoFisico(MB)" from dba_data_files;

TamanhoFisico(MB)
—————–
76000

col "FileSystem" format a12

select substr(file_name,1,4) as "FileSystem", sum(bytes)/1024/1024 as "Tamanho(MB)"
from dba_data_files
group by rollup(substr(file_name,1,4))
order by substr(file_name,1,4);

FileSystem Tamanho(MB)
———— ———–
/u01 25800
/u02 50200
76000

Percebemos, que no meu banco de dados, tenho quase 26GB de datafiles no FileSystem /u01 e mais 50GB no FileSystem /u02, totalizando os 76GB que é o tamanho total do meu banco de dados. O importante é saber o que esse valor representa na minha máquina, em questão de consumo e escabilidade, veja o que a máquina ainda pode oferecer.

[oracle@pelspos18 ~]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 3.2G 6.3G 34% /
/dev/sda1 190M 13M 168M 8% /boot
none 2.0G 0 2.0G 0% /dev/shm
/dev/sda5 2.0G 36M 1.9G 2% /tmp
/dev/sda6 114G 51G 58G 48% /u01
/dev/sdb1 134G 50G 78G 40% /u02

Para o FileSystem /u01, representa 48% de utilização, já para o FileSystem /u02, representa 40% de utilização. Claro, que tudo isso, irá depender de como o aplicativo e banco de dados se comporta, se é um banco de dados com crescimento acentuado diário, mensal ou semestral, tudo isso influência. Mas, no exemplo que estou utilizando, o banco de dados tem um crescimento em média de 3GB por mês, então, está adequado.

Mas, eu preciso liberar mais espaço em disco para fazer alguns backups em disco, exports e etc. Então, vou diminuir meu banco de dados físicamente de forma segura, como eu disse no início do post.

Para fazer isso, preciso da mais algumas informações como, Tamanho Físico e Livre das tablespace, que pode ser pego facilmente pelos SELECTS abaixo.

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_data_files
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
——————– ———–
FIN_CPAG 400
FIN_CEXT_IDX 800
USERS 800
TOOLS 1500
SYSAUX 2000
SYSTEM 2000
FIN_CORP 3500
FIN_CORP_IDX 5000
FIN_CPAG_IDX 8000
UNDOTBS 10000
FIN_CREC_IDX 12000
FIN_CREC 30000

12 linhas selecionadas.

Bom, as tablespaces SYSTEM e SYSAUX não é novidade para ninguem, então, elas vou deixar-las de fora da atividade, para não ocorrer nenhum tipo de problema. Vou apenas pensar nas demais, inclusive na de UNDO. Perceba que esse é apenas um SELECT para ver o tamanho total das tablespaces, agora, quero saber quanto cada uma tem livre, para poder direcionar os RESIZES. Abaixo segue o tamanho livre por tablespace.

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_free_space
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
——————– ———–
FIN_CREC_IDX 2,1875
FIN_CPAG 398,5625
USERS 642,5625
FIN_CEXT_IDX 799,5625
TOOLS 1495,3125
SYSTEM 1738,8125
SYSAUX 1869,125
FIN_CORP_IDX 2456,4375
FIN_CORP 3259,6875
FIN_CPAG_IDX 5289,375
FIN_CREC 8625,125
UNDOTBS 9865,375
12 linhas selecionadas.

Apenas mudei a view do primeiro SELECT, de dba_data_files para dba_free_space. Com isso, podemos ver quem tem mais espaço livre e saber quem precisa, existe tablespace com 8GB livres, e outros com 2,3 e 5G livres, só nisso, deixando apenas 10% livre, podemos economizar 12GB em disco. E ainda sem pensar no UNDO.

Agora, vamos executar um SELECT que irá analisar a marca d’água dos datafiles e verificar se existe a possibilidade de realizar um RESIZE para um valor menor, com isso, liberar espaço em disco no sistema operacional. Esse SELECT precisa de uma atenção especial, pois, é necessário informar o tamanho do db_block_size do seu banco de dados para efetuar corretamente os cálculos.

Para saber o tamanho do seu db_block_size, basta fazer o seguinte procedimento.

NO SQLPLUS, faça:

show parameters db_block_size

NAME TYPE VALUE
———————————— ———– ——————————
db_block_size integer 8192

Se preferir, poderá ver na v$parameter, como no exemplo.

col name format a15

col value format a15

select name, value from v$parameter where name = 'db_block_size';

NAME VALUE
————— —————
db_block_size 8192

Agora, o momento esperado, o SELECT para realizar a operação de resize, veja.

select 'alter database datafile ''' || file_name || ''' resize ' ||
ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 )  || 'm;' cmd
from dba_data_files a,
( select file_id, max(block_id+blocks-1) hwm
  from dba_extents
  group by file_id ) b
where a.file_id = b.file_id(+)
and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) < ceil( blocks*8192/1024/1024)
and ceil( (nvl(hwm,1)*8192*1.2)/1024/1024 ) > 100

Lembrete
Veja que onde está 8192 no script acima, é referente ao tamanho do db_block_size do seu banco de dados, esse valor então poder ser 2048, 4096, 8192, 16384 e 32768.

O script acima irá gerar um resultado sobre espaço livre, tamanho atual, espaço que pode ser salvo, total de espaço que pode ser liberado por datafile do seu banco de dados, tudo isso gerado pelos cálculos sobre a marca d’água de cada datafile. Se atentem pois ele está pegando todas as tablespaces do banco de dados e isso para nós não é necessário, podemos excluir a tablespace SYSTEM e SYSAUX.

FILE_NAME SMALLEST CURRSIZE SAVINGS SMALLEST_SAFE SAVINGS_SAFE
———————————————————— ———- ———- ———- ————- ————
/u02/app/oracle/oradata/finp/fin_corp01.dbf 125 2000 1875 149 1851
/u02/app/oracle/oradata/finp/sysaux01.dbf 191 2000 1809 229 1771
/u02/app/oracle/oradata/finp/system01.dbf 264 2000 1736 316 1684
/u02/app/oracle/oradata/finp/fin_corp02.dbf 117 1500 1383 140 1360
/u01/app/oracle/oradata/finp/fin_cpag_idx04.DBF 643 2000 1357 771 1229
/u01/app/oracle/oradata/finp/fin_cpag_idx03.dbf 651 2000 1349 781 1219
/u01/app/oracle/oradata/finp/fin_cpag_idx02.dbf 692 2000 1308 830 1170
/u01/app/oracle/oradata/finp/fin_cpag_idx01.dbf 728 2000 1272 873 1127
/u01/app/oracle/oradata/finp/fin_corp_idx02.dbf 847 2000 1153 1016 984
/u01/app/oracle/oradata/finp/fin_corp_idx01.dbf 897 2000 1103 1076 924
/u02/app/oracle/oradata/finp/fin_crec09.dbf 1284 2000 716 1540 460
/u02/app/oracle/oradata/finp/fin_crec08.dbf 1288 2000 712 1545 455
/u02/app/oracle/oradata/finp/fin_crec07.dbf 1304 2000 696 1564 436
/u02/app/oracle/oradata/finp/fin_crec06.dbf 1314 2000 686 1576 424
/u02/app/oracle/oradata/finp/fin_crec05.dbf 1331 2000 669 1597 403
/u02/app/oracle/oradata/finp/fin_crec04.dbf 1334 2000 666 1600 400
/u02/app/oracle/oradata/finp/fin_crec01.dbf 1351 2000 649 1622 378
/u02/app/oracle/oradata/finp/fin_crec02.dbf 1351 2000 649 1621 379
/u02/app/oracle/oradata/finp/fin_crec03.dbf 1351 2000 649 1621 379
/u02/app/oracle/oradata/finp/users01.dbf 158 800 642 189 611
/u02/app/oracle/oradata/finp/fin_crec15.dbf 1427 2000 573 1712 288
/u02/app/oracle/oradata/finp/fin_crec14.dbf 1547 2000 453 1856 144
/u02/app/oracle/oradata/finp/fin_crec13.dbf 1549 2000 451 1858 142
/u02/app/oracle/oradata/finp/fin_crec12.dbf 1551 2000 449 1861 139
/u02/app/oracle/oradata/finp/fin_crec11.dbf 1603 2000 397 1923 77
/u01/app/oracle/oradata/finp/fin_corp_idx03.dbf 802 1000 198 962 38

26 linhas selecionadas.

CMD
——————————————————————————
alter database datafile ‘/u02/app/oracle/oradata/finp/system01.dbf’ resize 316m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec11.dbf’ resize 1923m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec02.dbf’ resize 1621m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec07.dbf’ resize 1564m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_corp02.dbf’ resize 140m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec05.dbf’ resize 1597m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec06.dbf’ resize 1576m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec03.dbf’ resize 1621m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec08.dbf’ resize 1545m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_corp_idx01.dbf’ resize 1076m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec01.dbf’ resize 1622m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec09.dbf’ resize 1540m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec12.dbf’ resize 1861m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec14.dbf’ resize 1856m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec15.dbf’ resize 1712m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx01.dbf’ resize 873m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx04.DBF’ resize 771m;
alter database datafile ‘/u02/app/oracle/oradata/finp/sysaux01.dbf’ resize 229m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec13.dbf’ resize 1858m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_crec04.dbf’ resize 1600m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx02.dbf’ resize 830m;
alter database datafile ‘/u02/app/oracle/oradata/finp/fin_corp01.dbf’ resize 149m;
alter database datafile ‘/u02/app/oracle/oradata/finp/users01.dbf’ resize 189m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_corp_idx02.dbf’ resize 1016m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_corp_idx03.dbf’ resize 962m;
alter database datafile ‘/u01/app/oracle/oradata/finp/fin_cpag_idx03.dbf’ resize 781m;

26 linhas selecionadas.

Uma coisa boa que essse script já fornece o comando de DDL para redimensionar o datafile da tablespace sem a perda de dados. Basta executar.

Após a execução dos scripts, vamos analisar os resultados gerados. Primeiramente, vamos ver agora o tamanho total e o espaço livre das tablespaces, depois verificar como ficou o espaço em disco no sistema operacional e saber o quanto ganhamos com isso.

Espaço total das tablespace

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_data_files
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
——————– ———–
USERS 189
FIN_CORP 289
FIN_CPAG 400
FIN_CEXT_IDX 800
TOOLS 1500
SYSAUX 2000
SYSTEM 2000
FIN_CORP_IDX 3054
FIN_CPAG_IDX 3255
UNDOTBS 10000
FIN_CREC_IDX 12000
FIN_CREC 25496

12 linhas selecionadas.

Espaço livre nas tablespace

select tablespace_name, sum(bytes)/1024/1024 as "TAMANHO(MB)"
from dba_free_space
group by tablespace_name
order by sum(bytes);

TABLESPACE_NAME TAMANHO(MB)
———————– ———–
FIN_CREC_IDX 2,1875
USERS 31,5625
FIN_CORP 48,6875
FIN_CPAG 398,5625
FIN_CORP_IDX 510,4375
FIN_CPAG_IDX 544,375
FIN_CEXT_IDX 799,5625
TOOLS 1495,3125
SYSTEM 1737,3125
SYSAUX 1811,5
FIN_CREC 4121,125
UNDOTBS 9797,4375

12 linhas selecionadas.

Espaço no sistema operacional

[oracle@pelspos18 u01]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.9G 3.2G 6.3G 34% /
/dev/sda1 190M 13M 168M 8% /boot
none 2.0G 0 2.0G 0% /dev/shm
/dev/sda5 2.0G 36M 1.9G 2% /tmp
/dev/sda6 114G 45G 64G 42% /u01
/dev/sdb1 134G 42G 86G 33% /u02

Conclusões

Perceba que algumas tablespace permaneceram do mesmo tamanho e algumas tiveram mais que 10% do seu tamanho reduzido, o melhor que podemos notar no sistema operacional que o FileSystem /u02 que antes tinha 78GB disponível, agora tem 86GB, uma diferença de 8GB, para o FileSystem /u01 que atens tinha 58GB disponível, agora tem 64GB, uma diferença de 6GB, que somando com o valor anterior, podemos reutilizar 14GB de espaço no sistema operacional.

O tamanho do nosso banco de dados fisicamente, também diminuiu, foi para 62GB. Antes era de 76GB, 14GB a menos, justamente o que nós não utilizamos mais.

O que pode nos ajudar a redução física do banco de dados?

Pode nos ajudar em N tarefas, como:

• Não deixar o banco de dados travar por problemas de ARCHIVE ERROR;
• Reaproveitamente de espaço em disco;
• Diminuição de arquivos de backup gerados pelo RMAN em nível 0;
• Ajuda na escabilidade do servidor;

Acho que isso já são boas razões para se pensar em fazer uma diminuição física do seu banco de dados.

Abraços,

Olá,

Uma dos principais conceitos sobre arquitetura física do Oracle, é a marca D’água, uma tradução de HWM  - High Water Mark, ele que indica o limite que uma tabela já ocupou de espaço físico no seu banco de dados. Mas, vamos um pouco mais a fundo.

O que é uma Marca D’água (HWM - High Water Mark)?

A marca d’água é o limite do número de blocos que uma tabela pode estar utilizando, resumindo para um conceito mais simples, toda vez que uma tabela recebe um INSERT (novos registros), essa marca na tabela aumenta dizendo ao Oracle Server a quantidade de blocos que a tabela está utilizando, automaticamente, a quantidade de blocos, multiplicado, pelo tamanho do db_block_size do banco de dados, diz o valor físico real que está sendo utilizado.

Mas, esse valor real não é o valor que o Oracle irá alocar, pois irá depender de alguns outros pontos, como:

• Se a tabela está sendo gerenciada por sí própria ou pela tablespace.
• Irá depender dos tamanhos dos extents, exemplo, INITIAL_EXTENT e NEXT_EXTENT.
• Também, irá depender do tipo de gerenciamento, se é SEGMENT MANAGEMENT AUTO ou UNIFORM.
• E a quantidade de blocos que um EXTENT pode suportar.

Vamos ver como funciona a marca d’água na prática, um alguns exemplos práticos.

Vou criar uma tabela simples, chamada TSTDBA.

create table TESTE (a varchar2(100) not null, b number(7) not null);

Tabela criada.

Agora, vamos analisar como está a estrutura para o Oracle, pois a tabela não possui nenhum valor e nenhuma estatística coletada.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
from dba_tables
where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA

Até o momento, tudo sem surpresas para nós.

Então, vamos popular essa tabela com alguns registros, veja o exemplo.

declare
     contador integer;
begin
     contador := 1;
     while contador <= 1000 loop
               insert into TSTDBA values ('TESTE',contador);
               contador := contador + 1;
       end loop;
       commit;
 end;

Procedimento PL/SQL concluído com sucesso.

exec dbms_stats.gather_table_stats (ownname=>'RODRIGO',tabname=>'TSTDBA',estimate_percent=>null,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Procedimento PL/SQL concluído com sucesso.

Verifiquem que fiz um pequeno bloco PL/SQL para inserir dados em minha tabela, cerca de 1.000 registros. Após isso, preciso dizer ao Oracle, como a tabela está, seu volume e outras coisas mais, então, fiz um analyze na tabela para atualizar as informações estruturais dela no dicionário Oracle, ao fazer o analyze com o DBMS_STATS, o resultado do SELECT acima, agora é esse.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
from dba_tables
where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA                                  5            0       1000 06-10-2008 19:42:08

Veja, a nossa tabela está utilizando 5 blocos, o db_block_size do meu banco de dados é de 8KB, então, resumidamente, ele deveria estar utilizando cerca de 40KB, certo?

select 8192*5 from dual;

8192*5
———-
40960

Mas, se consultar o seu tamanho na dba_segments temos:

select segment_name, sum(bytes)/1024 from dba_segments where segment_name = 'TSTDBA' group by segment_name;

SEGMENT_NAME                                                                      SUM(BYTES)/1024
——————————————————————————— —————
TSTDBA                                                                                         64

O resultado para o tamanho da tabela TSTDBA é 64KB, porque, o INITIAL_EXTENT da tabela é de 64KB, e como os 1.000 registros ocuparam apenas 40KB, um único extent consegui suportar.

select initial_extent/1024, next_extent from dba_tables where table_name = 'TSTDBA';

INITIAL_EXTENT/1024 NEXT_EXTENT
——————- ———–
64

Pois bem! Rodrigo, e o tal do HWM, até onde está entrando nisso?

Vamos começar a brincar agora, veja que após o analyze, minha tabela TSTDBA está utilizando 5 blocos de dados, certo? Teoricamente, se eu fizer um TRUNCATE TABLE, eu não vou mais utilizar nenhum bloco, e minha marca d’água deveria baixar, mas, acontece isso:

truncate table TSTDBA;

Tabela truncada.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
  2  from dba_tables
  3  where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA                                  5            0       1000 06-10-2008 19:44:18

A minha tabela continua com se estivesse com 5 blocos, o que isso pode nos prejudicar:

• Esse exemplo é bem simples, mas para tabelas com milhares de registros, poderá influenciar os FULL-TABLES SCANS.
• Ao realizar um INSERT convencional, ou seja, sem o hint /* + APPEND */, ele irá procurar por bocos livres e irá consumir CPU e demorar um tempo para sua execução.
• Se minha marca d’água estiver muito alta, ou seja, estiver armazenando um alto valor de blocos utilizados, e você sabe, que ele não está utilizando tudo isso, você terá uma alocação de EXTENTS desnecessários no banco de dados, e isso irá ocupar espaço desnecessários.

Caso eu quisesse diminuir o tamanho do meu segmento de tabela, eu não iria conseguir, pois além da marca d’água é inferior aos meus 64KB, pois bem, tente realizar um insert agora de 2.000.000 de registros e vamos ver o que acontece.

declare
       contador integer;
    begin
       contador := 1;
       while contador <= 2000000 loop
               insert into TSTDBA values ('TESTE',contador);
               contador := contador + 1;
       end loop;
       commit;
   end;

Procedimento PL/SQL concluído com sucesso.

exec dbms_stats.gather_table_stats (ownname=>'RODRIGO',tabname=>'TSTDBA',estimate_percent=>null,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Procedimento PL/SQL concluído com sucesso.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
    from dba_tables
    where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA                               4654            0    2000000 06-10-2008 22:37:24

show parameters db_block_size

NAME                                 TYPE        VALUE
———————————— ———– ——————————
db_block_size                        integer     8192

select (8192*4654)/1024/1024 as "Tamanho" from dual;

Tamanho
———-
36,359375

select segment_name, sum(bytes)/1024/1024 from dba_segments where segment_name = 'TSTDBA' group by segment_name;

SEGMENT_NAME                                                                      SUM(BYTES)/1024/1024
——————————————————————————— ——————–
TSTDBA                                                                                              37

Se quizer analisar melhor como ficou a distribuição, veja a dba_extents, abaixo vou mostrar apenas um pequeno resumo da quantidade de extents alocados e seus respectivo tamanho.

select segment_name, count(extent_id), sum(bytes)/1024/1024
    from dba_extents
    where segment_name = 'TSTDBA'
    group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
——————– —————- ——————–
TSTDBA                             52                   37

Bom, vimos que agora temos um valor legal de extents alocados, e mesmo após o TRUNCATE continuo com uma alocação de extents, que totaliza os 37MB da tabela, então, minha marca d’água está posicionado no 51° extent, que seria o limite do numeros de blocos alcançados.

Conseguimos entender como funciona a marca d’água, o que isso pode nos causar?

A chamada fragmentação de tabela, além da marca d’água elevar o número de extents no dicionário, prejudicando muitas vezes os planos de execução e os table full scans, vamos ter também perca de espaço físico para a tablespace, espaço que não poderam ser alocados por outro segmento. Vamos a uma demostração prática de como funciona a fragmentação.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
    from dba_tables
    where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA                               4654            0    2000000 06-10-2008 22:37:24

select segment_name, count(extent_id), sum(bytes)/1024/1024
    from dba_extents
    where segment_name = 'TSTDBA'
    group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
——————– —————- ——————–
TSTDBA                             52                   37

A minha tabela TSTDBA continua com seus 2.000.000 de registros, após o analyze acima, vimos que está a atual estrutura da tabela, e se realizarmos diversos DELETES em grandes quantidades, o que poderemos ter?

delete from TSTDBA where b between 10000 and 20000;

10001 linhas deletadas.

delete from TSTDBA where b between 50000 and 200000;

150001 linhas deletadas.

delete from TSTDBA where b between 400000 and 700000;

300001 linhas deletadas.

delete from TSTDBA where b between 1000000 and 1300000;

300001 linhas deletadas.

commit;

Commit concluído.

select segment_name, count(extent_id), sum(bytes)/1024/1024
    from dba_extents
    where segment_name = 'TSTDBA'
    group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
——————– —————- ——————–
TSTDBA                             52                   37

Vamos passar um analyze para validar toda a estrutura da tabela.

exec dbms_stats.gather_table_stats (ownname=>'RODRIGO',tabname=>'TSTDBA',estimate_percent=>null,method_opt=>'FOR ALL COLUMNS SIZE AUTO',degree=>6);

Procedimento PL/SQL concluído com sucesso.

Veja o resultado para os novos valores.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
    from dba_tables
    where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA                               4654            0    1239996 06-10-2008 23:09:01

A quantidade de extents não alterou depois de apagarmos diversos registros, isso causa a conhecida fragmentação do segmento, mesmo que após calcularmos a quantidade de registro exato da tabela.

select segment_name, count(extent_id), sum(bytes)/1024/1024
    from dba_extents
    where segment_name = 'TSTDBA'
    group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
——————– —————- ——————–
TSTDBA                             52                   37

Para resolvermos esse problema de fragmentação, bastamos reconstruir o mapa binário da tabela, para isso, apenas use um MOVE sem mencionar a tablespace que resolve nosso problema.

alter table TSTDBA move;

Tabela alterada.

select owner, table_name, blocks, empty_blocks, num_rows, to_char(last_analyzed,'DD-MM-RRRR HH24:MI:SS') as "ANALYZE"
    from dba_tables
    where table_name = 'TSTDBA';

OWNER      TABLE_NAME                         BLOCKS EMPTY_BLOCKS   NUM_ROWS ANALYZE
———- —————————— ———- ———— ———- ——————-
RODRIGO    TSTDBA                               4654            0    1239996 06-10-2008 23:09:01

select segment_name, count(extent_id), sum(bytes)/1024/1024
    from dba_extents
    where segment_name = 'TSTDBA'
    group by segment_name;

SEGMENT_NAME         COUNT(EXTENT_ID) SUM(BYTES)/1024/1024
——————– —————- ——————–
TSTDBA                             38                   23

PRONTO! Veja que após nosso “rebuild” na tabela, liberamos cerca de 15MB para a tablespace, fazendo apenas uma reconstrução dos extents da tabela.

Existem muitos outros conceitos envolvidos sobre a alocação de extents, sem mencionar os freelists, gerenciamento das tablespaces e diferenças entre os segmentos de tabela e índice, tudo isso foi apenas um modo de ilustrar os problemas que podem causar perda de performance em nossos ambientes.

Existe uma matéria que escrevi para a iMasters algum tempo atrás que explica com um pouco mais de detalhes como funciona a arquitetura de armazenamento lógico do banco de dados Oracle, o artigo Arquitetura de armazenamento lógico, que sanar algumas dúvidas.

A idéia principal do post foi iniciar desde o conceito de HWM (High Water Mark) até sua fragmentação, passando por várias fases, para fornecer um melhor entendimento de como a arquitetura Oracle funciona.

Abraços,

Olá,

Alguns profissionais iniciantes em Oracle, ainda tem muitas dúvidas sobre diversos conceitos de arquitetura do banco de dados Oracle, por isso, resolvi discutir sobre um ponto bem importante, O que é um Control file?

Tradução

Control file = Arquivo de Controle, tradução em português para a palavra que é muito utilizado na literatura Oracle brasileira.

Visão Geral

Contéudo

Um arquivo de controle possui diversas informações de um banco de dados que é requerida pela instância. Durante o processo de startup ou uma operação normal, somente o Oracle Server pode modificar as informações no arquivo de controle, deste modo, nenhum DBA ou usuário pode modificar seu contéudo.

As informações que o arquivo de controle possui são:

• Nome do banco de dados
• Data de criação do banco de dados
• Os nomes e localizações de cada datafile e redo log associados ao banco de dados
• Informações sobre as tablespaces
• Possíveis datafiles com status offline
• O histórico de logs
• Sobre os archives gerados
• Backupsets e backup pieces, gerados pelo RMAN
• Backups de datafiles e informações de redo log
• Cópia de datafiles
• O valor atual do número da sequência do log
• Informações de checkpoint

Para cada datafile ou redo log que é adicionado, renomeado, modificado ou excluído do banco de dados, o arquivo de controle é atualizado pelo Oracle Server para garantir a modificação da estrutura física da base. Essas modificações pode ser:

• O Oracle pode identificar os datafiles e redo logs que foram abertos durante o processo de startup
• Identificar os arquivos que são necessários ou disponíveis em caso de recuperação do banco de dados

Portanto, para cada modificação na estrutura física do banco de dados, podendo ser feito atráves do comando ALTER DATABASE, é altamente recomendado que seja feito um backup do seu arquivo de controle para evitar possíveis problemas no próximo processo de startup do banco de dados.

Como o arquivo de controle armazena informações sobre os checkpoints, a cada três segundos, o processo de plano de fundo (CKPT) registra as posições do redo log, essas posições serão utilizadas posteriormente  durante um processo de recuperação do banco de dados, onde o Oracle irá dizer se todas as entradas dos grupos de redo log serão necessárias para realizar tal recuperação.

Referência

Oracle Concepts 10g Documentation

Abraços,

Olá,

Uma dos maiores problemas de realizar uma recuperação completa ou uma restauração de um banco de dados para um novo servidor, é o problema de mencionar o DBID (Database Identifier - Identificação do banco de dados) para o catálogo do RMAN.

Pois, para conseguir uma restauração da base, é necessário mencionar o DBID ao catálogo de recuperação para conseguir associar o banco de dados no catálogo e posteriormente restaurar e recuperar seus backups sets.

Agora, vamos mencionar quais os meios que podemos encontrar o DBID de um banco de dados.

1. Dicionário de dados

Podemos realizar um simples select na view v$database para conseguir a informação, veja.

select dbid from v$database;

      DBID
----------
4263396950
1 linha selecionada.

2. RMAN - Inicío de sessão

O DBID também é informado quando você conecta ao RMAN, lembrando, que o DBID será informado se o banco de dados estiver em MOUNT ou OPEN, se apenas com NOMOUNT, não será informado, pois não irá ler o arquivo de controle, ou control file. Exemplo.

[oracle@PELSPOWMS2 ~]$ rman

Recovery Manager: Release 10.2.0.1.0 - Production on Thu Oct 23 17:15:23 2008
Copyright (c) 1982, 2005, Oracle.  All rights reserved.

RMAN> connect target 'rman/##########@wmssp.world';

connected to target database: WMSSP (DBID=4263396950)

3. RMAN - Usando o comando List incarnation

Outro modo de se conseguir o DBID do banco de dados, é após logar-se no banco de dados target e estar conectado ao catálogo de recuperação, utilizar o comando LIST INCARNATION, exemplo:

RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
——- ——- ——– —————- — ———- ———-
8451    8458    WMSSP    4263396950       PARENT  1          30/06/2005 19:09:40
8451    8452    WMSSP    4263396950       CURRENT 446075     27/02/2008 09:03:20

Uma dica muito importante é sempre manter uma planilha com todos os bancos de dados, senhas e seus respectivos DBID armazenados após as criação do banco de dados para não correr risco de não saber o DBID do banco de dados criado.

Abraços,

Olá,

Algumas semanas atrás, tive um problema com um banco de dados que eu tinha acabado de criar, um caso muito estranho, tudo funcionava perfeitamente e no outro dia, o banco não iniciava por problemas de ORA-600, poderia ser um caso de pesquisar no Metalink para resolver o problema, mas por curiosidade, resolvi analisar de onde pelo menos esse erro acontecia ou tentar saber o que poderia ter acontecido com meu hardware. O erro exato do ORA-600, está abaixo:

ORA-00600: internal error code, arguments: [2252], [1903], [3499988641], [], [], [], [], []

Como eu estava tentando entender o problema, fui pesquisar sobre o primeiro argumento do ORA-600, o argumento 2252, onde ele se referia a categoria de base 2000, que é referente a funcionalidade do Cache Layer, porém, como o argumento exato é 2252, estava relacionada diretamente a funcionalidade de RCV (Recovery), e o valor 252 é para diversas funcionalidades voltadas ao SCN.

O erro sempre acontecia no momento que eu tentava abrir o banco de dados, executando o ALTER DATABASE OPEN, fora isso, meu banco de dados conseguia montar sem problemas! Então, começei a levantar algumas informações sobre o hardware, como por exemplo:

• O servidor já tinha 5 anos de uso.
• Fabricante DELL.
• O sistema operacional, tinha acabado de ser instalado, estava sobre a Plataforma Linux Red Hat EL AS 4 em 32-Bits, observando os logs do SO, também não encontrava problemas.
• O banco de dados, recém instalado e configurado.

O problema estava misterioso, quando resolvi analisar cuidadosamente o erro no alert.log, e me deparei com alvo assim:

Wed Jan  9 23:45:57 2002
Successful mount of redo thread 1, with mount id 1181935665
Wed Jan  9 23:45:57 2002
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Wed Jan  9 23:46:07 2002
alter database open
Wed Jan  9 23:46:07 2002
Errors in file /u01/app/oracle/admin/esdp/udump/esdp_ora_31553.trc:
ORA-00600: internal error code, arguments: [2252], [1903], [3499988641], [], [], [], [], []
Wed Jan  9 23:46:08 2002
ORA-600 signalled during: alter database open...

Lembra que disse que eu tive problemas há algumas semanas atrás, isso é no ano de 2008, todos os registros de alerta estavam com a data de 2002!! Resolvi apenas executar um DATE no Linux diretamente para ver a data, quando me deparei com o ano de 2002 também!

O argumento que o ORA-600 estava apontando estava correto, na trava certa, pois quando criei o banco de dados e realizei o import de várias dados atráves do datapump, meus primeiros archives e entradas de REDO, estava com a data de 2008, quando o servidor perdeu essa data e regrediu, é correto o Oracle Server afirmar que não consegue fazer um Automatic Recovery da instância, quando realiza a abertura do banco, pois como um banco de dados pode começar os primeiros archives na data de 2008 e depois pedir uma recuperação de 2002!!! Meio complicado.

Só para compreender melhor, olhe como estava a minha área de db_recovery:

[oracle@pelspos13 archivelog]$ ls -R
.:
2002_01_05  2008_07_31  2008_08_01  2008_08_04  2008_08_11
./2002_01_05:
o1_mf_1_1_y3dz9wbt_.arc   o1_mf_1_81_y3dx0npt_.arc  o1_mf_1_83_y3dx2ftp_.arc
o1_mf_1_80_y3dx3gmy_.arc  o1_mf_1_82_y3dx1496_.arc
./2008_07_31:
./2008_08_01:
./2008_08_04:
./2008_08_11:
o1_mf_1_82_4b1r5349_.arc
[oracle@pelspos13 archivelog]$

Sendo que os archives da data de 05/01/2002, seria “teoricamente” os archives mais recentes!!!

Agora, a causa disso tudo, simples! A bateria da placa mãe do servidor, como essa bateria já deveria estar com problemas, quando o servidor era reiniciado, ele voltava para a data de fabricação da placa, e com isso, todo o sistema operacional também voltava, e consequentemente, meu banco de dados.

Como trabalhava no modo ARCHIVELOG, ao abrir o banco de dados, apresentava esse erro bonito. Se for analisar, é um erro “besta”, que poderia ser resolvido rapidamente, mas, um simples erro, muitas vezes é díficil de se perceber.

Abraços,

Olá,

Pessoal, no site da DBAPool existe uma rádio virtual que fornece um podcast sobre a tecnologia Oracle, o programa é Tea and Tech e está na sessão Radio do site.

Essa semana o podcast está com o tema Oracle 11g Security, que faz uma visão geral sobre as políticas e caractéristicas de segurança de Oracle Database 11g. Vale a pena ouvir o podcast.

Abraços,

–

Hi Folks,

On the DBAPool website exist a virtual radio that provide a podcast about Oracle Tecnology, the program is  Tea and Tech and it’s available on radio menu.

This week’s, the podcast it’s with theme  Oracle 11g Security, which is an overview about the policies and security features of Oracle Database 11g. It’s worth checking.

Regards,

Olá,

Tudo bem pessoal! Espero tenham passado um bom Natal e Ano novo, foi semanas de descando e reflexão. Pois bem, Ano Novo (2010) e notícias novas para a comunidade Oracle Brasileira.

Em Dezembro de 2009, a Oracle Corporation consagrou mais um Oracle Ace no Brasil, para o profissional Antonio Jose Rodrigues Neto que trabalha na Netapp, segue o seu perfil no Oracle Ace Directories.

Meus Parabéns Neto pelo prêmio e as boas-vindas ao time de Oracle Aces da America Latina. Agora já são quatro integrantes brasileiros que já receberam o prêmio da Oracle.

E um outro assunto que gostaria de compartilhar com vocês. Ano passado publiquei um artigo nos blogs e no portal iMasters sobre QUE TIPO DE DBA É VOCÊ? Que é apenas são alguns pontos de vista sobre os tipos de DBA existentes no mercado.

E vasculhando a internetm, achei no site do Don Burleson um artigo que ele publicou que possui o mesmo título, What type of DBA are you? (Que tipo de DBA é você?) que vale a pena ler e dar algumas risadas, ele expressa o seu ponto de vista sobre os tipos de dba existentes, o texto está em inglês.

Abraços,