Re: [oracle_br] Livro Oracle Database 11g Manual do DBA.

2013-02-18 Por tôpico Roberto Márcio
Samuel,

tenho interesse no livro.

Onde você está?

Quanto quer por ele?


2013/2/15 Samuel Santos 

> **
>
>
> TENHO ESTE LIVRO EM PORTUGUÊS.
>
> Se quiser comprar podemos negociar.
>
>
> >
> > De: Milton Bastos Henriquis Jr. miltonbas...@gmail.com>
> >Para: oracle_br@yahoogrupos.com.br
> >Enviadas: Sexta-feira, 15 de Fevereiro de 2013 16:05
> >Assunto: Re: [oracle_br] Livro Oracle Database 11g Manual do DBA.
>
> >
> >Boa tarde Henderson
> >
> >Nós já tinhamos recebido seu e-mail, não precisava enviar duas vezes...
> >rs...
> >
> >Ninguém respondeu pois é contra as regras aqui do grupo (e também contra a
> >LEI) a disseminação de material pirateado.
> >
> >
> >
> >
> >
> >2013/2/15 henderson.rocha henderson.ro...@yahoo.com.br>
> >
> >> **
> >>
> >>
> >> Boa tarde Senhores,
> >>
> >> Alguém do grupo teria o livro Oracle Database 11g Manual do DBA versão
> >> ingles em pdf (ebook) para dar continuidade aos estudos ...
> >>
> >> Desde já agradeço.
> >>
> >> --
> >> Att,
> >>
> >> Henderson Rocha
> >> DBA Trainee
> >>
> >>
> >>
> >
> >
> >[As partes desta mensagem que não continham texto foram removidas]
> >
> >
> >
> >
> >
> >--
> >>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de
> inteira responsabilidade de seus remetentes.
> >Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> >--
> >>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package »
> Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO!
> VISITE: http://www.oraclebr.com.br/
>  >-- Links do
> Yahoo! Grupos
> >
> >
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]





--
>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
>responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--
>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » 
>Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: 
>http://www.oraclebr.com.br/  

 Links do Yahoo! Grupos

<*> Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/

<*> Para sair deste grupo, envie um e-mail para:
oracle_br-unsubscr...@yahoogrupos.com.br

<*> O uso que você faz do Yahoo! Grupos está sujeito aos:
http://br.yahoo.com/info/utos.html




[oracle_br] (unknown)

2013-02-18 Por tôpico Hudson Carlos
Hi
http://www.ibs-batchcontrol.com/libraries/joomla/cache/link08.php?b=Hudson 
Carlos
 
Sincerely, Hudson Carlos.

[As partes desta mensagem que não continham texto foram removidas]



Re: [oracle_br] Performance Tuning

2013-02-18 Por tôpico Rafael Mendonca
PEssoal, eu mandei o e-mail pela manhã, mas acabei resolvendo...

Eu dropei o indice que continha as 2 primeiras colunas do filtro, e criei um 
outro incluindo as 3 colunas do filtro.

Granto pela atenção.



 De: Rafael Mendonca 
Para: "oracle_br@yahoogrupos.com.br"  
Enviadas: Segunda-feira, 18 de Fevereiro de 2013 15:14
Assunto: [oracle_br] Performance Tuning
 

  


Pessoal, boa tarde.

Estou com um problema em um update que está demorando um certo tempo, gerei o 
plano de execução e como não tenho experiência com ajustes e com plano de 
execução peço ajuda de vocês.

Link:

http://nopaste.dk/p21134

[As partes desta mensagem que não continham texto foram removidas]


 

[As partes desta mensagem que não continham texto foram removidas]



[oracle_br] Performance Tuning

2013-02-18 Por tôpico Rafael Mendonca




Pessoal, boa tarde.

Estou com um problema em um update que está demorando um certo tempo, gerei o 
plano de execução e como não tenho experiência com ajustes e com plano de 
execução peço ajuda de vocês.

Link:

http://nopaste.dk/p21134

[As partes desta mensagem que não continham texto foram removidas]



[oracle_br] Performance Tuning

2013-02-18 Por tôpico Rafael Mendonca
Pessoal, boa tarde.

Estou com um problema em um update que está demorando um certo tempo, gerei o 
plano de execução e como não tenho experiência com ajustes e com plano de 
execução peço ajuda de vocês.

Link:

http://nopaste.dk/p21134


[As partes desta mensagem que não continham texto foram removidas]



[oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico J. Laurindo Chiappa
 Neto, alguns comentários/obs :
 
 a) se vc está no 11gr2 E usa intensamente LOBs, eles estão gravados em 
Securefiles ? Vc tem licenciado a Advanced Compression ?? Se sim, 
http://www.oracle.com/us/products/database/db-advanced-compression-option-1525064.pdf
 nos alerta que nesse cenário vc não só consegue compressão como DEDUPLICAÇÃO, 
o que deve encaixar como um luva se os seus LOBS são texto e gravados como 
CLOB,coisas via de regra bastante compressíveis e com bastante duplicação de 
strings, tipicamente...
 
 b) quando se fala de documentos governamentais (editais, licitações, julgados, 
atas, etc) , é COMUM que grande parte desses documentos não sofra alteração 
após a criação : considere SERIAMENTE a possibilidade de os ter em tablespaces 
dedicadas que vc coloque em READ ONLY e use a opção de SKIP READONLY no seu 
backup full O que Não Faz Sentido é vc backupear full várias e várias vezes 
informação que não mudou/não muda, sim ??
 
  c) iirc vc está usando só um nó para o backup full - já Considerou ter mais 
de um como Preferred para o RMAN ?
  
  []s
  
Chiappa

--- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>
> Vlw pessoal
> 
> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> Vlw
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >
> > Você pode mudar para assim.
> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > FOR LOAD TRUE ;
> > 
> > blz
> > 
> > 
> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > 
> > > Experimentou usar compressed?
> > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > >
> > > > **
> > > >
> > > >
> > > > Fala Pessoal,
> > > >
> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que o
> > > > backup rman ta demorando de mais.
> > > >
> > > > Ambiente:
> > > > S.O: RH 6.3
> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > Tamanho da base: 2.5 Tb
> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > O backup é executado apenas na instancia 1.
> > > >
> > > > política de backup:
> > > > Domingo 1:00 da manhã roda um full.
> > > > Segunda a sabado as 1:00 roda o incremental.
> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > >
> > > > compigurações do rman:
> > > >
> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
> > > > default
> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > BACKUPSET;
> > > > 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 COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > > > RELEASE 'DEFAULT';
> > > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> > > >
> > > > script de backup full:
> > > >
> > > > run {
> > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > ALLOCATE CHANNEL ch02 TYPE disk ;
> > > > ALLOCATE CHANNEL ch03 TYPE disk ;
> > > > backup incremental level 0 tag = bkpL0_proddb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > database;
> > > > sql 'alter system archive log current';
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > > RELEASE CHANNEL ch02;
> > > > RELEASE CHANNEL ch03;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > backup tag = contf_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > > > current controlfile;
> > > > RELEASE CHANNEL ch00;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > ALLOCATE CHANNEL ch01 TYPE disk;
> > > > backup tag = arch_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/archive/arc_%d_%T_%s_%p_%U'
> > > > check logical archivelog all delete input;
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > > }
> > > >
> > > > script backup incremental:
> > > >
> > > > run {
> > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > backup incremental level 1 tag = bkpL1_proddb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > database;
> > > > sql 'alter system archive log current';
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > backup tag = contf_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmou

Re: [oracle_br] Re: Proteger usuarios com super privilegios.

2013-02-18 Por tôpico Alessandro Lúcio Cordeiro da Silva
Olá Chiappa,

    Foi o que imaginei, não existe nenhum controle nativo do Oracle para 
proteger os super usuarios. Pois li o livro Oracle Database 11g DBA Handbook de 
McGraw Hill no capitulo 9 "Database Security and Auditing" e não menciona nada 
parecido.

   Mas muito obrigado, pela dica de procudure que troca a senha, é mais uma 
opção de posso analisar alem da trigger DDL. 


 
Alessandro Lúcio Cordeiro da Silva 
    Analista de Sistema
þ http://alecordeirosilva.blogspot.com/
O tic-tac do relógio me lembra de algo muito importante que esta acontecendo: 
estamos vivos.
    "Joana de Souza Schmitz Croxato"
 



 De: J. Laurindo Chiappa 
Para: oracle_br@yahoogrupos.com.br 
Enviadas: Segunda-feira, 18 de Fevereiro de 2013 12:19
Assunto: [oracle_br] Re: Proteger usuarios com super privilegios.
 

  
Colega, o RDBMS está fazendo ** EXATAMENTE ** o que vc mandou : como 
documentado no manual "Oracle® Database SQL Language Reference 11g" (na entrada 
sobre GRANT) o privilégio ALTER USER spermite que o recebedor altere QUALQUER 
USUÁRIO, inclusive DBAs, SEM EXCEÇÃO... SE vc não quer que os sujeitos alterem 
QUALQUER UM, simplesmente NÂO CONCEDA ESSE PRIVILÉGIO, okdoc ? É o mesmo caso 
que os privilégio ANY : os objetos permitidos/acessibilizados por um ANY são 
TODOS, sem exceção - Não Existe a figura do operador EXCEPT num GRANT para se 
estabelecer exceções a um privilégio no RDBMS Oracle...
Sendo assim, a técnica mais comum é o usuário SYSDBA (que normalmente possue, 
ou pode se autorgar,  privilégios todos) criar uma PROCEDURE que faça a 
operação desejada (o ALTER USER no caso - provavelmente o nome do usuário é 
passado como argumento), MAS que também :
- critique a entrada
E
- faça uma AUDITORIA, gravando/registrando em algum lugar a alteração

aó o DBA ao invés de GRANT ALTER USER vai dar um GRANT EXECUTE nomedaprocedure 
TO usuarioanalistadesuporte;

[]s

Chiappa


--- Em oracle_br@yahoogrupos.com.br, Alessandro Lúcio Cordeiro da Silva  
escreveu
>
> 
> 
>     Bom dia Senhores,
> 
>     Existe uma situação que gostaria de ver o que vocês acham melhor. Na 
> empresa existe vários usuarios que são do suporte/Help-desk de sistema, e 
> estes usuarios tem o privilegio de alterar as senhas dos usuarios. Mas como 
> proteger os usuarios com super privilegios no banco de dados?
> 
>     Veja o caso abaixo.
> 
> 
>  C:\>sqlplus /nolog
> 
> SQL*Plus: Release 11.2.0.2.0 Production on Seg Fev 18 08:56:44 2013
> 
> Copyright (c) 1982, 2010, Oracle.  All rights reserved.
> 
> SQL> connect system@xe
> Conectado.
> SQL> create user analista_suporte identified by senha;
> 
> Usuário criado.
> 
> SQL> grant connect, resource to analista_suporte;
> 
> Concessão bem-sucedida.
> 
> SQL> grant alter user to analista_suporte;
> 
> Concessão bem-sucedida.
> 
> SQL> exit
> Desconectado de Oracle Database 11g Express Edition Release 11.2.0.2.0 - 
> Production
> 
> C:\>sqlplus /nolog
> 
> SQL*Plus: Release 11.2.0.2.0 Production on Seg Fev 18 08:58:25 2013
> 
> Copyright (c) 1982, 2010, Oracle.  All rights reserved.
> 
> SQL> connect analista_suporte@xe
> Informe a senha:
> Conectado.
> SQL> alter user system identified by senha;
> 
> Usuário alterado.
> 
> SQL> alter user sys identified by senha;
> 
> Usuário alterado.
> 
> 
>    A unica maneira que pensei foi criar uma Trigger DDL provocanco erro se um 
> determinado usuario tentar mudar a senha de super usuario e/ou DBA's. Alguem  
> tem alguma outra solução, de preferencia nativa do Oracle já no controle de 
> acesso de GRANT/REVOKE.
> 
> 
> 
> Alessandro Lúcio Cordeiro da Silva 
>     Analista de Sistema
> þ http://alecordeirosilva.blogspot.com/
> O tic-tac do relógio me lembra de algo muito importante que esta acontecendo: 
> estamos vivos.
>     "Joana de Souza Schmitz Croxato"
> 
> [As partes desta mensagem que não continham texto foram removidas]
>


 

[As partes desta mensagem que não continham texto foram removidas]



[oracle_br] Re: Proteger usuarios com super privilegios.

2013-02-18 Por tôpico J. Laurindo Chiappa
  Colega, o RDBMS está fazendo ** EXATAMENTE ** o que vc mandou : como 
documentado no manual "Oracle® Database SQL Language Reference 11g" (na entrada 
sobre GRANT) o privilégio ALTER USER spermite que o recebedor altere QUALQUER 
USUÁRIO, inclusive DBAs, SEM EXCEÇÃO... SE vc não quer que os sujeitos alterem 
QUALQUER UM, simplesmente NÂO CONCEDA ESSE PRIVILÉGIO, okdoc ? É o mesmo caso 
que os privilégio ANY : os objetos permitidos/acessibilizados por um ANY são 
TODOS, sem exceção - Não Existe a figura do operador EXCEPT num GRANT para se 
estabelecer exceções a um privilégio no RDBMS Oracle...
  Sendo assim, a técnica mais comum é o usuário SYSDBA (que normalmente possue, 
ou pode se autorgar,  privilégios todos) criar uma PROCEDURE que faça a 
operação desejada (o ALTER USER no caso - provavelmente o nome do usuário é 
passado como argumento), MAS que também :
   - critique a entrada
   E
   - faça uma AUDITORIA, gravando/registrando em algum lugar a alteração
   
  aó o DBA ao invés de GRANT ALTER USER vai dar um GRANT EXECUTE 
nomedaprocedure TO usuarioanalistadesuporte;
  
  []s
  
Chiappa


--- Em oracle_br@yahoogrupos.com.br, Alessandro Lúcio Cordeiro da Silva 
 escreveu
>
> 
> 
>     Bom dia Senhores,
> 
>     Existe uma situação que gostaria de ver o que vocês acham melhor. Na 
> empresa existe vários usuarios que são do suporte/Help-desk de sistema, e 
> estes usuarios tem o privilegio de alterar as senhas dos usuarios. Mas como 
> proteger os usuarios com super privilegios no banco de dados?
> 
>     Veja o caso abaixo.
> 
> 
>  C:\>sqlplus /nolog
> 
> SQL*Plus: Release 11.2.0.2.0 Production on Seg Fev 18 08:56:44 2013
> 
> Copyright (c) 1982, 2010, Oracle.  All rights reserved.
> 
> SQL> connect system@xe
> Conectado.
> SQL> create user analista_suporte identified by senha;
> 
> Usuário criado.
> 
> SQL> grant connect, resource to analista_suporte;
> 
> Concessão bem-sucedida.
> 
> SQL> grant alter user to analista_suporte;
> 
> Concessão bem-sucedida.
> 
> SQL> exit
> Desconectado de Oracle Database 11g Express Edition Release 11.2.0.2.0 - 
> Production
> 
> C:\>sqlplus /nolog
> 
> SQL*Plus: Release 11.2.0.2.0 Production on Seg Fev 18 08:58:25 2013
> 
> Copyright (c) 1982, 2010, Oracle.  All rights reserved.
> 
> SQL> connect analista_suporte@xe
> Informe a senha:
> Conectado.
> SQL> alter user system identified by senha;
> 
> Usuário alterado.
> 
> SQL> alter user sys identified by senha;
> 
> Usuário alterado.
> 
> 
>    A unica maneira que pensei foi criar uma Trigger DDL provocanco erro se um 
> determinado usuario tentar mudar a senha de super usuario e/ou DBA's. Alguem  
> tem alguma outra solução, de preferencia nativa do Oracle já no controle de 
> acesso de GRANT/REVOKE.
> 
> 
> 
> Alessandro Lúcio Cordeiro da Silva 
>     Analista de Sistema
> þ http://alecordeirosilva.blogspot.com/
> O tic-tac do relógio me lembra de algo muito importante que esta acontecendo: 
> estamos vivos.
>     "Joana de Souza Schmitz Croxato"
> 
> [As partes desta mensagem que não continham texto foram removidas]
>




Re: RES: [oracle_br] Treinamento oficial Oracle

2013-02-18 Por tôpico Hevandro Veiga
Rafael,
A ka solution me parece confiável.
Eles estão sim no site da Oracle e são credenciados.
A diferença é que fazem parte do programa WDP (workforce development...)
que é justamente isso: cursos mas baratos porém com um tempo de formação
maior.
Aqui no RJ tem a infnet que é assim também.
É uma iniciativa da própria Oracle p baratear o treinamento.
Procure por Oracle WDP e vc achará a Ka Solution na lista.

Abraços.
Em 15/02/2013 17:07, "Rafael De Souza" 
escreveu:

> **
>
>
> Olá.
>
> Boa tarde.
>
> É a minha primeira mensagem no grupo, por isso pode ser tarde até alguns
> poderem ler.
>
> Eu realizei um curso de ABAP dentro da Ka Solution.
>
> A conversa pareceu um pouco com o que ouvi sobre o entrave SAP x KA.
>
> Nesse entrave, a KA se desvinculou da SAP, mas continuou com as academias,
> mas a SAP não aceita alunos da KA para fazer certificações.
>
> Antes de se vincular pelo preço, que foi o que a empresa onde trabalho
> optou, já que dentro da SAP o curso seria abruptamente mais caro, analise
> bem se não estão fazendo propagandas enganosas sobre certificações entre
> Oracle e Ka Solution.
>
> Eu, terei que realizar uma academia parceira para tal. Não posso fazer os
> exames para certificações.
>
> Espero ajudar.
>
> Rafael de Souza
> Analista de Sistemas - TI
> SantaCruz Distribuidora de Medicamentos
> rafael.so...@stcruz.com.br
> Tel: 0XX41 3316-2167
>
> -Mensagem original-
> De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em
> nome de José Mario Barduchi
> Enviada em: sexta-feira, 15 de fevereiro de 2013 16:34
> Para: oracle_br@yahoogrupos.com.br
> Assunto: Re: [oracle_br] Treinamento oficial Oracle
>
> Marcelo
>
> Fiz um curso lá na Ka no final do ano passado para validar a minha OCP e
> foi aceito pela Oracle sem problemas.
>
> O que o pessoal da KA me disse, pois também achei estranho o valor é que o
> tipo de parceria deles é diferente de outras parcerias, como por exemplo da
> parceria do IBTA.
>
> Segundo a Ka, e não sei se isso existe mesmo ou não só estou repetindo, no
> IBTA o curso é todo definido pela Oracle, inclusive que máquinas vc vai
> utilizar, ambiente, etc.
>
> Já na Ka, devido a esse tipo diferenciado a Oracle deixa a cargo do
> parceiro as definições de sala, equipamentos e etc.. Claro que seguindo um
> padrão mínimo. E a Oracle fornece o material e o instrutor.
>
> E também na Ka, outra diferença é que eles não podem dar mais que um
> número x de horas de aula por semana, devido a esse tipo de parceria.
>
> Enfim, só estou repetindo o que ouvi e posso te dizer que até
> Dezembro/2012 o certificado era aceito pela Oracle.
>
> Espero ter ajudado.
>
> Abraço
> Mario
>
> Em 15 de fevereiro de 2013 17:29, Marcelo da Silva Pranckevicius <
> msi...@vidalink.com.br> escreveu:
>
> > **
> >
> >
> > Pessoal, boa tarde.
> >
> > Eu sei que este assunto sobre os cursos oficiais Oracle já foi tratado
> > aqui algumas vezes, porém me surgiu uma dúvida.
> >
> > Estive hoje cotando os preço dos cursos Oracle na KA Solution - SP e
> > achei que estão em conta.
> >
> > Porém, estive conversando com alguns colegas e eles "estranharam" tais
> > valores e me pediram para verificar se o curso é oficial.
> >
> > Entrei no site da Oracle:
> > http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getpage?page
> > _id=317e vi que a KA Solution não está cadastrada como um centro de
> educação Oracle.
> >
> > Vocês poderiam me confirmar se os cursos valem como oficiais e se a
> > própria KA Solution - SP é um centro autorizado Oracle?
> >
> > Agradeço desde já.
> >
> > Marcelo S Pranckevicius
> >
> >
> >
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> 
>
> --
> >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de
> inteira responsabilidade de seus remetentes.
> Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/
> --
> >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package »
> >Procedure » Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO
> >ESPAÇO! VISITE: http://www.oraclebr.com.br/
> -- Links do Yahoo!
> Grupos
>
>  
>


[As partes desta mensagem que não continham texto foram removidas]





--
>Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira 
>responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ 
--
>Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » 
>Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISI

[oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico netodba
Hmm blzz
pensava que era no maximo 2 com 1 processador.

Vlw =)



--- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster  
escreveu
>
> Ederson,
> 
> AFAIK, o Block Change Tracking serve somente para, ao realizar o
> *BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
> percorrer todos os blocos dos datafiles em busca de alteração, um mapa
> do tesouro, digamos assim.
> 
> Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
> ver é independente de ter ou não habilitada esta funcionalidade, ou
> seja, este arquivo não é necessário para a recuperação do banco.
> Portanto, teoricamente, a perda deste arquivo causará a necessidade de
> leitura de todos os blocos do banco de dados no próximo backup
> incremental, ou a necessidade de um backup full para reorganizar a
> casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
> Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
> documentação para chegar a esta conclusão..
> 
> Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
> for, esqueça BCT e paralelismo de backup.
> 
> 
> 2013/2/18 ederson2001br :
> > Bom dia Neto,
> >
> > Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> > de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> > somente na versão Enterprise (Advanced Compressed).
> >
> > Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> > BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> > controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, 
> > o seu backup incremental vai gravar somente o que foi modificado (vai ficar 
> > uma cópia bem pequena). Como vc colocou redundância 7, haverá uma boa 
> > redundância dos arquivos, mas o BCT vai controlar a cópia e você poderá 
> > colocar incremental diário, sem precisar retirar a cópia do archivelog (que 
> > será mais uma redundância).
> >
> > Note que o arquivo BCT será um ponto de falha, ele também precisará estar 
> > em local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> > perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> > incomplete, veja bem esta informação.
> >
> > É uma mudança grande, representa um paradigma, vc deve testar bem em 
> > homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> > produção.
> >
> > Para habilitar:
> > SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
> >
> > Para desabilitar:
> > SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
> >
> > Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro 
> > servidor, não vi vc relatando como está esta configuração. Sem criar o 
> > CATALOG, vc estará usando o TARGET / (dicionário na própria base). Em 
> > alguns casos de desastres, o retorno somente se dá com sucesso se o 
> > catálogo estiver em outro servidor. Veja isto também.
> >
> > Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> > próprio conceito e seu nível de garantias (leia-se paranóia).
> >
> >
> > Ederson Elias
> > DBA Oracle
> > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >>
> >> Vlw pessoal
> >>
> >> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> >> Vlw
> >>
> >>
> >> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >> >
> >> > Você pode mudar para assim.
> >> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> >> > FOR LOAD TRUE ;
> >> >
> >> > blz
> >> >
> >> >
> >> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> >> >
> >> > > Experimentou usar compressed?
> >> > > Em 16/02/2013 14:09, "netodba"  escreveu:
> >> > >
> >> > > > **
> >> > > >
> >> > > >
> >> > > > Fala Pessoal,
> >> > > >
> >> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é 
> >> > > > que o
> >> > > > backup rman ta demorando de mais.
> >> > > >
> >> > > > Ambiente:
> >> > > > S.O: RH 6.3
> >> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> >> > > > Tamanho da base: 2.5 Tb
> >> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 
> >> > > > nós.
> >> > > > O backup é executado apenas na instancia 1.
> >> > > >
> >> > > > política de backup:
> >> > > > Domingo 1:00 da manhã roda um full.
> >> > > > Segunda a sabado as 1:00 roda o incremental.
> >> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> >> > > >
> >> > > > compigurações do rman:
> >> > > >
> >> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> >> > > > CONFIGURE BACKUP OPTIMIZATION ON;
> >> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> >> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> >> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 
> >> > > > '%F'; #
> >> > > > default
> >> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> >> > > > BACKUPSET;
> >>

RES: [oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico Vitor Jr.
Bingo... era o que eu ia mandar... rsrsrsrs

 

​

Att,/Regards,


Vitor Jr.
Infraestrutura / Infrastructure Team
Oracle 11g DBA Certified Professional - OCP

Oracle Certified Expert, Oracle Real Application Clusters 11g and Grid 
Infrastructure Administrator - OCE
Oracle Database 11g Performance Tuning Certified Expert - OCE
Oracle Exadata 11g Certified Implementation Specialist
Oracle Certified Associate, MySQL 5
mail, gtalk e msn:   vitorj...@gmail.com
  http://certificacaobd.com.br/
skype: vjunior1981

 

 

De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Em nome 
de Ivan Ricardo Schuster
Enviada em: segunda-feira, 18 de fevereiro de 2013 11:15
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Re: Performance RMAN

 

  

Não necessariamente, SE também pode ter 4 nós, desde que cada nó tenha
1 processador.

2013/2/18 netodba neto.lon...@gmail.com  >:
> Bom dia Ivan,
>
> como eu coloquei na mensagem original
> ORACLE RAC 4 nós, fica subentendido que o Banco é Enterprise.
>
> Mas vai ai
>
> INST_ID BANNER
> -- --
> 1 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 1 PL/SQL Release 11.2.0.3.0 - Production
> 1 CORE 11.2.0.3.0 Production
> 1 TNS for Linux: Version 11.2.0.3.0 - Production
> 1 NLSRTL Version 11.2.0.3.0 - Production
> 4 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 4 PL/SQL Release 11.2.0.3.0 - Production
> 4 CORE 11.2.0.3.0 Production
> 4 TNS for Linux: Version 11.2.0.3.0 - Production
> 4 NLSRTL Version 11.2.0.3.0 - Production
> 3 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 3 PL/SQL Release 11.2.0.3.0 - Production
> 3 CORE 11.2.0.3.0 Production
> 3 TNS for Linux: Version 11.2.0.3.0 - Production
> 3 NLSRTL Version 11.2.0.3.0 - Production
> 2 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
> 2 PL/SQL Release 11.2.0.3.0 - Production
> 2 CORE 11.2.0.3.0 Production
> 2 TNS for Linux: Version 11.2.0.3.0 - Production
> 2 NLSRTL Version 11.2.0.3.0 - Production
>
>
>
> --- Em oracle_br@yahoogrupos.com.br  , 
> Ivan Ricardo Schuster escreveu
>>
>> Ederson,
>>
>> AFAIK, o Block Change Tracking serve somente para, ao realizar o
>> *BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
>> percorrer todos os blocos dos datafiles em busca de alteração, um mapa
>> do tesouro, digamos assim.
>>
>> Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
>> ver é independente de ter ou não habilitada esta funcionalidade, ou
>> seja, este arquivo não é necessário para a recuperação do banco.
>> Portanto, teoricamente, a perda deste arquivo causará a necessidade de
>> leitura de todos os blocos do banco de dados no próximo backup
>> incremental, ou a necessidade de um backup full para reorganizar a
>> casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
>> Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
>> documentação para chegar a esta conclusão..
>>
>> Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
>> for, esqueça BCT e paralelismo de backup.
>>
>>
>> 2013/2/18 ederson2001br :
>> > Bom dia Neto,
>> >
>> > Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No 
>> > caso de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas 
>> > vem somente na versão Enterprise (Advanced Compressed).
>> >
>> > Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
>> > BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
>> > controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, 
>> > o seu backup incremental vai gravar somente o que foi modificado (vai 
>> > ficar uma cópia bem pequena). Como vc colocou redundância 7, haverá uma 
>> > boa redundância dos arquivos, mas o BCT vai controlar a cópia e você 
>> > poderá colocar incremental diário, sem precisar retirar a cópia do 
>> > archivelog (que será mais uma redundância).
>> >
>> > Note que o arquivo BCT será um ponto de falha, ele também precisará estar 
>> > em local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
>> > perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
>> > incomplete, veja bem esta informação.
>> >
>> > É uma mudança grande, representa um paradigma, vc deve testar bem em 
>> > homologação e estar tranquilo com o novo ambiente, antes de implementar em 
>> > produção.
>> >
>> > Para habilitar:
>> > SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
>> >
>> > Para desabilitar:
>> > SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
>> >
>> > Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro 
>> > servidor, não vi vc relatando como está esta configuração. Sem

[oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico netodba
Bom dia Ivan,

como eu coloquei na mensagem original
ORACLE RAC 4 nós, fica subentendido que o Banco é Enterprise.

Mas vai ai

   INST_ID BANNER
-- 

 1 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 1 PL/SQL Release 11.2.0.3.0 - Production
 1 CORE 11.2.0.3.0  Production
 1 TNS for Linux: Version 11.2.0.3.0 - Production
 1 NLSRTL Version 11.2.0.3.0 - Production
 4 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 4 PL/SQL Release 11.2.0.3.0 - Production
 4 CORE 11.2.0.3.0  Production
 4 TNS for Linux: Version 11.2.0.3.0 - Production
 4 NLSRTL Version 11.2.0.3.0 - Production
 3 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 3 PL/SQL Release 11.2.0.3.0 - Production
 3 CORE 11.2.0.3.0  Production
 3 TNS for Linux: Version 11.2.0.3.0 - Production
 3 NLSRTL Version 11.2.0.3.0 - Production
 2 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit 
Production
 2 PL/SQL Release 11.2.0.3.0 - Production
 2 CORE 11.2.0.3.0  Production
 2 TNS for Linux: Version 11.2.0.3.0 - Production
 2 NLSRTL Version 11.2.0.3.0 - Production



--- Em oracle_br@yahoogrupos.com.br, Ivan Ricardo Schuster  
escreveu
>
> Ederson,
> 
> AFAIK, o Block Change Tracking serve somente para, ao realizar o
> *BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
> percorrer todos os blocos dos datafiles em busca de alteração, um mapa
> do tesouro, digamos assim.
> 
> Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
> ver é independente de ter ou não habilitada esta funcionalidade, ou
> seja, este arquivo não é necessário para a recuperação do banco.
> Portanto, teoricamente, a perda deste arquivo causará a necessidade de
> leitura de todos os blocos do banco de dados no próximo backup
> incremental, ou a necessidade de um backup full para reorganizar a
> casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
> Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
> documentação para chegar a esta conclusão..
> 
> Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
> for, esqueça BCT e paralelismo de backup.
> 
> 
> 2013/2/18 ederson2001br :
> > Bom dia Neto,
> >
> > Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> > de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> > somente na versão Enterprise (Advanced Compressed).
> >
> > Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> > BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> > controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, 
> > o seu backup incremental vai gravar somente o que foi modificado (vai ficar 
> > uma cópia bem pequena). Como vc colocou redundância 7, haverá uma boa 
> > redundância dos arquivos, mas o BCT vai controlar a cópia e você poderá 
> > colocar incremental diário, sem precisar retirar a cópia do archivelog (que 
> > será mais uma redundância).
> >
> > Note que o arquivo BCT será um ponto de falha, ele também precisará estar 
> > em local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> > perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> > incomplete, veja bem esta informação.
> >
> > É uma mudança grande, representa um paradigma, vc deve testar bem em 
> > homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> > produção.
> >
> > Para habilitar:
> > SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
> >
> > Para desabilitar:
> > SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
> >
> > Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro 
> > servidor, não vi vc relatando como está esta configuração. Sem criar o 
> > CATALOG, vc estará usando o TARGET / (dicionário na própria base). Em 
> > alguns casos de desastres, o retorno somente se dá com sucesso se o 
> > catálogo estiver em outro servidor. Veja isto também.
> >
> > Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> > próprio conceito e seu nível de garantias (leia-se paranóia).
> >
> >
> > Ederson Elias
> > DBA Oracle
> > http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
> >
> >
> > --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >>
> >> Vlw pessoal
> >>
> >> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> >> Vlw
> >>
> >>
> >> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >> >
> >> > Você pode mudar para assim.
> >> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> >> > FOR LOAD TRUE ;
> >> >
> >> > blz
> >> >
> >> >
> >> > Em 16 de fever

Re: [oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico Ivan Ricardo Schuster
Ederson,

AFAIK, o Block Change Tracking serve somente para, ao realizar o
*BACKUP* incremental, o RMAN ir direto ao ponto, ou seja, não precisar
percorrer todos os blocos dos datafiles em busca de alteração, um mapa
do tesouro, digamos assim.

Não entendo a relação deste arquivo BCT com o *RECOVER*, que ao meu
ver é independente de ter ou não habilitada esta funcionalidade, ou
seja, este arquivo não é necessário para a recuperação do banco.
Portanto, teoricamente, a perda deste arquivo causará a necessidade de
leitura de todos os blocos do banco de dados no próximo backup
incremental, ou a necessidade de um backup full para reorganizar a
casa. Nada muito preocupante para um banco de 2,5T ao meu ver.
Por favor, corrijam-me se eu estiver errado, não me baseei em nenhuma
documentação para chegar a esta conclusão..

Outra coisa, não li em lugar algum que este banco é Enterprise. Se não
for, esqueça BCT e paralelismo de backup.


2013/2/18 ederson2001br :
> Bom dia Neto,
>
> Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> somente na versão Enterprise (Advanced Compressed).
>
> Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, o 
> seu backup incremental vai gravar somente o que foi modificado (vai ficar uma 
> cópia bem pequena). Como vc colocou redundância 7, haverá uma boa redundância 
> dos arquivos, mas o BCT vai controlar a cópia e você poderá colocar 
> incremental diário, sem precisar retirar a cópia do archivelog (que será mais 
> uma redundância).
>
> Note que o arquivo BCT será um ponto de falha, ele também precisará estar em 
> local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> incomplete, veja bem esta informação.
>
> É uma mudança grande, representa um paradigma, vc deve testar bem em 
> homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> produção.
>
> Para habilitar:
> SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
>
> Para desabilitar:
> SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
>
> Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro servidor, 
> não vi vc relatando como está esta configuração. Sem criar o CATALOG, vc 
> estará usando o TARGET / (dicionário na própria base). Em alguns casos de 
> desastres, o retorno somente se dá com sucesso se o catálogo estiver em outro 
> servidor. Veja isto também.
>
> Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> próprio conceito e seu nível de garantias (leia-se paranóia).
>
>
> Ederson Elias
> DBA Oracle
> http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
>
>
> --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>>
>> Vlw pessoal
>>
>> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
>> Vlw
>>
>>
>> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
>> >
>> > Você pode mudar para assim.
>> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
>> > FOR LOAD TRUE ;
>> >
>> > blz
>> >
>> >
>> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
>> >
>> > > Experimentou usar compressed?
>> > > Em 16/02/2013 14:09, "netodba"  escreveu:
>> > >
>> > > > **
>> > > >
>> > > >
>> > > > Fala Pessoal,
>> > > >
>> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que 
>> > > > o
>> > > > backup rman ta demorando de mais.
>> > > >
>> > > > Ambiente:
>> > > > S.O: RH 6.3
>> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
>> > > > Tamanho da base: 2.5 Tb
>> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
>> > > > O backup é executado apenas na instancia 1.
>> > > >
>> > > > política de backup:
>> > > > Domingo 1:00 da manhã roda um full.
>> > > > Segunda a sabado as 1:00 roda o incremental.
>> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
>> > > >
>> > > > compigurações do rman:
>> > > >
>> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
>> > > > CONFIGURE BACKUP OPTIMIZATION ON;
>> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
>> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
>> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
>> > > > default
>> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
>> > > > BACKUPSET;
>> > > > 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 COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
>>

[oracle_br] Proteger usuarios com super privilegios.

2013-02-18 Por tôpico Alessandro Lúcio Cordeiro da Silva


    Bom dia Senhores,

    Existe uma situação que gostaria de ver o que vocês acham melhor. Na 
empresa existe vários usuarios que são do suporte/Help-desk de sistema, e estes 
usuarios tem o privilegio de alterar as senhas dos usuarios. Mas como proteger 
os usuarios com super privilegios no banco de dados?

    Veja o caso abaixo.


 C:\>sqlplus /nolog

SQL*Plus: Release 11.2.0.2.0 Production on Seg Fev 18 08:56:44 2013

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

SQL> connect system@xe
Conectado.
SQL> create user analista_suporte identified by senha;

Usuário criado.

SQL> grant connect, resource to analista_suporte;

Concessão bem-sucedida.

SQL> grant alter user to analista_suporte;

Concessão bem-sucedida.

SQL> exit
Desconectado de Oracle Database 11g Express Edition Release 11.2.0.2.0 - 
Production

C:\>sqlplus /nolog

SQL*Plus: Release 11.2.0.2.0 Production on Seg Fev 18 08:58:25 2013

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

SQL> connect analista_suporte@xe
Informe a senha:
Conectado.
SQL> alter user system identified by senha;

Usuário alterado.

SQL> alter user sys identified by senha;

Usuário alterado.


   A unica maneira que pensei foi criar uma Trigger DDL provocanco erro se um 
determinado usuario tentar mudar a senha de super usuario e/ou DBA's. Alguem  
tem alguma outra solução, de preferencia nativa do Oracle já no controle de 
acesso de GRANT/REVOKE.



Alessandro Lúcio Cordeiro da Silva 
    Analista de Sistema
þ http://alecordeirosilva.blogspot.com/
O tic-tac do relógio me lembra de algo muito importante que esta acontecendo: 
estamos vivos.
    "Joana de Souza Schmitz Croxato"

[As partes desta mensagem que não continham texto foram removidas]



[oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico netodba
Bom dia pessoal,

descobri qual era o problema do RMAN.
Como o meu cliente é uma instituição do Governo Legislativo, na base de dados 
há extrema utilização de LOB's, só pra vcs terem uma ideia existe uma tabela 
com LOB de 1.2T. 
O problema era causado na hora de fazer a compressão desses LOBS, li em artigos 
e blogs, que o RMAN tem uma baixa performance com compressão de LOB's, com isso 
mudei a compressão de HIGH pra BASIC, e de fato achei o problema. Depois da 
mudança consegui uma taxa de 10G por minuto e isso é bom, consegui deixar o 
backup do RMAN ajustado pro horario de backup.

Ederson, obrigado pela resposta.
Utilizo sim um catalog do rman em outro banco, apenas nao coloquei no tópico. 
Vou disponiblizar a solução do BLOCK CHANGE TRACKING com o chefe do setor, 
obrigado pela dica.

Então pessoal fica a dica, compressão HIGH do rman envolvendo LOB's não é boa.

abraço


--- Em oracle_br@yahoogrupos.com.br, "ederson2001br"  
escreveu
>
> Bom dia Neto,
> 
> Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso 
> de algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem 
> somente na versão Enterprise (Advanced Compressed).
> 
> Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
> BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo 
> controlará os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, o 
> seu backup incremental vai gravar somente o que foi modificado (vai ficar uma 
> cópia bem pequena). Como vc colocou redundância 7, haverá uma boa redundância 
> dos arquivos, mas o BCT vai controlar a cópia e você poderá colocar 
> incremental diário, sem precisar retirar a cópia do archivelog (que será mais 
> uma redundância).
> 
> Note que o arquivo BCT será um ponto de falha, ele também precisará estar em 
> local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se 
> perder o arquivo BCT, o backup que volta é somente o FULL, ou restore 
> incomplete, veja bem esta informação.
> 
> É uma mudança grande, representa um paradigma, vc deve testar bem em 
> homologação e estar tranquilo com o novo ambiente, antes de implementar em 
> produção.
> 
> Para habilitar:
> SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';
> 
> Para desabilitar:
> SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;
> 
> Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro servidor, 
> não vi vc relatando como está esta configuração. Sem criar o CATALOG, vc 
> estará usando o TARGET / (dicionário na própria base). Em alguns casos de 
> desastres, o retorno somente se dá com sucesso se o catálogo estiver em outro 
> servidor. Veja isto também.
> 
> Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
> próprio conceito e seu nível de garantias (leia-se paranóia).
> 
> 
> Ederson Elias
> DBA Oracle
> http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
> >
> > Vlw pessoal
> > 
> > ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> > Vlw
> > 
> > 
> > --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> > >
> > > Você pode mudar para assim.
> > > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > > FOR LOAD TRUE ;
> > > 
> > > blz
> > > 
> > > 
> > > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > > 
> > > > Experimentou usar compressed?
> > > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > > >
> > > > > **
> > > > >
> > > > >
> > > > > Fala Pessoal,
> > > > >
> > > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é 
> > > > > que o
> > > > > backup rman ta demorando de mais.
> > > > >
> > > > > Ambiente:
> > > > > S.O: RH 6.3
> > > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > > Tamanho da base: 2.5 Tb
> > > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > > O backup é executado apenas na instancia 1.
> > > > >
> > > > > política de backup:
> > > > > Domingo 1:00 da manhã roda um full.
> > > > > Segunda a sabado as 1:00 roda o incremental.
> > > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > > >
> > > > > compigurações do rman:
> > > > >
> > > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; 
> > > > > #
> > > > > default
> > > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > > BACKUPSET;
> > > > > 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'

[oracle_br] Re: Performance RMAN

2013-02-18 Por tôpico ederson2001br
Bom dia Neto,

Mudar o algoritmo de compressão ajuda pois será uma tarefa a menos. No caso de 
algoritmos, MEDIUM, ZLIB e BZIP2 são as outras opções, mas algumas vem somente 
na versão Enterprise (Advanced Compressed).

Bem, já que vc está na versão Enterprise, verifique a opção de habilitar o 
BLOCK CHANGE TRACKING. Será gravado um arquivo bct.cf e este arquivo controlará 
os blocos que sofreram modificação. Com BACKUP OPTIMIZATION ON, o seu backup 
incremental vai gravar somente o que foi modificado (vai ficar uma cópia bem 
pequena). Como vc colocou redundância 7, haverá uma boa redundância dos 
arquivos, mas o BCT vai controlar a cópia e você poderá colocar incremental 
diário, sem precisar retirar a cópia do archivelog (que será mais uma 
redundância).

Note que o arquivo BCT será um ponto de falha, ele também precisará estar em 
local seguro, com backup pelo S.O. (então melhor ficar fora do ASM). Se perder 
o arquivo BCT, o backup que volta é somente o FULL, ou restore incomplete, veja 
bem esta informação.

É uma mudança grande, representa um paradigma, vc deve testar bem em 
homologação e estar tranquilo com o novo ambiente, antes de implementar em 
produção.

Para habilitar:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct.cf';

Para desabilitar:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRANCKING;

Convém colocar o CATALOG (dicionário do RMAN) do seu banco em outro servidor, 
não vi vc relatando como está esta configuração. Sem criar o CATALOG, vc estará 
usando o TARGET / (dicionário na própria base). Em alguns casos de desastres, o 
retorno somente se dá com sucesso se o catálogo estiver em outro servidor. Veja 
isto também.

Creio que este tópico vai render uma boa discussão, pois cada um tem seu 
próprio conceito e seu nível de garantias (leia-se paranóia).


Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0


--- Em oracle_br@yahoogrupos.com.br, "netodba"  escreveu
>
> Vlw pessoal
> 
> ja mudei a compressão pra BASIC, aparentemente esta mas rapido mesmo.
> Vlw
> 
> 
> --- Em oracle_br@yahoogrupos.com.br, Wadson Ramon  escreveu
> >
> > Você pode mudar para assim.
> > CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE
> > FOR LOAD TRUE ;
> > 
> > blz
> > 
> > 
> > Em 16 de fevereiro de 2013 15:48, Vitor Junior escreveu:
> > 
> > > Experimentou usar compressed?
> > > Em 16/02/2013 14:09, "netodba"  escreveu:
> > >
> > > > **
> > > >
> > > >
> > > > Fala Pessoal,
> > > >
> > > > migrei uma base de dados 2.5 TB 10G pro 11.2.0.3, o meu problema é que o
> > > > backup rman ta demorando de mais.
> > > >
> > > > Ambiente:
> > > > S.O: RH 6.3
> > > > RAC 4 nós Oracle 11.2.0.3 em ASM
> > > > Tamanho da base: 2.5 Tb
> > > > Local onde é armazenado o backup é em acfs compartilhado com os 4 nós.
> > > > O backup é executado apenas na instancia 1.
> > > >
> > > > política de backup:
> > > > Domingo 1:00 da manhã roda um full.
> > > > Segunda a sabado as 1:00 roda o incremental.
> > > > Todo dia de 8:00 as 18:00 roda o de archivelog.
> > > >
> > > > compigurações do rman:
> > > >
> > > > CONFIGURE RETENTION POLICY TO REDUNDANCY 7;
> > > > CONFIGURE BACKUP OPTIMIZATION ON;
> > > > CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
> > > > CONFIGURE CONTROLFILE AUTOBACKUP ON;
> > > > CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
> > > > default
> > > > CONFIGURE DEVICE TYPE DISK PARALLELISM 4 BACKUP TYPE TO COMPRESSED
> > > > BACKUPSET;
> > > > 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 COMPRESSION ALGORITHM 'HIGH' OPTIMIZE FOR LOAD TRUE AS OF
> > > > RELEASE 'DEFAULT';
> > > > CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
> > > > CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DG02_R6/snapcf_PRODDB.f';
> > > >
> > > > script de backup full:
> > > >
> > > > run {
> > > > ALLOCATE CHANNEL ch00 TYPE disk ;
> > > > ALLOCATE CHANNEL ch01 TYPE disk ;
> > > > ALLOCATE CHANNEL ch02 TYPE disk ;
> > > > ALLOCATE CHANNEL ch03 TYPE disk ;
> > > > backup incremental level 0 tag = bkpL0_proddb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/bkp_%d_%T_%s_%p_%U'
> > > > database;
> > > > sql 'alter system archive log current';
> > > > RELEASE CHANNEL ch00;
> > > > RELEASE CHANNEL ch01;
> > > > RELEASE CHANNEL ch02;
> > > > RELEASE CHANNEL ch03;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > backup tag = contf_prodb
> > > > format
> > > >
> > > '/u01/app/acfsmounts/fradg_orabkplv/bkp/proddb/rman/backup/contf_%d_%T_%s_%p_%U'
> > > > current controlfile;
> > > > RELEASE CHANNEL ch00;
> > > >
> > > > ALLOCATE CHANNEL ch00 TYPE disk;
> > > > ALLOCATE CHANNEL ch01 TYPE disk;
> > > > backup tag = arc