Re: [oracle_br] DBCA não lista o listener do grid home

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá Sofia, tudo bem?

O listener roda na camada do Grid Infrastructure e, portanto, no usuário
grid.

Dê uma olhada nas permissões do diretório de instalação do Grid. O usuário
Oracle deve ser capaz de acessar os arquivos na pasta $GRID_HOME/bin

Logada como oracle, veja se você consegue acessar o arquivo
$GRID_HOME/bin/oracle

Assim:

ls -l $GRID_HOME/bin/oracle

Se for possível, passa pra gente o resultado desses comandos:

id grid
id oracle
ls -ld $ORACLE_HOME/bin
ls -ld $GRID_HOME/bin

Lembrando que $ORACLE_HOME é o diretório de instalação do Oracle RDBMS e
$GRID_HOME é o diretório de instalação do GI

Em seg, 20 de ago de 2018 19:29, Sofia Mackenzie sofiama...@gmail.com
[oracle_br]  escreveu:

>
>
> Olá Pessoal!
>
> Preciso de uma ajuda, por favor. Estou fazendo a instalação do Oracle
> 12.2.0.1 com ASM - Standalone Server.
>
> O owner do ASM e da instalação do Grid Infrastructure é o user GRID e a
> instalação do Database é o user ORACLE.
>
> Tudo correu bem até chegar a parte do DBCA. Quando chego na parte de
> configuração do network, deveria aparecer uma linha trazendo o listener do
> grid home, porém não aparece nada.
>
> Se tento criar com netca, ocorre uma mensagem de erro de que o listener
> default já está criado e usando a porta 1521.
>
> Alguém saberia informar se poderia ser um problema de permissão em arquivo
> ou pasta?
>
>
> id oracle
> uid=54321(oracle) gid=54321(oinstall)
> groups=54321(oinstall),54322(dba),54323(oper),54327(asmdba),54324(backupdba),54325(dgdba),54326(kmdba),54330(racdba)
>
> id grid
> uid=54323(grid) gid=54321(oinstall)
> groups=54321(oinstall),54322(dba),54327(asmdba),54329(asmadmin),54328(asmoper),54330(racdba)
>
> Poderiam me ajudar, por favor?
>
> Obrigada,
> Sofia
> 
>

Re: [oracle_br] Re: Descobrir um DBID

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Se seu banco de origem era 11.2.0.3 e vc instalou o software versão
11.2.0.4 no destino, então vc vai ter que fazer o upgrade logo depois que
fizer o restore do banco.

Assim que o restore e recover tiverem concluído, vc deve abrir o banco com
resetlogs para recriar os redologs e em modo de upgrade, e rodar o catupgrd
para concluir o upgrade de 11.2.0.3 para 11.2.0.4.

Algom assim:

SQL> alter database open resetlogs upgrade;

SQL> @?/rdbms/admin/catupgrd.sql


Esse blog aqui explica bem:

http://parthidba.blogspot.com/2014/10/migrating-oracle-database-from-11203-to.html



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/





Em qua, 15 de ago de 2018 às 15:21, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Sim, backup COLD implica em parar o banco enquanto ele está sendo feito -
> realmente com ele vc tem 100% de certeza que NÂO há transações / alterações
> / manipulações de dados comitadas mas ainda não baixadas pro disco,sim, mas
> é Difícil que haja janela pra isso, sim...
>  Em não podendo ser COLD (exceções feitas à soluções de snapshot de discos
> que se integrem com o RDBMS e "forcem" um checkpoint completo E suspendam
> I/O no banco enquanto rola o snapshot) aí então SIM, estamos no domínio do
> HOT BACKUP
>  Pra vc explicar/conceituar HOT BACKUP pra um leigo, é bem simples : diga
> que ele é composto por uma cópia dos  dados 'intocados' que estavam em
> disco MAIS uma cópia da trilha de alterações, ie, de TODOS os dados que
> vieram do disco e foram alterados até um determinado ponto no tempo, okdoc
> ? Simples... NÂO EXISTE isso de "99% do que está ali é backupeado", até
> porque backup e gravidez, ou vc tem ou não tem - não existe backup parcial
> , não existe meia gravidez, ou vc tem completo ou não tem.  Assim
> sendo, falando do seu caso, se é backup HOT vc só tem um backup válido SE E
> APENAS SE vc tem uma cópia de TODOS os archived redo logs gerados desde a
> última alteração dos datafiles até a hora do backup : se vc não tem 100% de
> certeza que tem TODOS esses archives backupeados, vc simplesmente NÂO TEM
> CERTEZA de ter um backup íntegro, sim sim sim ??? UM archive que seja
> faltante pronto, já significa que do ponto do tempo onde esse archive
> faltante foi gerado pra frente vc simplesmente NÃO conseguirá recuperar os
> dados desse ponto pra frente - digamos que quando foi feito o backup mais
> recente dos datafiles o SCN marcado num deles era de 72 horas atrás
> (plenamente possível - como nós sabemos quando vc faz COMMIT os dados NÃO
> SÃO gravados imediatamente nos datafiles, por questões de performance), e
> por qquer falha na sua política vc PERDEU o archive que registrava
> alterações de 71 horas atrás : pronto, essa simples falha de UM archive
> crítico faltante te impedirá de recuperar esse datafile em questão... E se
> esse datafile for o que contém a crítica tablespace SYSTEM ?? Ferrou
>
>  É por isso que eu insisto : backup HOT só é tão confiável o quanto for
> confiável tua política de backups de Archives.
>
>  []s
>
>Chiappa
> 
>

Re: [oracle_br] Re: Descobrir um DBID

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Eu imagino que seus backups estejam em uma Tape, certo? Caso o seu backup
esteja no local, basta vc catalogar os backuppieces no seu script de
restore do rman.

Se você sabe as infos do Gerenciador de Tape, e os nomes dos handlers
(backup piece) nas fitas, vc pode catalogar eles também, sem a necessidade
de saber o DBid.

Esse link do blog do Marko Sutic mostra como fazer.

http://msutic.blogspot.com/2014/03/rman-catalog-backuppiece-located-on-tape..html

I've recorded backups on tape to RMAN repository several times already, but
every next time I needed to do that I was searching through notes to find
proper procedure.

This time I will note procedure in form of the blog post.

Note!
Test is performed on Oracle version 11.1.0.7.


These were my unsuccessful attempts:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
RMAN> run
2> {
3> allocate channel c1 device type 'sbt_tape';
4> send
'NSR_ENV=(NSR_SERVER=backup_server,NSR_CLIENT=oracle_client,NSR_DATA_VOLUME=OrclPool)'
;
5> catalog  backuppiece 'ARCH_ORCL_rep2dod5_s128878_p1';
6> }

allocated channel: c1
channel c1: SID=321 device type=SBT_TAPE
channel c1: NMDA Oracle v1.1.0

sent command to channel: c1

ORA-19870: error while restoring backup piece
/u01/app/orcl11/product/11.1.0/db_1/dbs/ARCH_ORCL_rep2dod5_s128878_p1
ORA-19505: failed to identify file
"/u01/app/orcl11/product/11.1.0/db_1/dbs/ARCH_ORCL_rep2dod5_s128878_p1"
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

released channel: c1
RMAN-00571: ===
RMAN-00569: === ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===
RMAN-03002: failure of catalog command at 03/05/2014 15:42:23
RMAN-06209: List of failed objects
RMAN-06211: ==
RMAN-06212:   Object Type   Filename/Handle
RMAN-06213: ---
---
RMAN-06214: Backup Piece
/u01/app/orcl11/product/11.1.0/db_1/dbs/ARCH_ORCL_rep2dod5_s128878_p1

and

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
RMAN> run
2> {
3> allocate channel c1 device type 'sbt_tape';
4> send
'NSR_ENV=(NSR_SERVER=backup_server,NSR_CLIENT=oracle_client,NSR_DATA_VOLUME=OrclPool)'
;
5> catalog device type 'sbt_tape' backuppiece
'ARCH_ORCL_rep2dod5_s128878_p1';
6> }

allocated channel: c1
channel c1: SID=321 device type=SBT_TAPE
channel c1: NMDA Oracle v1.1.0

sent command to channel: c1

released channel: c1
RMAN-00571: ===
RMAN-00569: === ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===
RMAN-03002: failure of catalog command at 03/05/2014 15:36:57
RMAN-06470: DEVICE TYPE is supported only when automatic channels are used



How to *catalog backuppiece on tape*...


Add SBT_TAPE configuration:
1
2
RMAN> configure default device type to 'SBT_TAPE';
RMAN> configure channel device type 'SBT_TAPE' send '[MML PARAMETERS]';

Catalog backuppiece:
1
RMAN> catalog device type 'SBT_TAPE' backuppiece '[BACKUP NAME]';

To clear configuration:
1
RMAN> configure channel device type ‘SBT_TAPE’ clear;


My example:

Set *configuration*:
1
2
3
4
5
6
RMAN> configure default device type to 'SBT_TAPE';
RMAN> configure channel device type 'SBT_TAPE'
2> send
'NSR_ENV=(NSR_SERVER=backup_server,NSR_CLIENT=oracle_client,NSR_DATA_VOLUME=OrclPool)'
;
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' SEND
'NSR_ENV=(NSR_SERVER=backup_server,NSR_CLIENT=oracle_client,NSR_DATA_VOLUME=OrclPool)'
;
new RMAN configuration parameters are successfully stored

*Catalog* backuppiece:
1
2
3
4
5
6
7
RMAN> catalog device type 'SBT_TAPE' backuppiece
'ARCH_ORCL_rep2dod5_s128878_p1';

allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=321 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: NMDA Oracle v1.1.0
cataloged backup piece
backup piece handle=ARCH_ORCL_rep2dod5_s128878_p1 RECID=127894
STAMP=841419878

*Clear* configuration:
1
2
3
4
5
RMAN> CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' CLEAR;

old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' SEND
'NSR_ENV=(NSR_SERVER=backup_server,NSR_CLIENT=oracle_client,NSR_DATA_VOLUME=OrclPool)'
;
old RMAN configuration parameters are successfully deleted




Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/





Em ter, 14 de ago de 2018 às 14:00, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> A partir do backup de dados propriamente dito afaik não, mas cfrme
> http://shahiddba.blogspot.com/2012/11/how-to-find-oracle-dbid.html
> indica, vc pode obter a partir dos LOGs (seja dos logs do RMAN, seja o log
> de tela que teu terminal tenha gerado - já me salvou N vezes o log do puTTY
> pra casos do tipo)

Re: [oracle_br] Emnail com Oracle 11xe

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Vc pode utilizar o UTL_MAIL.

O Eduardo Legatti explica muito bem em seu blog.

https://eduardolegatti.blogspot.com/2010/04/um-pouco-dos-pacotes-utlsmtp-e-utlmail.html

Este outro artigo explica como fazer isso usando o gmail:

https://hostelfour.wordpress.com/2012/03/29/sending-email-from-oracle-xe-using-gmail/


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/





Em ter, 14 de ago de 2018 às 09:32, afonso_jalmore...@yahoo.com [oracle_br]
 escreveu:

>
>
> Bom dia, estou usando orcle 11xe e gostaria de atiovar o envio de email
> automatico dependendo de cwerta situacao, como ativo essa funcao??
>
>
> abs
>
> afonso
>
> Sao Paulo-SP
>
>
>
> 
>

Re: [oracle_br] Descobrir um DBID

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Retificando... para se contectar no catalog sem que o banco atual esteja
montado:

Simplesmente entre no rman, sem informar "target /"

$> rman

RMAN> connect catalog user/password@sid

RMAN> list incarnations;

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/





Em seg, 13 de ago de 2018 às 19:07, Evandro Giachetto <
evandrogiache...@gmail.com> escreveu:

> Vc usava catalog.
>
> Se sim, basta conectar no catalog pelo RMAN e dar um list incarnations;
>
> Rman target /
>
> connect catalog user/password@sid
>
> list incarnations;
>
>
> 2. Se vc deixava o controlfile autobackup ligado e guardou algum log de
> seus backups, então no log deve conter o dbid.
>
> 3. Se vc tiver algum arquivo do banco disponível (datafile, logfile ou até
> mesmo um archivelog), vc pode extrair o DBID para um arquivo trace. O banco
> não precisa estar montado pra isso.
>
> rman target /
>
> alter system dump datafile 'C:\caminho\do\arquivo.dbf' block min 1 block
> max 10;
>
> Procura no trace que foi criado, algo assim: "Db ID=12345678"
>
>
> 4. Se vc não precisa que seu banco contenha o mesmo dbid, é só vc
> catalogar os backuppieces e restaurar o backup que o banco vai ser
> restaurado do mesmo jeito, mas com um dbid diferente.
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
> http://www.dbaoracle.eti.br/
>
> 
>
>
>
> Em seg, 13 de ago de 2018 às 18:17, angelo angelolis...@gmail.com
> [oracle_br]  escreveu:
>
>>
>>
>> Senhores,
>>
>> Consigo descobrir um DBID de um banco a partir de um backup full do Rman
>> ?  Esqueci de anotar.. mas tenho o backup a mão.
>>
>> Pois se eu nao conseguir pelo backup, só vou ter acesso ao servidor
>> fisico daqui a uns 10 dias..
>> que ele vai ser devolvido, um sistema antigo que saiu de operação mas
>> preciso consultar uma coisa
>>
>> os caras se adiantaram e cortaram conexão, era pra ter sido no fim do
>> mês..  sem chance de religar
>>
>> meu Oracle é 11g  11.2.0.4  x64  windows.
>>
>>
>> []s angelo
>>
>>
>>
>> 
>>
>

Re: [oracle_br] Descobrir um DBID

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Vc usava catalog.

Se sim, basta conectar no catalog pelo RMAN e dar um list incarnations;

Rman target /

connect catalog user/password@sid

list incarnations;


2. Se vc deixava o controlfile autobackup ligado e guardou algum log de
seus backups, então no log deve conter o dbid.

3. Se vc tiver algum arquivo do banco disponível (datafile, logfile ou até
mesmo um archivelog), vc pode extrair o DBID para um arquivo trace. O banco
não precisa estar montado pra isso.

rman target /

alter system dump datafile 'C:\caminho\do\arquivo.dbf' block min 1 block
max 10;

Procura no trace que foi criado, algo assim: "Db ID=12345678"


4. Se vc não precisa que seu banco contenha o mesmo dbid, é só vc catalogar
os backuppieces e restaurar o backup que o banco vai ser restaurado do
mesmo jeito, mas com um dbid diferente.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/





Em seg, 13 de ago de 2018 às 18:17, angelo angelolis...@gmail.com
[oracle_br]  escreveu:

>
>
> Senhores,
>
> Consigo descobrir um DBID de um banco a partir de um backup full do Rman
> ?  Esqueci de anotar.. mas tenho o backup a mão.
>
> Pois se eu nao conseguir pelo backup, só vou ter acesso ao servidor fisico
> daqui a uns 10 dias..
> que ele vai ser devolvido, um sistema antigo que saiu de operação mas
> preciso consultar uma coisa
>
> os caras se adiantaram e cortaram conexão, era pra ter sido no fim do
> mês..  sem chance de religar
>
> meu Oracle é 11g  11.2.0.4  x64  windows.
>
>
> []s angelo
>
>
>
> 
>

Re: [oracle_br] Re: Multiples discos em diferentes RAID levels

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Muito obrigado Chiappa e Junior Cesar.

A prestatividade foi excepcional, como sempre.

Obrigado.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/




Em 20 de fevereiro de 2018 14:14, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Blz ? Então, OBRIGATORIEDADE não existe (nem em lugar ** nenhum ** da
> Documentação e nem em nota técnica NENHUMA do metalink vc vai achar uma
> OBRIGATORIEDADE pra isso), mas é FORTEMENTE RECOMENDADO que os discos
> físicos (e os disk volumes, óbvio) dentro de um diskgroup sejam IDÊNTICOS
> entre si, tanto na questão de tamanho quanto na questão de tecnologia : a
> nota metalink How to Prepare Storage for ASM (Doc ID 452924.1) diz isso com
> ** TODAS AS LETRAS ** :
>
> "
> C) Recommendations for Storage Preparation. The following are guidelines
> for preparing storage for
> use with ASM:
>
>
>
> 1) Configure two disk groups, one for the datafile and the other for the
> Flash Recovery Area. For availability purposes, one is used as a backup for
> the other.
>
> 2) Ensure that LUNs, which are disk drives of partitions, that ASM disk
> groups use have similar storage performance and availability
> characteristics. In storage configurations with mixed speed drives, such as
> 10K and 15K RPM, I/O distribution is constrained by the slowest speed drive.
>
> 3) Be aware that ASM data distribution policy is capacity-based. LUNs
> provided to ASM have the same capacity for each disk group to avoid an
> imbalance.
> "
>
> OK ? Viole essa Recomendação Oficial por sua conta e risco... Eu, se
> estivesse no seu lugar, PRIMEIRO mandaria tirar a turma tirar o escorpião
> do bolso e DISPENSAR esses RAID-5 se a máquina em questão é Produção E
> performance decente é paradigma (vide http://www.baarf.dk/BAARF/
> BAARF2.html e os outros n+1! materiais disponíveis) ...
>  APENAS SE REALMENTE  não tiver outra solução, tapando o nariz eu SEM
> DÚVIDA criaria um OUTRO diskgroup pra conter os tais discos RAID-5
>
> []s
>
>   Chiappa
> 
>

[oracle_br] Multiples discos em diferentes RAID levels

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Boa tarde pessoal.

Essa pergunta surgiu hoje em uma reunião com os Sys admins e eu não soube
responder.

Em um determinado host, os discos apresentados são todos RAID 10. Existem
alguns discos disponíveis, porém são RAID 5.

Seria possível adicionar esse disco RAID 5 em um mesmo diskgroup que já
contenha discos RAID 10?

Eu já li em algum lugar que é uma boa prática utilizar discos sempre de
mesma capacidade (velocidade) e mesmo level de RAID, porém não sei se isso
é uma obrigatoriedade.

Considerações:

Aqui usamos Oracle Linux 5 64bit.
Estamos utilizando asm library (oracleasm).
Discos criados com external redundancy.
Versão do Oracle/GI: 11.2.0.1



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/

Re: [oracle_br] Migração

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Você vai precisar copiar o encryption wallet para o banco standby.

Vc pode dar uma olhada nessa MOS aqui:

Step by step method to implement Transparent Data Encryption (TDE) in 11g
Data Guard and 11g RAC environments (Doc ID 1627807.1)



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/

<http://www.dbaoracle.eti.br/>


2017-11-13 11:13 GMT-02:00 Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br] :

>
>
> Evandro, obrigado pelo retorno.
>
> Eu estava pensando em fazer assim, mas me parece que existe um passo a
> mais aí quando se trata de um database com ADvanved security. Existem
> dezenas de arquivos de segurança no file system, e se não me engano, o
> ORACLE_HOME deve ser migrado em um ORACLE_HOME separado dos databases já
> existentes do novo servidor para evitar impacto. Li a respeito disso há um
> tempo atrás.
>
> Vamos ver se alaguém mais pode opinar em relação a isso.
>
>
> Em Segunda-feira, 13 de Novembro de 2017 11:08, "Evandro Giachetto
> evandrogiache...@gmail.com [oracle_br]" 
> escreveu:
>
>
>
> Eu gosto sempre de utilizar Dataguard para reduzir o downtime em migrações
> de servidores.
>
> Faço o setup do dataguard alguns dias antes da migração de fato. Confirmo
> que está fazendo o replicate corretamente e que está 100% sincronizado, sem
> gaps.
>
> No dia da migração, simplesmente paro o banco origem e torno o banco
> destino ativo. O tempo de downtime é mínimo, apenas alguns minutos
> (dependendo da quantidade de archives a serem aplicados).
>
> *Consulte as opções de licença para este modelo. Dataguard exige licença
> em algumas modalidades de uso.
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
> http://www.dbaoracle.eti.br/
>
> <http://www.dbaoracle.eti.br/>
>
>
> Em 13 de novembro de 2017 10:54, Rafael Mendonca raffaell.t...@yahoo.com
> [oracle_br]  escreveu:
>
>
> SEnhores, bom dia.
>
> Segue:
>
> Ambiente atual:
>
> Oracle 11.2.0.4 EE
> SO: Linux 6 64 bits
> Single instance
> Tamanho da base: 2TB
>
> Ambiente para migração:
>
> Servidor com as mesmas configurações, apenas com a diferença que se trata
> de um ambiente RAC com dois nós (já existe uma base em funcionamento nesse
> cluster). Será criado uma nova base para realizar a migração.
>
>
> O tempo de downtime é de aproximadamente 5 a 6 horas e que o ambiente
> possui todas as options de Security envolvidos. Existe database vault, TDE
> nesse ambiente. Existe uma série de arquivos que são criados a nível de
> sistema operacional/file system.
>
>
> Minha dúvida é: Qual seria o melhor procedimento para realizar esse tipo
> de migração.
>
>
>
>
> 
>

Re: [oracle_br] Migração

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Eu gosto sempre de utilizar Dataguard para reduzir o downtime em migrações
de servidores.

Faço o setup do dataguard alguns dias antes da migração de fato. Confirmo
que está fazendo o replicate corretamente e que está 100% sincronizado, sem
gaps.

No dia da migração, simplesmente paro o banco origem e torno o banco
destino ativo. O tempo de downtime é mínimo, apenas alguns minutos
(dependendo da quantidade de archives a serem aplicados).

*Consulte as opções de licença para este modelo. Dataguard exige licença em
algumas modalidades de uso.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/




Em 13 de novembro de 2017 10:54, Rafael Mendonca raffaell.t...@yahoo.com
[oracle_br]  escreveu:

>
>
> SEnhores, bom dia.
>
> Segue:
>
> Ambiente atual:
>
> Oracle 11.2.0.4 EE
> SO: Linux 6 64 bits
> Single instance
> Tamanho da base: 2TB
>
> Ambiente para migração:
>
> Servidor com as mesmas configurações, apenas com a diferença que se trata
> de um ambiente RAC com dois nós (já existe uma base em funcionamento nesse
> cluster). Será criado uma nova base para realizar a migração.
>
>
> O tempo de downtime é de aproximadamente 5 a 6 horas e que o ambiente
> possui todas as options de Security envolvidos. Existe database vault, TDE
> nesse ambiente. Existe uma série de arquivos que são criados a nível de
> sistema operacional/file system.
>
>
> Minha dúvida é: Qual seria o melhor procedimento para realizar esse tipo
> de migração.
>
> 
>

Re: [oracle_br] Dúvidas com consulta hierárquica C ONNECT BY LEVEL

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Maravilha. Fico feliz em ter ajudado.

Desculpe pelo erro no código. Realmente passou sem perceber. Mas o
importante é que você entendeu e pode realizar a correção no código.

Forte abraço. E não deixe de visitar meu blog: http://www.dbaoracle.eti.br/ Eu
procuro sempre atualizar com algumas coisas interessantes, e, em breve,
alguns artigos da OTN em que estou trabalhando.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/




Em 4 de novembro de 2017 22:04, fca_anali...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Boa noite Evandro,
>
> Você solucionou meu problema. Obrigado.
>
> Só tive que fazer um pequeno ajuste, nada de mais.
>
> Do jeito que estava, as datas estavam vindo repetidas na última coluna,
> pois somavam a data de inicio com a diferença de dias entre o inicio e fim.
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
> Loja2 Loja 2 05/02/17 08/02/17 08/02/17
> Loja2 Loja 2 05/02/17 08/02/17 08/02/17
> Loja2 Loja 2 05/02/17 08/02/17 08/02/17
> Loja2 Loja 2 05/02/17 08/02/17 08/02/17
>
> Então, alterei de:
>
> PIPE ROW(t_tf_row(rec.estabelecimento, rec.descricao, rec.inicio,
> rec.fim, rec.inicio+num_days));
>
> Para
>
> PIPE ROW(t_tf_row(rec.estabelecimento, rec.descricao, rec.inicio,
> rec.fim, rec.inicio+i));
>
> Ficou do jeito que queria...
>
> Loja1 Loja 1 01/02/17 05/02/17 01/02/17
> Loja1 Loja 1 01/02/17 05/02/17 02/02/17
> Loja1 Loja 1 01/02/17 05/02/17 03/02/17
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
> Loja2 Loja 2 05/02/17 08/02/17 05/02/17
> Loja2 Loja 2 05/02/17 08/02/17 06/02/17
> Loja2 Loja 2 05/02/17 08/02/17 07/02/17
> Loja2 Loja 2 05/02/17 08/02/17 08/02/17
>
> Vou dar uma estudada em PIPELINED e PIPE ROW, muito interessante.
>
> Obrigado.
>
> 
>

Re: [oracle_br] Dúvidas com consulta hierárquica CONNECT BY LEVEL

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Achei interessante a forma como você tentou resolver esse problema, porém,
não é para isso que consultas hierárquicas são utilizadas.

Da forma como você escreveu, está gerando um produto cartesiano do
resultado.

Além disso, está considerando que os contratos não irão se sobrepor. No seu
exemplo, há apenas 2 contratos: 1 que se inicia no dia 1° e finaliza no dia
5° e outro que inicia no dia 5° e finaliza no dia 8°, e a ligação foi feita
entre level e as datas, o que não faz sentido.

Entendi que seu raciocínio era o de gerar linhas em seu resultset baseado
nas datas de inicio e fim do contrato. Assim, um registro com datas entre
dia 1 e 5 se tornariam 5 linhas em seu resultset.

A lógica é interessante, mas não é este o propósito das consultas
hierárquicas.

Basicamente, é necessário que haja uma definição de como uma linha filho
irá se relacionar com a linha pai. No seu exemplo, você utilizou a data
para isso, o que não faz sentido, já que, teoricamente, poderia-se haver
contratos se intercalando (ex: dia 1 até dia 5 e dia 2 até dia 8). Dessa
forma o relacionamento está quebrado.

Acredito eu que você possa até conseguir o resultado esperando dessa forma,
como de fato conseguiu ao utilizar o distinct, porém, a melhor forma de se
fazer isso, ao meu ver, seria com PL/SQL.

Se você precisa desse resultado em um select, uma PIPELINED FUNCTION seria
a melhor pedida.

Um exemplo bem rápido escrito a mão aqui, sem nenhum teste:


create table contratos (
  estabelecimento varchar2(5),
  descricao   varchar2(30),
  inicio  date,
  fim date
);


CREATE TYPE t_tf_row AS OBJECT (
  estabelecimento varchar2(5),
  descricao   varchar2(30),
  inicio  date,
  fim date,
  dia_contratodate
);
/

CREATE TYPE t_tf_tab IS TABLE OF t_tf_row;
/


CREATE OR REPLACE FUNCTION get_tab_ptf RETURN t_tf_tab PIPELINED AS

num_days number;

BEGIN

  FOR rec IN (select estabelecimento, descricao, trunc(inicio) inicio,
trunc(fim) fim from contratos order by 1,3,4) LOOP

num_days := rec.fim - rec.inicio;

FOR i in 0 .. num_days LOOP

  PIPE ROW(t_tf_row(rec.estabelecimento, rec.descricao, rec.inicio,
rec.fim, rec.inicio+num_days));

END LOOP;

  END LOOP;

  RETURN;
END;
/


SELECT *
FROM TABLE(get_tab_ptf);


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/




Em 4 de novembro de 2017 08:29, fca_anali...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Bom dia pessoal,
>
>
> Estou com o seguinte desafio, já pesquisei bastante e ainda não cheguei a
> uma solução.
>
>
> O problema é o seguinte, tenho N contratos, cada contrato tem data de
> inicio e fim, isto eu chamo de período de vigência do contrato.
>
> Neste período de vigência cada contrato deve informar vendas para cada dia.
>
>
> Exemplo 1:
>
>
> Contrato: X
>
> Inicio: 10/10/2017
>
> Fim: 13/10/2017
>
>
> Neste exemplo o contrato X deveria informar vendas nos dias 10, 11, 12 e
> 13/10.
>
>
> Minha dificuldade está em gerar estes intervalos de datas para cada linha
> de contrato, estas datas devem estar entre o período de inicio e fim do
> contrato.
>
>
> Exemplo 2:
>
>
> -- script
>
>
> create table contratos (
>
> estabelecimento varchar2(5),
>
> descricao varchar2(30),
>
> inicio date,
>
> fim date
>
> );
>
>
> insert into contratos values ('Loja1', ' Loja 1', '01/02/2017',
> '05/02/2017');
>
> insert into contratos values ('Loja2', ' Loja 2', '05/02/2017',
> '08/02/2017');
>
>
> commit;
>
>
> Se eu executar a consulta abaixo, as linhas se repetem, gerando um volume
> de dados muito grande.
>
> * a coluna DT seria o intervalo de datas que quero consegui
>
>
> select estabelecimento, descricao, inicio, fim, inicio + level - 1 dt
>
> from contratos
>
> connect by level <= fim - inicio + 1
>
> order by estabelecimento, inicio, 5;
>
>
> Resultado: (Errado)
>
>
> Loja1 Loja 1 01/02/17 05/02/17 01/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 02/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 02/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 03/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 03/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 03/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 03/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 04/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02/17 05/02/17
>
> Loja1 Loja 1 01/02/17 05/02

Re: [oracle_br] Query colunas dinâmicas

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Infelizmente não há uma maneira de fazer isso automaticamente.

Quando queremos construir uma query pivot, devemos saber exatamente quais
valores serão convertidos em colunas.

Felizmente, o Tom e o Lucas Jellema escreveram formas diferente de se
fazerem isso que você quer.

Ambos de formas diferentes, mas que usam os metadados da query para
construir a query pivot dinamicamente.

Dá uma olhada e veja se ajuda.

https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:4471013000346257238

https://technology.amis.nl/2006/05/24/dynamic-sql-pivoting-stealing-antons-thunder/




Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://www.dbaoracle.eti.br/




Em 6 de abril de 2017 07:57, Junior roberjr_...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
>
>
>
>
>
>
>
> * Prod Setor Qtd-- -  X  A
>3 X  B   2 Y  A   1 Z
>   B   4*
>
> *Gostaria que ficasse assim*
>
>
>
>
>
>
> *Prod   Setor A Setor B
>  -  --- - X
>   3 2 Y  1 -
>  Z  - 4*
>
> *De uma forma dinâmica não fixa. *
>
> *Tentei usar o pivot xml, mas não é obtive o resultado esperado.*
>
> *Alguém poderia me ajudar?*
>
> *Estou utilizando Oracle 11.2.0.3.0 *
>
> *Obrigado.*
>
> 
>

Re: [oracle_br] Instalação em silent mode

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Valeu Vitor

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 16 de fevereiro de 2017 07:34, Vitor Junior vitorj...@gmail.com
[oracle_br]  escreveu:

>
>
> Belo post cara! Parabéns! :)
>
> Em qua, 15 de fev de 2017 às 13:17, Evandro Giachetto
> evandrogiache...@gmail.com [oracle_br] 
> escreveu:
>
>>
>>
>> Aos que se interessarem.
>>
>> Feebacks são muito bem vindos.
>>
>> http://bancotunado.blogspot.com.br/2017/02/instalando-
>> oracle-database-12c-em.html
>>
>> Evandro Giachetto
>> Oracle DBA
>> evandrogiache...@gmail.com
>> http://bancotunado.blogspot.com.br/
>>
>> --
> Att,/Regards,
>
> Vitor Jr.
> https://br.linkedin.com/in/vitorjunior81
>
> 
>

Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Fico feliz em saber que pude ajudar.

Um abraço.

Dá uma sapeada no meu blog de vez em quando :)

http://bancotunado.blogspot.com.br

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 15 de fevereiro de 2017 15:03, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Evandro,
>
> Ignora meu e-mail anterior, eu havia feito um move da tabela para outra
> tablespace.
>
> Executei novamente aquele script e peguei o novo rowid.
>
>
>
> SQL> delete compras.adm_compras_page where rowid='AAC6pYABbAABSSFAA5';
>
>
>
> 1 row deleted
>
>
>
> SQL> COMMIT;
>
>
>
> Commit complete
>
>
>
> E agora fez o export com sucesso.
>
>
>
> Gostaria de agradecer a você, Chiappa e Jonathan Barbosa pela ajuda.
>
>
>
> Forte Abraço,
>
> Ednilson
>
>
>
> *De:* sentto-1682896-121499-1487172832-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121499-
> 1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 13:34
>
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Veja bem.
>
>
>
> Temos 2 problemas aqui.
>
>
>
> 1. Seu Lob está corrompido.
>
> Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente).
>
>
> A saída do script informou algumas rowid em que foram encontrados blocos
> corrompidos.
>
>
>
> 2.
>
> MAX(MAXQUERYLEN)
>
> 
>
>33094
>
>
>
>  COLUMN_NAME   SECUREFILE PCTVERSION  RETENTION
>
> - -- -- --
>
> TEXTSHOT  NO 28800
>
>
>
> Quer dizer que a query mais demorada de seu banco precisa reter undo por
> 33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800.
>
>
>
> Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria
> ser, no mínimo, 33094.
>
>
>
> Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido.
>
>
>
> Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4).
> Se você puder excluir essa linha e recriá-la
>
>
>
> Em seguida, rode novamente aquele procedimento para identificar corrupção
> e veja se tem mais.
>
>
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
> http://bancotunado.blogspot.com.br/
>
>
>
> Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva'
> ednilson.si...@jbs.com.br [oracle_br] 
> escreveu:
>
>
>
> Evandro,
>
> Segue resultado do primeiro comando, desculpe não entendi muito bem o
> resultado.
>
>
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 0
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 1
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 2
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 3
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
>
>
> SQL> select max(maxquerylen) from v$undostat;
>
>
>
> MAX(MAXQUERYLEN)
>
> ----
>
>33094
>
>
>
> SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION
>
>   2from dba_lobs
>
>   3   where OWNER = 'COMPRAS'
>
>   4 and TABLE_NAME = 'ADM_COMPRAS_PAGE';
>
>
>
> COLUMN_NAME   SECUREFILE PCTVERSION  RETENTION
>
> - -- -- --
>
> TEXTSHOT  NO 28800
>
>
>
>
>
>
>
> Grato,
>
>
>
>
> *_Ednilson Silva*
>
> (11) 3144-4305
>
> JBS S/A
>
>
>
> *De:* s

Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Esse rowid existe?

Select * from COMPRAS.ADM_COMPRAS_PAGE where rowid=’AABaK4AAyAAM2zJAA4’;

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 15 de fevereiro de 2017 14:53, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Evandro,
>
> Como faço para excluir esse registro?
>
>
>
> Seria ?
>
> delete from COMPRAS.ADM_COMPRAS_PAGE where rowid=’AABaK4AAyAAM2zJAA4’;
>
> ORA-01410: ROWID inválido
>
>
>
> Grato,
>
> Ednilson
>
>
>
> *De:* sentto-1682896-121499-1487172832-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121499-
> 1487172832-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 13:34
>
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Veja bem.
>
>
>
> Temos 2 problemas aqui.
>
>
>
> 1. Seu Lob está corrompido.
>
> Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente).
>
>
> A saída do script informou algumas rowid em que foram encontrados blocos
> corrompidos.
>
>
>
> 2.
>
> MAX(MAXQUERYLEN)
>
> 
>
>33094
>
>
>
>  COLUMN_NAME   SECUREFILE PCTVERSION  RETENTION
>
> - -- -- --
>
> TEXTSHOT  NO 28800
>
>
>
> Quer dizer que a query mais demorada de seu banco precisa reter undo por
> 33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800.
>
>
>
> Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria
> ser, no mínimo, 33094.
>
>
>
> Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido.
>
>
>
> Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4).
> Se você puder excluir essa linha e recriá-la
>
>
>
> Em seguida, rode novamente aquele procedimento para identificar corrupção
> e veja se tem mais.
>
>
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
> http://bancotunado.blogspot.com.br/
>
>
>
> Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva'
> ednilson.si...@jbs.com.br [oracle_br] 
> escreveu:
>
>
>
> Evandro,
>
> Segue resultado do primeiro comando, desculpe não entendi muito bem o
> resultado.
>
>
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 0
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 1
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 2
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 3
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
>
>
> SQL> select max(maxquerylen) from v$undostat;
>
>
>
> MAX(MAXQUERYLEN)
>
> 
>
>        33094
>
>
>
> SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION
>
>   2from dba_lobs
>
>   3   where OWNER = 'COMPRAS'
>
>   4 and TABLE_NAME = 'ADM_COMPRAS_PAGE';
>
>
>
> COLUMN_NAME   SECUREFILE PCTVERSION  RETENTION
>
> - -- -- --
>
> TEXTSHOT  NO 28800
>
>
>
>
>
>
>
> Grato,
>
>
>
>
> *_Ednilson Silva*
>
> (11) 3144-4305
>
> JBS S/A
>
>
>
> *De:* sentto-1682896-121494-1487162780-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121494-
> 1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:46
>
>
> *Para:* oracle_br@yahoog

Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Veja bem.

Temos 2 problemas aqui.

1. Seu Lob está corrompido.
Você provavelmente vai ter que recuperá-lo (RMAN ou manualmente).

A saída do script informou algumas rowid em que foram encontrados blocos
corrompidos.

2.
MAX(MAXQUERYLEN)

   33094

 COLUMN_NAME   SECUREFILE PCTVERSION  RETENTION
- -- -- --
TEXTSHOT  NO 28800

Quer dizer que a query mais demorada de seu banco precisa reter undo por
33094 segundos, enquanto o tempo máximo de retenção de seu lob é de 28800.

Apesar de ser um tempo MUITO GRANDE, teoricamente, seu RETENTION deveria
ser, no mínimo, 33094.

Mas, eu acredito que o problema, provavelmente, está no Lob Corrompido.

Verifique quais são os registros corrompidos (ROWID AABaK4AAyAAM2zJAA4). Se
você puder excluir essa linha e recriá-la

Em seguida, rode novamente aquele procedimento para identificar corrupção e
veja se tem mais.


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 15 de fevereiro de 2017 13:24, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Evandro,
>
> Segue resultado do primeiro comando, desculpe não entendi muito bem o
> resultado.
>
>
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 0
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 1
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 2
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
> Error on rowid AABaK4AAyAAM2zJAA4 page 3
>
> ORA-01555: snapshot too old: rollback segment number  with name "" too
>
> small
>
> ORA-22924: snapshot too old
>
> ORA-06512: at "SYS.DBMS_LOB", line
>
> 1084
>
> ORA-06512: at line 1
>
>
>
> SQL> select max(maxquerylen) from v$undostat;
>
>
>
> MAX(MAXQUERYLEN)
>
> 
>
>33094
>
>
>
> SQL> select COLUMN_NAME, SECUREFILE, PCTVERSION, RETENTION
>
>   2from dba_lobs
>
>   3   where OWNER = 'COMPRAS'
>
>   4 and TABLE_NAME = 'ADM_COMPRAS_PAGE';
>
>
>
> COLUMN_NAME   SECUREFILE PCTVERSION  RETENTION
>
> - -- -- ------
>
> TEXTSHOT  NO 28800
>
>
>
>
>
>
>
> Grato,
>
>
>
>
> *_Ednilson Silva*
>
> (11) 3144-4305
>
> JBS S/A
>
>
>
> *De:* sentto-1682896-121494-1487162780-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121494-
> 1487162780-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *Evandro Giachetto evandrogiache...@gmail.com [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:46
>
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Não acho que o expdp esteja alterando a tabela no momento do export.
>
>
>
> Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
> corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
>
>
>
> Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou
> RETENTION ou PCTVERSION.
>
>
>
> Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
> utilizado (Doc ID 452341.1)
>
>
>
> set serverout on
>
> exec dbms_output.enable(10);
>
> declare
>
>   pagenumber;
>
>   lennumber;
>
>   c  varchar2(10);
>
>   charpp number := 8132/2;
>
>
>
> begin
>
>   for r in (select rowid rid, dbms_lob.getlength () len
>
> from   ) loop
>
> if r.len is not null then
>
>   for page in 0..r.len/charpp loop
>
> begin
>
>   select dbms_lob.substr (, 1, 1+ (page *
> charpp))
>
>   into   c
>
>   from   
>
>   where  rowid = r.rid;
>
>
>
> exception
>
>   when others then
>
> dbms_output.put_line ('Error on rowid ' ||R.rid||' page
> &

[oracle_br] Instalação em silent mode

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Aos que se interessarem.

Feebacks são muito bem vindos.

http://bancotunado.blogspot.com.br/2017/02/instalando-oracle-database-12c-em.html

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/

Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

E, claro.

Estou considerando que você já verificou seu ambiente externo (Discos, CPU,
Memória), se não tem muita concorrência, como o Chiappa falou.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 15 de fevereiro de 2017 10:46, Evandro Giachetto <
evandrogiache...@gmail.com> escreveu:

> Não acho que o expdp esteja alterando a tabela no momento do export.
>
> Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
> corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.
>
> Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou
> RETENTION ou PCTVERSION.
>
> Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
> utilizado (Doc ID 452341.1)
>
> set serverout on
> exec dbms_output.enable(10);
> declare
>   pagenumber;
>   lennumber;
>   c  varchar2(10);
>   charpp number := 8132/2;
>
> begin
>   for r in (select rowid rid, dbms_lob.getlength () len
> from   ) loop
> if r.len is not null then
>   for page in 0..r.len/charpp loop
> begin
>   select dbms_lob.substr (, 1, 1+ (page *
> charpp))
>   into   c
>   from   
>   where  rowid = r.rid;
>
> exception
>   when others then
> dbms_output.put_line ('Error on rowid ' ||R.rid||' page
> '||page);
> dbms_output.put_line (sqlerrm);
> end;
>   end loop;
> end if;
>   end loop;
> end;
> /
>
> Se o LOB não estiver corrompido, use essa query para verificar o tempo
> máximo usado pelas queries no banco:
>
> select max(maxquerylen) from v$undostat;
>
> Como seu undo_retention é bem grande, eu acredito que esse tempo não será
> maior. O problema então provavelmente está mesmo no RETENTION/PCTVERSION do
> seu LOB.
>
> Tenta verificar o retention/pctversion do seu lob.
>
> "COMPRAS"."ADM_COMPRAS_PAGE"
>
> select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where
> OWNER='COMPRAS' and TABLE_NAME='ADM_COMPRAS_PAGE';
>
> Se o Retention do LOB for menor que o UNDO_RETENTION, altere-o para um
> valor maior (Até o máximo de MAX(UNDO_RETENTION, MAXQUERYLEN) ).
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
> http://bancotunado.blogspot.com.br/
>
>
> Em 15 de fevereiro de 2017 10:32, 'Ednilson Silva'
> ednilson.si...@jbs.com.br [oracle_br] 
> escreveu:
>
>>
>>
>> Chiappa,
>>
>> Minha UNDO esta como GUARANTEED.
>>
>>
>>
>> Clonei essa tabela em outro Owner, e no momento do INSERT deu Snapshot
>> too old
>>
>>
>>
>> ORA-01555: instantâneo muito antigo: número de segmento de rollback  com
>> nome  "" muito pequeno
>>
>> ORA-22924: snapshot muito antigo
>>
>>
>>
>> Esta bem claro mesmo que no momento do export algum processo esta
>> alterando essa tabela sim, irei aprofundar meus teste nisso.
>>
>>
>>
>> Grato,
>>
>> Ednilson
>>
>>
>>
>> *De:* sentto-1682896-121491-1487160830-ednilson.silva=jbs.com.br@
>> returns.groups.yahoo.com [mailto:sentto-1682896-121491-
>> 1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
>> de *jlchia...@yahoo.com.br [oracle_br]
>> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:14
>> *Para:* oracle_br@yahoogrupos.com.br
>> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>>
>>
>>
>>
>>
>> Tá, e os outros pontos ** todos ** : essa Retention do UNDO é GUARANTEED
>> ou não ?? Essa é uma informação CRÍTICA que pela terceira vez estamos
>> citando e vc não nos diz SE não for, avalie a Possibilidade de tornar
>> esse UNDo como GUARANTEED ..
>>  De que maneira vc checou que não havia no exato momento do export
>> ninguém fazendo DML na tabela , E por quanto tempo / quantas vezes ?? Tá
>> incluso nisso consulta na V$TRANSACTION ?? A questão aqui é tentar
>> localizar eventuais JOBs (até externos ao banco, talvez) e/ou sessões que
>> façam acessos pequenos mas intermitentes e frequentes - seria Interessante
>> se nesses testes isolados que vc vai fazer à noite vc lançasse mão de
>> alguma técnica (ogra que seja, como remover temporariamente acesso, baixar
>> listener, tornar a tabela READ-ONLY temporariamente, etc) pra tentar
>> garantir que ninguém acesse a tabela enquanto rola o export...
>>  Nesse teste que vc vai fazer é ** imperativo ** que além de não haver
>> outras Transações, vc ** VERIFIQUE ** o Consumo e utilização de UNDO como
>> indicado previamente, também... E Não Deixe de fazer os demais testes que
>> sugeri na minha outra resposta, como testar com exp tradicional, tentar um
>> SELECT direto nessa tabela, etc... Uma boa checagem na ** PERFORMANCE ** do
>> expdp como um todo, usando as notas que indiquei, seria de bom tom também
>> antes do teu teste à noite...
>>
>>  []s
>>
>>Chiappa
>>
>> 
>>
>
>

Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Não acho que o expdp esteja alterando a tabela no momento do export.

Muito provavelmente essa tabela tem um segmento de LOB e, ou esse LOB está
corrompido, ou o RETENTION ou PCTVERSION desse LOB está pequeno demais.

Uma outra coisa que você deve se atentar é que, usa-se apenas 1, ou
RETENTION ou PCTVERSION.

Tente verificar se seu lob não está corrompido. Esse script aqui pode ser
utilizado (Doc ID 452341.1)

set serverout on
exec dbms_output.enable(10);
declare
  pagenumber;
  lennumber;
  c  varchar2(10);
  charpp number := 8132/2;

begin
  for r in (select rowid rid, dbms_lob.getlength () len
from   ) loop
if r.len is not null then
  for page in 0..r.len/charpp loop
begin
  select dbms_lob.substr (, 1, 1+ (page * charpp))
  into   c
  from   
  where  rowid = r.rid;

exception
  when others then
dbms_output.put_line ('Error on rowid ' ||R.rid||' page
'||page);
dbms_output.put_line (sqlerrm);
end;
  end loop;
end if;
  end loop;
end;
/

Se o LOB não estiver corrompido, use essa query para verificar o tempo
máximo usado pelas queries no banco:

select max(maxquerylen) from v$undostat;

Como seu undo_retention é bem grande, eu acredito que esse tempo não será
maior. O problema então provavelmente está mesmo no RETENTION/PCTVERSION do
seu LOB.

Tenta verificar o retention/pctversion do seu lob.

"COMPRAS"."ADM_COMPRAS_PAGE"

select COLUMN_NAME,SECUREFILE,PCTVERSION,RETENTION from dba_lobs where
OWNER='COMPRAS' and TABLE_NAME='ADM_COMPRAS_PAGE';

Se o Retention do LOB for menor que o UNDO_RETENTION, altere-o para um
valor maior (Até o máximo de MAX(UNDO_RETENTION, MAXQUERYLEN) ).


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 15 de fevereiro de 2017 10:32, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Chiappa,
>
> Minha UNDO esta como GUARANTEED.
>
>
>
> Clonei essa tabela em outro Owner, e no momento do INSERT deu Snapshot too
> old
>
>
>
> ORA-01555: instantâneo muito antigo: número de segmento de rollback  com
> nome  "" muito pequeno
>
> ORA-22924: snapshot muito antigo
>
>
>
> Esta bem claro mesmo que no momento do export algum processo esta
> alterando essa tabela sim, irei aprofundar meus teste nisso.
>
>
>
> Grato,
>
> Ednilson
>
>
>
> *De:* sentto-1682896-121491-1487160830-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121491-
> 1487160830-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *jlchia...@yahoo.com.br [oracle_br]
> *Enviada em:* quarta-feira, 15 de fevereiro de 2017 10:14
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* Re: RES: RES: [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Tá, e os outros pontos ** todos ** : essa Retention do UNDO é GUARANTEED
> ou não ?? Essa é uma informação CRÍTICA que pela terceira vez estamos
> citando e vc não nos diz SE não for, avalie a Possibilidade de tornar
> esse UNDo como GUARANTEED ..
>  De que maneira vc checou que não havia no exato momento do export ninguém
> fazendo DML na tabela , E por quanto tempo / quantas vezes ?? Tá incluso
> nisso consulta na V$TRANSACTION ?? A questão aqui é tentar localizar
> eventuais JOBs (até externos ao banco, talvez) e/ou sessões que façam
> acessos pequenos mas intermitentes e frequentes - seria Interessante se
> nesses testes isolados que vc vai fazer à noite vc lançasse mão de alguma
> técnica (ogra que seja, como remover temporariamente acesso, baixar
> listener, tornar a tabela READ-ONLY temporariamente, etc) pra tentar
> garantir que ninguém acesse a tabela enquanto rola o export...
>  Nesse teste que vc vai fazer é ** imperativo ** que além de não haver
> outras Transações, vc ** VERIFIQUE ** o Consumo e utilização de UNDO como
> indicado previamente, também... E Não Deixe de fazer os demais testes que
> sugeri na minha outra resposta, como testar com exp tradicional, tentar um
> SELECT direto nessa tabela, etc... Uma boa checagem na ** PERFORMANCE ** do
> expdp como um todo, usando as notas que indiquei, seria de bom tom também
> antes do teu teste à noite...
>
>  []s
>
>Chiappa
>
> 
>

Re: [oracle_br] Re: ORA-31693: Table data object

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá Ednilson.

Como o Chiappa disse, esse problema é claramente o banco tentando utilizar
Undo que ele já não tem mais.

Como você não informou, eu suponho que essa tabela seja uma das grandes.

Também, como seus parâmetros estão todos como Default, também imagino que
sua UNDO tenha sido criada com as opções default, isto é, sem o "Retention
Guarantee" habilitado.


Olhando de fora, o que eu posso imaginar o que está acontecendo é o
seguinte:

Seu banco possui muitas transações ao mesmo tempo, usando UNDO "até o
talo", tantas que é impossível segurar uma query por mais de 10 minutos sem
que aquela UNDO tenha sido sobrescrita.

Ou.

Sua UNDO está "Undersized". Ela é tão pequena que não consegue segurar um
select em uma tabela muito grande.

Então, posso te sugerir o seguinte:

Se sua UNDO estiver muito pequena (Menor que o tamanho da tabela, por
exemplo), tente aumentá-la.

Se o export estiver demorando muito mais que 10 minutos somente nessa
tabela, tente rodar o expdp em paralelo, usando o parâmetro parallel.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 14 de fevereiro de 2017 22:35, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Chiappa,
>
> Obrigado pelas dicas, mas sem sucesso.
>
> Executei o export agora a noite é um horário mais tranquilo para o banco.
>
> Olhei os dois links, e segui os conselhos.
>
>
>
> Parei a execução dos JOB, mas pode ser que alguma sessão esta a todo
> instante atualizando essa tabela enquanto coloco o export para executar.
>
> Irei tentar algumas outra forma resolver isso.
>
>
>
> Grato,
>
> Ednilson Silva
>
>
>
> *De:* sentto-1682896-121484-1487096454-ednilson.silva=jbs.
> com...@returns.groups.yahoo.com [mailto:sentto-1682896-121484-
> 1487096454-ednilson.silva=jbs.com...@returns.groups.yahoo.com] *Em nome
> de *jlchia...@yahoo.com.br [oracle_br]
> *Enviada em:* terça-feira, 14 de fevereiro de 2017 16:21
> *Para:* oracle_br@yahoogrupos.com.br
> *Assunto:* [oracle_br] Re: ORA-31693: Table data object
>
>
>
>
>
> Bem ** claramente ** , ao que me parece vc não tem retention suficiente,
> OU se tiver talvez vc tentou rodar o export no meio de um pico de uso, com
> alguma transação gerando muito UNDO ou então muitas pequenas transações
> consumindo...
>
> Experimente re-agendar esse export para um período de tempo onde o banco
> esteja sendo menos usado, em primeiro lugar..
>
> A possibilidade de retention insuficiente (seja na tablespace de UNDO seja
> no LOB SEGMENT) sempre existe também  :  dá um look em
> http://yichen-oracledba.blogspot.com.br/2013/08/
> datapump-export-failed-with-ora-01555.html para refs para o caso de LOB,
> e http://olivertconsultoria.blogspot.com.br/2013/08/
> resolvendo-o-erro-ora-01555.html te dá um pouco da Teoria
>
> E obviamente se vc for Aumentar retention, Muito Provavelmente vc vai
> precisar aumentar o TAMANHO da tablespace de undo, para que seja viável o
> RDBMS honrar esse retention maior
>
> []s
>
>   Chiappa
>
>
> OBS : se precisar monitorar o consumo de UNDO nas suas transações,
> http://soidamientrung.blogspot.com.br/2012/06/who-
> is-using-your-undo-space.html e http://www.dbaref.com/home/
> dba-routine-tasks/findingwhatsconsumingthemostundo dão uns exemplinhos, é
> basicamente consultar V$TRANSACTION
>
> 
>

Re: [oracle_br] Duvida na constr ução de select para localizar um Nome com ou sem acento (JOÃO e JOAO)

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá Daniel.

A solução provida pelo Schiavini é bem interessante.

Se você estiver utilizando Java como linguagem de desenvolvimento de sua
aplicação, um alter session é perfeitamente possível e nada muito
complicado. Seria, basicamente uma instrução a mais no seu objeto Statement
(de qualquer tipo).

Aqui tem um exemplo:

http://stackoverflow.com/questions/17578335/alter-session-to-set-date-format-in-mybatis

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 13 de dezembro de 2016 23:50, daniel...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Étore Schiavini, boa noite.
>
> eu preciso para implementar na aplicação, você tem uma outra sugestão para
> meu problema?
>
> 
>

Re: [oracle_br] Problema em compilação

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá Rafael.

Realmente, o argumento do Developer foi bem fraco.

Na certa ele deve ter sacado que você não manja de Java e jogou esse verde
para você não ficar enchendo o saco dele.

Na certa o cara usa o objeto do tipo Statement no código java para executar
a query... daí monta aquela string salsicha, dando vários concats para
montar os wheres.

A única coisa que mudaria para ele usar Bind seria utilizar o objeto do
tipo PreparedStatement. Na query que ele vai rodar, utiliza o caracter '?'
onde quer que haja um bind.

Depois, para cada ?, usa-se a substituição com um setInt, setString,
setDate, etc.

tipo assim:

String query = "select ename from emp where empid=?";

PreparedStatement stmt=con.prepareStatement(query);

stmt.setInt(1,empno);

O primeiro parâmetro de setInt (1) quer dizer que é o primeiro ? que
aparece na query.

Assim, se tivesse mais, vc iria setando os valores assim: setInt(2, valor)
setInt(3,valor) etc.

Espero ter sido claro...

Agora você já tem argumento par brigar com o seu developer.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 2 de agosto de 2016 20:02, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> É ** mais que fraco **, é Risível o 'argumento' do teu desenvolver :
> pesquisa em http://asktom.oracle.com por JAVA BIND que vc vai achar PELO
> MENOS uma dúzia de artigos que discutem algumas opções/best practices de
> como implementar BINDING em java/jdbc e demonstram os graves problemas que
> podem advir de não usar, E além disso ainda educam sobre a Recomendação e
> as Palpáveis Vantagens de usar PREPARED STATEMENT 
>  Nós sabemos que desenvolvedor é aquela água, neguim não quer saber de
> usar o banco de dados da maneira correta mas sim da maneira que ELE acha
> ser mais fácil, depois quando a coisa chega no ventilador a culpa é do DBA,
> ele VAI dar as maiores desculpas pra não aprender a usar a tecnologia de
> maneira correta, sim sim, mas pelo menos vc tem que deixar Claro (não só
> pra ele MAS pro gerente e pros Superiores de vcs) os Riscos (de
> performance, de mal-uso da capacidade de hardware, até de Segurança) a que
> estão sujeitos por não usar BIND VARIABLES e não acessar/trabalhar com o
> RDBMS da maneira correta e adequada...
>
> ´[]s
>
>Chiappa
> 
>

Re: [oracle_br] Dúvida sobre parallel

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Valeu Chiappa. Como sempre sua atenção aos membros do grupo é digna de
várias rodadas de Cerveja (embora eu acho que eu seja o único dba no mundo
que não bebe.. rss)

Eu estava pensando nisso mesmo que você falou e, para ser sincero, depois
que mandei o e-mail encontrei os bugs, mas como ele dizia acontecer até o
11.2.0.3, não dei tanta importância. Pode mesmo ser uma reapresentação.

Fabio, foi exatamente isso que eu disse ao topeir... errr... developer :o)
.. Eu achei o comportamento curioso e por isso postei aqui na lista, pois
outros podem já ter passado por isso e ter uma solução... ou mesmo serve de
"heads up" para os que ainda não viram esse comportamento.

Amanhã eu devo coletar os traces, embora eu tenha que mudar malandramente a
tabela para auto dop novamente... pois já pedi para o developer voltar as
tabelas para noparallel.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 2 de agosto de 2016 19:53, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Não sei não : numa outra mensagem depois desta que vc respondeu, o colega
> mostrou que a má-performance só acontece se ele usar AUTO-DOP , se ele
> indica o degree of parallelism manualmente a performance é normal - se
> fosse questão de falta de cpu, gerenciamento de fila longuíssima de slaves
> ou coisa assim em tese deveria acontecer TAMBÉM quando ele usa o auto-dop,
> acho... .  Eu ainda penso que o que tá parecendo é bug no auto-dop e/ou
> acesso ao dicionário comprometido (pois o AUTO-DOP tem que consultar e
> analisar muita coisa)  Mas só quando ele fazer o teste de trace que
> indiquei numa outra msg E confirmar com o SUporte a chance de bugs é que
> vamos saber a real...
>
>  []s
>
>   Chiappa
> 
>

[oracle_br] Re: Dúvida sobre parallel

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Apenas adicionando um dado.

Se eu rodar a query dessa forma ela termina rápido.

SQL> select /*+ parallel */ * from gdw_adm.d_country;

288 rows selected.

Elapsed: 00:00:00.21

Execution Plan
--
Plan hash value: 2802851973

---
| Id  | Operation| Name  | Rows  | Bytes | Cost (%CPU)|
Time |TQ  |IN-OUT| PQ Distrib |
---
|   0 | SELECT STATEMENT |   |   288 | 21600 | 2   (0)|
00:00:01 ||  ||
|   1 |  PX COORDINATOR  |   |   |   ||
 ||  ||
|   2 |   PX SEND QC (RANDOM)| :TQ1  |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |PX BLOCK ITERATOR |   |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWC ||
|   4 | TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWP ||
---

Note
-
   - automatic DOP: Computed Degree of Parallelism is 2


Statistics
--
  6  recursive calls
  0  db block gets
 13  consistent gets
  0  physical reads
  0  redo size
  23875  bytes sent via SQL*Net to client
733  bytes received via SQL*Net from client
 21  SQL*Net roundtrips to/from client
  0  sorts (memory)
  0  sorts (disk)
288  rows processed


Mas, sem especificar nenhum hint, apenas aceitando o que está no atributo
parallel da tabela, ela leva 28s.

select * from gdw_adm.d_country

288 rows selected.

Elapsed: 00:00:28.42

Execution Plan
--
Plan hash value: 2802851973

---
| Id  | Operation| Name  | Rows  | Bytes | Cost (%CPU)|
Time |TQ  |IN-OUT| PQ Distrib |
---
|   0 | SELECT STATEMENT |   |   288 | 21600 | 2   (0)|
00:00:01 ||  ||
|   1 |  PX COORDINATOR  |   |   |   ||
 ||  ||
|   2 |   PX SEND QC (RANDOM)| :TQ1  |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |PX BLOCK ITERATOR |   |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWC ||
|   4 | TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWP ||
---


Statistics
--
   1277  recursive calls
  0  db block gets
 13  consistent gets
  0  physical reads
  0  redo size
  23867  bytes sent via SQL*Net to client
733  bytes received via SQL*Net from client
 21  SQL*Net roundtrips to/from client
  0  sorts (memory)
  0  sorts (disk)
288  rows processed

Alguém aí já observou esse comportamento? Será um bug?

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


Em 2 de agosto de 2016 14:30, Evandro Giachetto 
escreveu:

> Olá pessoal, estou com uma dúvida sobre um comportamento que tenho
> observado.
>
> Um dos retard eerr.. quer dizer, developers... alterou todas as
> tabelas de um schema para PARALLEL. (alter table  parallel )
>
> Dessa forma o Oracle define o degree como "default"... porém, uma coisa me
> chamou a atenção.
>
> Para uma tabela com apenas 280 linhas, um select * levou em torno de 28s
> para ser processado, tendo a cláusula de parallel setada.
>
> Se eu altero a tabela para noparallel (ou mesmo rodo o mesmo select com a
> hint de noparallel), ela me entrega todos os dados em menos de 1s (quase
> instantâneo), mesmo após limpar o cache.
>
> Minha dúvida é: Será que isso pode ser algum bug? Não acredito que o
> oracle precise de todo esse tempo para montar todos os slaves e começar a
> processar a query em paralelo.
>
> Versão: 11.2.0.4
> RAC com 4 nós
>
> Fiz o rebalanceamento de IO recentemente.
>
> SQL> select * from gdw_adm.d_country;
>
> 288 rows selected.
>
> Elapsed: 00:00:28.43
>
> Execution Plan
> --
> Plan hash value: 2802851973
>
>
> ---
> | Id  | Operation| Name  

[oracle_br] Dúvida sobre parallel

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá pessoal, estou com uma dúvida sobre um comportamento que tenho
observado.

Um dos retard eerr.. quer dizer, developers... alterou todas as tabelas
de um schema para PARALLEL. (alter table  parallel )

Dessa forma o Oracle define o degree como "default"... porém, uma coisa me
chamou a atenção.

Para uma tabela com apenas 280 linhas, um select * levou em torno de 28s
para ser processado, tendo a cláusula de parallel setada.

Se eu altero a tabela para noparallel (ou mesmo rodo o mesmo select com a
hint de noparallel), ela me entrega todos os dados em menos de 1s (quase
instantâneo), mesmo após limpar o cache.

Minha dúvida é: Será que isso pode ser algum bug? Não acredito que o oracle
precise de todo esse tempo para montar todos os slaves e começar a
processar a query em paralelo.

Versão: 11.2.0.4
RAC com 4 nós

Fiz o rebalanceamento de IO recentemente.

SQL> select * from gdw_adm.d_country;

288 rows selected.

Elapsed: 00:00:28.43

Execution Plan
--
Plan hash value: 2802851973

---
| Id  | Operation| Name  | Rows  | Bytes | Cost (%CPU)|
Time |TQ  |IN-OUT| PQ Distrib |
---
|   0 | SELECT STATEMENT |   |   288 | 21600 | 2   (0)|
00:00:01 ||  ||
|   1 |  PX COORDINATOR  |   |   |   ||
 ||  ||
|   2 |   PX SEND QC (RANDOM)| :TQ1  |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |PX BLOCK ITERATOR |   |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWC ||
|   4 | TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 2   (0)|
00:00:01 |  Q1,00 | PCWP ||
---


Statistics
--
   1280  recursive calls
  0  db block gets
 13  consistent gets
  0  physical reads
  0  redo size
  23867  bytes sent via SQL*Net to client
733  bytes received via SQL*Net from client
 21  SQL*Net roundtrips to/from client
  0  sorts (memory)
  0  sorts (disk)
288  rows processed


SQL> select /*+ noparallel */ * from gdw_adm.d_country;

288 rows selected.

Elapsed: 00:00:00.06

Execution Plan
--
Plan hash value: 3256989411

---
| Id  | Operation | Name  | Rows  | Bytes | Cost (%CPU)| Time
  |
---
|   0 | SELECT STATEMENT  |   |   288 | 21600 | 3   (0)|
00:00:01 |
|   1 |  TABLE ACCESS FULL| D_COUNTRY |   288 | 21600 | 3   (0)|
00:00:01 |
---


Statistics
--
  1  recursive calls
  0  db block gets
 26  consistent gets
  0  physical reads
  0  redo size
  28788  bytes sent via SQL*Net to client
733  bytes received via SQL*Net from client
 21  SQL*Net roundtrips to/from client
  0  sorts (memory)
  0  sorts (disk)
288  rows processed



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/

Re: [oracle_br] Criando database com DBCA em silent mode

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Legal Andre.

Um dos problemas que eu tenho aqui é que eu conecto nos servidores através
de uma VPN e as ferramentas gráficas da Oracle (OUI, DBCA, NETCA) ficam
impraticáveis quando se está atrás de uma VPN.

Eu também vou fazer um tutorialzinho pro meu blog com o DBCA com UI, além
da criação "Na Unha" de um db...

Aos pouquinhos vamos alimentando.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/


2016-03-03 12:53 GMT-03:00 Andre Luiz Reis Marques aandre...@yahoo.com.br
[oracle_br] :

>
>
> Evandro,
>
> Gostei do artigo, parabéns, sempre utilizei o DBCA, mas com a configuração
> do Xming e put.
>
> Atenciosamente,
> André Luiz R. Marques
> Administrador de Banco de Dados - SQL Server/Oracle
> Tel: (21) 99978-4564
>
> *Evite imprimir. Colabore com o Meio Ambiente!*
>
> "Embora ninguém possa voltar atrás e fazer um novo começo, qualquer um pode
> começar agora e fazer um novo fim."
>*Chico Xavier*
>
>
>
> Em Quinta-feira, 3 de Março de 2016 12:23, "Evandro Giachetto
> evandrogiache...@gmail.com [oracle_br]" 
> escreveu:
>
>
>
> Olá pessoal.
>
> Gostaria de compartilhar com vocês, embora o nível do artigo possa não
> alcançar o nível dos DBAs do grupo, acredito que possa ser util para os que
> estão começando agora na carreira, ou pretendem seguir como DBA.
>
> Feedbacks são bem vindos.
>
>
> http://bancotunado.blogspot.com.br/2016/02/criando-um-database-utilizando-dbca-em.html
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
> http://bancotunado.blogspot.com.br/
>
>
>
> 
>

[oracle_br] Criando database com DBCA em silent mode

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá pessoal.

Gostaria de compartilhar com vocês, embora o nível do artigo possa não
alcançar o nível dos DBAs do grupo, acredito que possa ser util para os que
estão começando agora na carreira, ou pretendem seguir como DBA.

Feedbacks são bem vindos.

http://bancotunado.blogspot.com.br/2016/02/criando-um-database-utilizando-dbca-em.html

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com
http://bancotunado.blogspot.com.br/

Re: [oracle_br] Drop Table.

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

O synonym, embora aponte para a tabela, não é associado/ligado/dependente
daquela tabela.

É um objeto a parte, que pode ser apontado para objetos de qualquer schema
e, inclusive, para objetos de outros bancos de dados.

Imagine a seguinte situação.

Você tem 2 schemas diferentes SCHEMA1 e SCHEMA2 e ambos possuem uma tabela
com o mesmo nome e estrutura: TABELA.

Imagine que seu negócio exige que a aplicação use a tabela do SCHEMA1 em
determinado momento e a tabela do SCHEMA2 em outro momento. Você pode fazer
esse controle usando um synonym, que aponta hora para SCHEMA1.TABELA e hora
para SCHEMA2.TABELA.

Triggers, Indices e Constraints são objetos DEPENDENTES, que só existem (e
só fazem sentido em existir) enquanto a tabela na qual foram criados ainda
exista.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 23 de fevereiro de 2016 10:47, Eduardo Rodrigues oraedua...@gmail.com
[oracle_br]  escreveu:

>
>
> Pessoal muito o obrigado pelo retorno, achei estranho é que o synonym que
> também é associado a tabela não é apagado.
>
> @ OK Chiappa vou verificar sim, muito obrigado.
>
> *Att.*
> *Eduardo Rodrigues*
>
> Em 22 de fevereiro de 2016 12:01, André Luiz aandre...@yahoo.com.br
> [oracle_br]  escreveu:
>
>>
>>
>> Certamente. Pois  objeto triggres é um objeto associado a tabela.
>>
>> Enviado do meu iPhone
>>
>> Em 22 de fev de 2016, às 11:55, Eduardo Rodrigues oraedua...@gmail.com
>> [oracle_br]  escreveu:
>>
>>
>>
>> Bom dia Senhores,
>>
>> Uma duvida, quando apago uma tabela do banco de Oracle versão 10.2.0.5.0,
>> ele apaga as triggers criado para tabela?
>>
>>
>> *Att.*
>> *Eduardo Rodrigues*
>>
>>
> 
>

Re: [oracle_br] Drop Table.

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Sim !

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 22 de fevereiro de 2016 11:55, Eduardo Rodrigues oraedua...@gmail.com
[oracle_br]  escreveu:

>
>
> Bom dia Senhores,
>
> Uma duvida, quando apago uma tabela do banco de Oracle versão 10.2.0.5.0,
> ele apaga as triggers criado para tabela?
>
>
> *Att.*
> *Eduardo Rodrigues*
>
> 
>

Re: [oracle_br] Arquivos no ASM

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Tudo depende do Seu storage e de como o administrador do storage vai
disponibilizar esses discos para você.

O ASM em sí já tenta fazer um balanceamento dos dados nos discos por
setores. Assim, dados que são acessados muitas vezes juntos (como indices e
tabelas) são colocados em setores diferentes do mesmo disco, o que facilita
a leitura.

Aqui na empresa que eu trabalho, por exemplo, nós temos alguns discos SSD
dedicados a algumas tablespaces em que precisamos de um acesso mais rápido.

Pra isso, foi criado um novo diskgroup no asm com aqueles discos ssd e os
datafiles para aquelas tablespaces são colocadas lá.

Além dos diskgroups DATA e FRA. Sim, nós separamos a Flash Recovery Area
dos dados.

Agora, à sua pergunta:

Se seus discos DATA, FRA, REDO, ARCH são diskgroups separados, ambos
criados em seus respectivos discos individuais e não chunks do mesmo disk
no storage, então sim, teoricamente vc deve ter uma performance melhor pois
sua concorrência na leitura/escrita dos dados será menor.

Agora, se essas separações que vc mencionou (DATA, FRA, REDO, ARCH) são
apenas pastas dentro do mesmo diskgroup, então não irá influenciar na sua
performance.




Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 22 de fevereiro de 2016 10:23, 'Duilio Bruniera'
duilio.bruni...@fastsolutions.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Senhores eu sempre vejo por ai.
>
> A maioria dos post em blog’s que leio durante a instalação  costuma-se
> dividir a área do ASM em (DATA / FRA / ARCH / REDO / WALL ) ... etc .
>
> E dentro de cada pasta separar cada tipo de arquivo físico do Oracle, é
> lógico que de um ponto de vista organizacional é mais bonito, mais
> performaticamente influencia em algo?
>
> --
> Esta mensagem foi verificada pelo sistema de antivírus e
> acredita-se estar livre de perigo.
>
> 
>

Re: [oracle_br] Compartilhando: USM driver install actions failed - ACFS-9459: ADVM/ACFS is not supported on this OS version Durante upgrade do Oracle Grid Infrastructure: rootupgrade.sh / root.sh (11

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Existe um Patch específico para o Suse.

No meu caso é o Oracle Enterprise Linux com o kernel 2.6.18.

Infelizmente não encontrei um patch para isso para minha versão do linux.

O mais próximo que encontrei foi um bug (que não me recordo o numero agora)
que indicava justamente isso, onde o oracle procura no lugar "Errado" pela
versão do kernel e na descrição desse bug dizia apenas "Corrigido no 12c" e
não apresentava um workaround.

Na ocasião nós abrimos um TAR na oracle, porém o atendente não foi capaz de
prover uma solução eficaz, mesmo após tendo mencionado que ocorreu o
upgrade do kernel do SO DELES utilizando kpslice.

Para chegar a essa solução eu usei, dentre outra notas, como mencionei no
texto, a nota do problema no suse, em que descrevia esse workaround.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 20 de fevereiro de 2016 18:05, Vitor Junior vitorj...@gmail.com
[oracle_br]  escreveu:

>
>
> Tive o mesmo problema no suse, onde o patch mistura aplicar com cópia de
> arquivos. :)
>
> Em Sex, 19 de fev de 2016 20:42, Paulo Jr paulobarbosa@gmail.com
> [oracle_br]  escreveu:
>
>>
>>
>> Evandro boa noite,
>>
>> Peguei este erro quando fui instalar do zero o grid 11.2.0.4 no SuSE11
>> SP3 , fiz a correção aplicando um patch , vou escrever e publicar também.
>>
>> Abraços.
>>
>>
>> Em sex, 19 de fev de 2016 20:23, Evandro Giachetto
>> evandrogiache...@gmail.com [oracle_br] 
>> escreveu:
>>
>>>
>>>
>>> Olá amigos.
>>>
>>> Gostaria de compartilhar com vocês a solução para um problema que fez
>>> com que eu perdesse alguns fios de cabelo e algumas noites de sono.
>>>
>>> O problema ocorreu durante o upgrade do Grid Infrastructure para a
>>> versão 11.2.0.4 devido a discrepâncias na identificação do kernel utilizado
>>> pelo OS (Oracle Linux 5).
>>>
>>> Espero que seja útil.
>>>
>>>
>>> http://bancotunado.blogspot.com.br/2016/02/usm-driver-install-actions-failed-acfs.html
>>>
>>> Evandro Giachetto
>>> Oracle DBA
>>> evandrogiache...@gmail.com
>>>
>>> --
> Att,/Regards,
>
>
> Vitor Jr.
> Infraestrutura / Infrastructure Team
>
> Oracle 12c DBA Certified Professional - OCP 12c
> Oracle 11g DBA Certified Professional - OCP 11g
> 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
> https://mybizcard.co/vitor.jr.385628
>
> 
>

[oracle_br] Compartilhando: USM driver install actions failed - ACFS-9459: ADVM/ACFS is not supported on this OS version Durante upgrade do Oracle Grid Infrastructure: rootupgrade.sh / root.sh (11.2.0

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá amigos.

Gostaria de compartilhar com vocês a solução para um problema que fez com
que eu perdesse alguns fios de cabelo e algumas noites de sono.

O problema ocorreu durante o upgrade do Grid Infrastructure para a versão
11.2.0.4 devido a discrepâncias na identificação do kernel utilizado pelo
OS (Oracle Linux 5).

Espero que seja útil.

http://bancotunado.blogspot.com.br/2016/02/usm-driver-install-actions-failed-acfs.html

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com

Re: [oracle_br] Oracle "conversar" com Sql Server

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olá Tathyana.

Você pode usar o Oracle Heterogeneous Services para se conectar em diversos
outros bancos de dados, incluindo o SQL Server.

Ele utiliza de conexão odbc, o que não é uma feature grátis em ambientes
unix.
https://docs.oracle.com/cd/B19306_01/server.102/b14232/admin.htm

Por outro lado, você pode criar essa conexão a partir do lado do sql
server, como o colega mencionou há alguns e-mails atrás, e, ao invés de o
Oracle fazer o "Push" dos dados, será o SQL Server que fará o "Pull" para
suas tabelas.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 22 de janeiro de 2016 11:31, Tathyanna Pelegrinni tathya...@gmail.com
[oracle_br]  escreveu:

>
>
> Oi, gente!!
>
> Alguem já precisou fazer com que o Oracle converse* com o Sql Server?
>
> No caso, Oracle se conectaria no Sql Server para transferir dados de uma
> tabela dele -Oracle- para uma tabela do Sql Server.
> Alguem!? rs..
>
>
>
> Valeu!!
>
>
> - TaThyanna
>
> 
>

Re: [oracle_br] Re: RES: RES: [dba-brasil] 1º Encontro DBA Brasil

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Eu faço parte e posso ter perdido esse e-mail q vc mandou, pois não me
lembro de tê-lo lido.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 4 de novembro de 2015 16:44, Fabio Prado fbifa...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Mandei e-mail no grupo do Chiappa, mas ninguém se manifestou por lá.
>
> Alguém mais aqui faz parte do grupo oracle_br@yahoogrupos.com.br? Se sim,
> poderiam agitar por lá também?
>
> []s
>
>
> *Fábio Prado*
> 
> www.fabioprado.net
> "Compartilhando conhecimentos e treinando profissionais em Bancos de Dados
> Oracle"
>
>
> Em 4 de novembro de 2015 16:37, angelo  escreveu:
>
>>
>> Isso, vamos juntar uma grande quantidade de DBAs e assim poderamos
>> executar aquele velho plano de dominar o mundo... Kk
>>
>>
>> brincadeiras a parte, eu acho muito boa a iniciativa e é excelente para
>> aumentar o circulo de contatos e amizades.
>> quando o negócio desembarcar no RJ, é certo que eu entre no circuito
>> também.
>>
>> A propósito, estou sentindo falta de duas pessoas aqui nessa lista: O JL
>> Chiappa do Oracle e o Joao Bosel Polisel, do Sql Server.  Ninguém os puxou
>> para esta lista ?
>>
>> []s angelo
>>
>>
>> 2015-11-03 20:50 GMT-02:00 Lucios Tolentino :
>>
>>> Compreendi,
>>>
>>> Então se o melhor horário for as 20 horas, que sejao importante é a
>>> galera poder comparecer em massa. Assim juntamos uma grande quantidade de
>>> DBAs já no primeiro encontro e todos se conhecerem pessoalmente.
>>>
>>> Vocês decidem aí senhores, eu to envolvido.
>>> Em 03/11/2015 20:44, "Cezar Mulotto" 
>>> escreveu:
>>>
 O problema Lúcio é o deslocamento, porque quem trabalha em horário
 comercial sai normalmente as 18h.



 *De:* dba-bra...@googlegroups.com [mailto:dba-bra...@googlegroups.com] *Em
 nome de *Lucios Tolentino
 *Enviada em:* terça-feira, 3 de novembro de 2015 20:43
 *Para:* dba-bra...@googlegroups.com
 *Assunto:* Re: RES: [dba-brasil] 1º Encontro DBA Brasil



 Fábio, boa noite.

 Concordo e acho q poderia ser até mais cedo, tipo umas 18 ou 18:30 pra
 q não fique tarde pra alguns, principalmente os q tem família, fica
 complicado chegar muito tarde.

 O que vcs acham pessoal?

 Em 03/11/2015 19:57, "Fabio Prado"  escreveu:

 Pessoal,

Como a maioria é de São Paulo que tal começar um encontro nesta
 cidade em algum "barzinho" e se depois o evento "pegar"  a gente começa a
 pensar em outros lugares?

Quanto à data, sugiro começar em um dia da semana à noite, por volta
 das 20h. Como o encontro está começando e muita nao se conhece, acho mais
 difícil envolver família "neste momento".

 Abs

 Fábio Prado

 Em 03/11/2015 17:09, "angelo"  escreveu:



 E eu do Rio de Janeiro/RJ.



 Pra eu ir, só marcando com alguma antecedencia, apesar de SP ser "logo
 ali"







 2015-11-03 15:52 GMT-02:00 Cleysson Lima :

 Opa,  a maioria de SAMPA e sou de Brasília. Acho que vai ficar para
 próxima!



 []'s



 Cleysson Lima

 DBA PostgreSQL/MySQL

 Em terça-feira, 13 de outubro de 2015 17:33:46 UTC-3, Cezar Mulotto
 escreveu:

 Acho que será interessante o "Where" para satisfazer a todas as
 condições...



 "Select Datetime As 'Dia e Hora do Encontro' , Place As 'Local do
 Encontro' From dba-brasil Where 



 :)



 *De:* dba-b...@googlegroups.com [mailto:dba-b...@googlegroups.com
 ] *Em nome de *Juarez Thomazelli
 *Enviada em:* terça-feira, 13 de outubro de 2015 17:24
 *Para:* dba-b...@googlegroups.com
 *Assunto:* Re: RES: [dba-brasil] 1º Encontro DBA Brasil



 Pode marcar, sábado e domingo pra mim é tranquilo.



 Abraços






 Juarez Thomazelli



 +(55) 11 982521460
 EMAIL: juar...@gmail.com
 LINKEDIN: http://br.linkedin.com/in/juarezthomazelli



 Em 13 de outubro de 2015 08:32, Regis Araujo 
 escreveu:

 Bom dia a Todos!!!



 E ai, ninguém mais???



 Pohhh.. o Grupo esta fraco heim...





 Abraços..!











 2015-10-07 12:38 GMT-03:00 Gervasio Ramos Oliveira Junior <
 groj...@gmail.com>:

 Apareço também pra não me chamarem de anti social... Rsss

 Gervásio Ramos Oliveira Jr
 Enviado de um dispositivo móvel, desculpe-me por possíveis erros de
 digitação.

 Em 07/10/2015 12:24, "Ronaldo Garcia" 
 escreveu:

 Tô dentro



 *Att*

 *Ronaldo Garcia de Brito*

 *Adm Banco de Dados*

 (011)9 8014-3734

Re: [oracle_br] Re: Replicação usando EMC Recoverpoint

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Legal Luis.

Na verdade, o lado Powerpath não fui eu quem montou. O SA do cliente fez
essa parte e ele, basicamente, me entregou e falou "Se vira".

Pra ser bem sincero eu não conheço nada sobre essa ferramenta.

Se você tiver algum white paper ou um howto de como fazer essa configuração
seria fantástico. Me ajudaria muito.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 25 de junho de 2015 15:38, Luis Freitas lfreita...@yahoo.com [oracle_br]
 escreveu:

>
>
> Evandro,
>
>  Trabalhei algumas vezes com essa solução, e realmente será um crash
> recover, com alguma perda de dados. Se a replicação for sincrona em teoria
> você deve conseguir recuperar todas as transações comitadas, contanto que
> não haja erros durante o crash recover.
>
>  Como recebeu esse erro entendo que de alguma forma a replicação do
> disco de datafile foi quebrada depois da replicação de um controlfile. Os
> controlfiles sempre tem o SCN mais atual.
>
>   Você colocou todos os discos do banco de dados em um mesmo grupo de
> replicação? (Consistency Group)
>
> Atc,
> Luis
>
>
>
>   On Thursday, June 25, 2015 11:54 AM, "Evandro Giachetto
> evandrogiache...@gmail.com [oracle_br]" 
> wrote:
>
>
>
>  Obrigado mais uma vez Chiappa por sua explicação.
>
> Eu tenho uma nova chance de colocar isso pra funcionar e tentarei fazer da
> forma correta agora :)
>
> Vou gerar uma nova cópia do controlfile e ver se consigo restaurar o banco
> a partir desse novo controlfile.
>
> Mesmo tendo que acessar o servidor antigo neste momento.
>
> Eu pensei em configurar um backup do controlfile de tempos em tempos
> direto no FRA (ou usar o snapshot controlfile [???] não sei se é
> possível restaurar com o snapshot). Esse backup sempre vai ter um scn mais
> antigo e talvez eu possa abrir o banco aplicando os archives que já estão
> no FRA.
>
> De qualquer forma. A cópia entre discos é feita com os discos no servidor
> secundário ainda desmontados. Ou seja, eles são "desapresentados" do SO e
> reapresentados quando a transferência está completa a partir do console do
> EMC. Então, ninguém está tocando nos discos eqto a transferência é feita.
>
> Eu achei intrigante ele não abrir, já que imaginei que, com a cópia dos
> arquivos, mesmo que sem o último checkpoing aplicado o banco abriria numa
> boa.
>
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
>
> Em 25 de junho de 2015 11:45, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>
>  Opa, blz ? Então, eu não trabalhei com essa daí ainda, mas farei a
> Observação geral e genérica que faço ** SEMPRE ** aqui no Fórum quando se
> fala de replicação por storage (veja as muitas msgs mais antigas sobre
> isso) que vai ser usada com banco-origem ONLINE/ATIVO : a primeira coisa
> que vc TEM que receber (do Suporte, da Documentação, enfim, de alguma fonte
> CONFIÁVEL sobre a solução de replicação de blocos de disco) é que ela **
> EFETIVAMENTE BLOQUEIA ** o acesso aos blocos TODOS nquanto a
> cópia/transferência está rolando, ok ?? O que esse pessoalzinho muitas
> vezes esquece é o RDBMS Oracle ** nunca ** grava imediatamente a informação
> alterada em disco de forma imediata (SEMPRE é em background, e de forma
> "preguiçosa", e que pode iniciar a Qualquer Momento em Qualquer Bloco do
> disco) E ** tranquilamente ** (ainda que NÃO estejam havendo Transações!!)
> alguns arquivos (especialmente CONTROLFILEs!) podem estar sendo gravados...
> Em cima disso, imagine que a solução de replicação leu o bloco x, e por
> azar nesse instante em que o está replicando o RDBMS cisma de querer gravar
> e grava coisa nesse bloco... Ou ainda, imagine que (ainda durante a cópia
> de blocos) o RDBMS atualizou o SCN num datafile MAs não atualizou ainda no
> controlfile, ou vice-versa : SCN inapropriado é o Mínimo que se pode
> esperar se vc quiser subir uma cópia nesses condições REPITO, Alguém
> Tem que te Garantir que esse tipo de coisa não ocorre, que a Solução
> efetivamente BLOQUEIA acesso ao Storage no instante em que a Replicação
> está rolando... SE vc realmente quer ter failover instantâneo, a solução de
> replicação do STorage TEM que te garantir esse tipo de Integridade...
>
>   Aí chegamos no ponto da CONFIGURAÇÃO eventualmente necessária : por
> exemplo, já vo Soluções que (justamente por não bloquear/garantir que
> ninguém tá atualizando algo enquanto rola a transferência )exigiam que vc
> tivesse no "servidor-réplica" um BACKUP do Controlfile numa posição mais
> antiga e daí, quando esse servidor for "assumir" como Produção, vc TINHA
> que antes pedir o restore desse controlfile mais antigo e APLICAR os
> archives daí em diante, o que Logicamente não era instantâneo...
>
>  []s
>
>Chiappa
>
>
>
>
>   
>

Re: [oracle_br] Re: Replicação usando EMC Recoverpoint

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Obrigado mais uma vez Chiappa por sua explicação.

Eu tenho uma nova chance de colocar isso pra funcionar e tentarei fazer da
forma correta agora :)

Vou gerar uma nova cópia do controlfile e ver se consigo restaurar o banco
a partir desse novo controlfile.

Mesmo tendo que acessar o servidor antigo neste momento.

Eu pensei em configurar um backup do controlfile de tempos em tempos direto
no FRA (ou usar o snapshot controlfile [???] não sei se é possível
restaurar com o snapshot). Esse backup sempre vai ter um scn mais antigo e
talvez eu possa abrir o banco aplicando os archives que já estão no FRA.

De qualquer forma. A cópia entre discos é feita com os discos no servidor
secundário ainda desmontados. Ou seja, eles são "desapresentados" do SO e
reapresentados quando a transferência está completa a partir do console do
EMC. Então, ninguém está tocando nos discos eqto a transferência é feita.

Eu achei intrigante ele não abrir, já que imaginei que, com a cópia dos
arquivos, mesmo que sem o último checkpoing aplicado o banco abriria numa
boa.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 25 de junho de 2015 11:45, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Opa, blz ? Então, eu não trabalhei com essa daí ainda, mas farei a
> Observação geral e genérica que faço ** SEMPRE ** aqui no Fórum quando se
> fala de replicação por storage (veja as muitas msgs mais antigas sobre
> isso) que vai ser usada com banco-origem ONLINE/ATIVO : a primeira coisa
> que vc TEM que receber (do Suporte, da Documentação, enfim, de alguma fonte
> CONFIÁVEL sobre a solução de replicação de blocos de disco) é que ela **
> EFETIVAMENTE BLOQUEIA ** o acesso aos blocos TODOS nquanto a
> cópia/transferência está rolando, ok ?? O que esse pessoalzinho muitas
> vezes esquece é o RDBMS Oracle ** nunca ** grava imediatamente a informação
> alterada em disco de forma imediata (SEMPRE é em background, e de forma
> "preguiçosa", e que pode iniciar a Qualquer Momento em Qualquer Bloco do
> disco) E ** tranquilamente ** (ainda que NÃO estejam havendo Transações!!)
> alguns arquivos (especialmente CONTROLFILEs!) podem estar sendo gravados...
> Em cima disso, imagine que a solução de replicação leu o bloco x, e por
> azar nesse instante em que o está replicando o RDBMS cisma de querer gravar
> e grava coisa nesse bloco... Ou ainda, imagine que (ainda durante a cópia
> de blocos) o RDBMS atualizou o SCN num datafile MAs não atualizou ainda no
> controlfile, ou vice-versa : SCN inapropriado é o Mínimo que se pode
> esperar se vc quiser subir uma cópia nesses condições REPITO, Alguém
> Tem que te Garantir que esse tipo de coisa não ocorre, que a Solução
> efetivamente BLOQUEIA acesso ao Storage no instante em que a Replicação
> está rolando... SE vc realmente quer ter failover instantâneo, a solução de
> replicação do STorage TEM que te garantir esse tipo de Integridade...
>
>   Aí chegamos no ponto da CONFIGURAÇÃO eventualmente necessária : por
> exemplo, já vo Soluções que (justamente por não bloquear/garantir que
> ninguém tá atualizando algo enquanto rola a transferência )exigiam que vc
> tivesse no "servidor-réplica" um BACKUP do Controlfile numa posição mais
> antiga e daí, quando esse servidor for "assumir" como Produção, vc TINHA
> que antes pedir o restore desse controlfile mais antigo e APLICAR os
> archives daí em diante, o que Logicamente não era instantâneo...
>
>  []s
>
>Chiappa
>
>  
>

[oracle_br] Dúvida de RMAN

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Pessoal, percebi um comportamento que não tinha percebido ainda no RMAN.

Talvez seja algo bem noob, mas se alguém puder compartilhar uma solução :)

Os scripts estão no final do e-mail.

Bom, estou movendo alguns datafiles para um novo disco.

No script eu estou alocando 10 canais, no entanto, ao executar esse bloco,
eu percebo que o rman está usando apenas no ch1 para todos os backup as
copy.

Eu imagino que seja pq tudo está indo para um mesmo disco... mas, eu já vi
backups sendo feitos para um único mount point e ainda assim rodando em
diversos canais.

RUN
{
allocate channel ch1 type disk;
allocate channel ch2 type disk;
allocate channel ch3 type disk;
allocate channel ch4 type disk;
allocate channel ch5 type disk;
allocate channel ch6 type disk;
allocate channel ch7 type disk;
allocate channel ch8 type disk;
allocate channel ch9 type disk;
allocate channel ch10 type disk;
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_BTC_GDWHS_PUBLIC_I_S_03.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_BTC_GDWHS_PUBLIC_I_S_03.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHD_D_01.dbf" FORMAT
"/mnt/GWP01/datafiles/GWP01_CHD_D_01.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_07.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_07.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_08.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_08.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_09.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_09.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_10.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_10.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_01.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_01.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles18/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_02.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_02.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_03.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_03.dbf";
BACKUP AS COPY DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_04.dbf"
FORMAT "/mnt/GWP01/datafiles/GWP01_CHG_BILL_GLOBAL_D_S_04.dbf";
}

SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_BTC_GDWHS_PUBLIC_I_S_03.dbf''
OFFLINE";
SWITCH DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_BTC_GDWHS_PUBLIC_I_S_03.dbf"
TO COPY;
RECOVER DATAFILE 1389;
SQL "ALTER DATABASE DATAFILE 1389 ONLINE";
DELETE NOPROMPT DATAFILECOPY
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_BTC_GDWHS_PUBLIC_I_S_03.dbf";
SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHD_D_01.dbf'' OFFLINE";
SWITCH DATAFILE "/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHD_D_01.dbf"
TO COPY;
RECOVER DATAFILE 35;
SQL "ALTER DATABASE DATAFILE 35 ONLINE";
DELETE NOPROMPT DATAFILECOPY
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHD_D_01.dbf";
SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_07.dbf''
OFFLINE";
SWITCH DATAFILE
"/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_07.dbf"
TO COPY;
RECOVER DATAFILE 68;
SQL "ALTER DATABASE DATAFILE 68 ONLINE";
DELETE NOPROMPT DATAFILECOPY
"/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_07.dbf";
SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_08.dbf''
OFFLINE";
SWITCH DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_08.dbf"
TO COPY;
RECOVER DATAFILE 70;
SQL "ALTER DATABASE DATAFILE 70 ONLINE";
DELETE NOPROMPT DATAFILECOPY
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_08.dbf";
SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_09.dbf''
OFFLINE";
SWITCH DATAFILE
"/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_09.dbf"
TO COPY;
RECOVER DATAFILE 71;
SQL "ALTER DATABASE DATAFILE 71 ONLINE";
DELETE NOPROMPT DATAFILECOPY
"/oracle/GWP01/datafiles1/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_09.dbf";
SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_10.dbf''
OFFLINE";
SWITCH DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_10.dbf"
TO COPY;
RECOVER DATAFILE 72;
SQL "ALTER DATABASE DATAFILE 72 ONLINE";
DELETE NOPROMPT DATAFILECOPY
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_10.dbf";
SQL "ALTER DATABASE DATAFILE
''/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_01.dbf''
OFFLINE";
SWITCH DATAFILE
"/oracle/GWP01/datafiles3/oradata/GWP01/GWP01_CHG_BILL_GLOBAL_D_S_01.dbf"
TO COPY;
RECOVER DATAFILE 107;
SQL "ALTER DATABASE DATAFILE 

[oracle_br] Replicação usando EMC Recoverpoint

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Boa noite pessoal.

Alguém por acaso já trabalhou com Recoverpoint e Oracle?

Confesso que essa foi a primeira vez que vi essa tecnologia e estou
encontrando alguma dificuldade para colocar isso rodando.

Bom, basicamente.

Há a necessidade de se construir um ambiente de failover entre 2
datacenters diferentes.

A tecnologia escolhida foi essa EMC Recoverpoint. Basicamente, ele faz uma
cópia a nível de blocos dos discos, e a replicação é feita de forma online.

Essencialmente, vc tem um espelho no seu ambiente secundário do(s) disco(s)
do seu ambiente primário.

Não consegui encontrar muita coisa sobre isso (ao menos, nem um documento
um pouco mais técnico).

Os discos foram replicados corretamente. Eu consigo montar todos meus
discos no ASM. Pelo asmcmd consigo ver todos os arquivos de meus bancos;
datafiles, redos, archives, etc.

No entanto, o banco não abre.

Essenciamente, como todos os arquivos estão lá, incluindo controlfile e
spfile que são identicos (mesmos arquivos) que em meu primeiro ambiente, ao
rodar um startup, o oracle deveria fazer o recover de meu banco para o SCN
mais recente e, em seguida, abrir o banco.

Idêntico a quando o banco pára abruptamente, como em um shutdown abort, ou
como quando alguém puxa o cabo de energia do servidor. :o)

Ao invés disso, o que tenho é isso:


SQL> startup
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 4275781632 bytes
Fixed Size  2260088 bytes
Variable Size1040188296 bytes
Database Buffers 3204448256 bytes
Redo Buffers   28884992 bytes
Database mounted.
ORA-01122: database file 9 failed verification check
ORA-01110: data file 9: '+DATA/cossqa/datafile/cossglobal_data.271.881415985'
ORA-01207: file is more recent than control file - old control file



Espero que alguém possa me ajudar com isso.

Eu realmente gostaria de não precisar de nada do servidor primário no
momento do startup do meu failover. Imaginando a situação de SER UM
FAILOVER e eu posso não ter acesso ao ambiente primário :D

Após isso, eu tentei um recover e, de fato, fiz o recover manualmente até
um ponto em que nada era mostrado na v$recover_file.

Após isso, o que eu tive foi isso:

Procurando no metalink por esse ora-600 em especifico, identifiquei que é
justamente por causa da diferença do SCN. Só que, olhando nos parâmetros do
ora-600 esse primeiro [2207] seria o SCN em que se encontra o banco, e o
segundo [2207] seria o SCN esperado para que o banco pudesse abrir
(???).. é...

SQL> startup
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 4275781632 bytes
Fixed Size  2260088 bytes
Variable Size1040188296 bytes
Database Buffers 3204448256 bytes
Redo Buffers   28884992 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [2207], [95699000], [2207],
[95869976], [8491572], [], [], [], [], [], []
Process ID: 51580


Idéias são muito bem vindas ...

Grande abraço.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com

Re: [oracle_br] Re: commit não persiste

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Alessandro, eu gostaria de adicionar mais alguma coisa a essa discussão.

No caso de transações distribuidas é importante dizer que, os SCN são
sincronizados sempre no inicio e fim de cada transação.

É um comportamento conhecido e EXISTEM gaps entre ambos bancos, Local e
Remoto.

A documentação da Oracle diz que é possível acontecer gaps devido a essa
dessincronia do SCN. Assim, se você executar um select a uma tabela remota
a partir de uma segunda sessão, você pode estar selecionando dados antigos,
mesmo após executar o commit na sua sessão principal.

Pode acontecer de, após você rodar e execução na sua segunda sessão, os
dados atualizados não aparecerem e, após alguns segundos, esses dados
estarem lá pois a soncronia do scn já foi feita.

Existem alguns workarounds que vc pode tentar:

Tenha em mente que as SCN são sincronizadas sempre no inicio e no fim de
cada transação, então:

1. Execute um commit APÓS o seu bloco plsql que está executando o update (E
não apenas um commit dentro do corpo do bloco.
2. Execute um commit ANTES de executar seu select na sua segunda sessão.
3. Faça um select dummy para o banco remoto antes de seu select de fato,
(ex: SELECT * FROM DUAL@REMOTE)

Esse comportamento é descrito na documentação do oracle:

http://docs.oracle.com/cd/B19306_01/server.102/b14231/ds_txnman.htm#i1008473

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 11 de junho de 2015 14:42, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> nah, se tem uma coisa que se pode confiar num RDBMS (e principalmente no
> RDBMS Oracle) é no ACID, que DEMANDA que as operações sejam
> permanentes/duráveis, isso é a letra D da sigla : pode ESQUECER a chance de
> um COMMIT que só vale pra sessão, e/ou que é desfeito depois de executado,
> essas coisas violariam GRANDÃO o princípio mais básico dos RDBMSs...
>  Com 99,% de certeza podemos dizer que vc tem galho é no seu ambiente
> - entre as opções mais comuns que podem estar acontecendo aí, eu cito :
>
>  a. a tool cliente que vc está usando está transparentemente metendo algum
> tipo de SAVEPOINT ou de flashback/SCN point , fazendo a sessão que faz a
> consulta enxergar os dados num momento no tempo antes da execução da
> procedure
>
>  ou
>
>  b. as sessões estão conectadas a usuários diferentes, que (por causa de
> sinônimos diferentes existentes) estão enxergando objetos diferentes
>
>  ou
>
>  c.  o código do procedure é mais complexo do que o mostrado, e escondido
> nalgum ponto vc tem uma EXCEPTION mascarando o eventual erro que impede o
> DELETE de acontecer, E/OU algum alter session causando um AUTONOMOUS
> TRANSACTION nesse código, coisas assim
>
>  ou
>
>  d. os dados que vc vê no SELECT da outra sessão foram RE-INSERIDOS no
> intervalo de tempo entre o término da execução da procedure e a execução da
> consulta na outra sessão : digamos, vc tem TRIGGERs e/ou código recursivo
> do tipo lá no database-destino que está fazendo o INSERT, ou mesmo tem
> outras pessoas nesse ambiente fazendo DMLs na tabela em questão
>
>  e derivados
>
>  O seu teste vai ser : usando sqlplus (que é a tool cliente mais básica
> possível, essa temos certeza que não faz NADA de mais nas sessões que cria)
> vc escrever uma procedure o mais enxuta possível, *** SEM *** nenhuma
> EXCEPTION nem DDL nem PRAGMA e APENAS e TÃO SOMENTE com o DELETE, COMMIT e
> SELECT COUNT (bem básica)...
>   DEPOIS de ter confirmado com 100% de certeza que não há triggers nem SQL
> recursivo/interno do tipo entrando em ação (isso é crítico!!), que não há
> outras sessões que possam inserir os dados que vc acabou de deletar na
> procedure (bloqueando o acesso a tabela em questão para as outras sessões
> que não aquelas onde vc executará a proc e aquela onde vc fará a consulta,
> como puder - isso Evitará acessos concorrentes/re-inserção), e que AMBAS as
> sessões sqlplus estão enxergando EXATAMENTE os mesmos objetos em exatamente
> os MESMOS SCHEMAS, aí sim numa das sessões sqlplus  execute a proc e na
> outra faça o SELECT
>
>   []s
>
> Chiappa
>
>  
>

Re: [oracle_br] Re: Usando o FORALL

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Calma gente.

O FORALL é sim muito rápido, no entanto, vc precisa de uma collection para
ele funcionar.

Só que você carregou essa collection usando um cursor implícito (for r in
select ...)

Não estou dizendo que é errado, no entanto, você poderia carregar o seu
collection usando a operação BULK COLLECT INTO, mantendo seu código enxuto.

Assim:

Select col1, col2, col3, col4
BULK COLLECT INTO meu_array LIMIT 1000
from table1, table2, ..

FORALL i in meu_array.FIRST .. meu_array.LAST
insert etc, etc, etc;

commit;

Isso iria enxugar muito seu código e iria ganhar um tempo no carregamento
de seu collection para memória.






Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 6 de março de 2015 04:17, lmarinh...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Obrigado pela dica. Só mais uma dúvida não são visão o BULK COLLECT INTO
> é mais rápido do que o FORALL?
>
>
> Luiz Marinho
>
>  
>

Re: [oracle_br] Usando o FORALL

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Sobre uma melhorada no código.

De uma pesquisada sobre a operação BULK COLLECT INTO.

Iria facilitar sua vida ;)

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


2015-03-05 14:44 GMT-03:00 Evandro Giachetto :

> Cara... Bom, vou me ater ao erro e não à qualidade do código, blza?
>
> Se precisar de um help pra dar uma melhorada no código, estamos por aqui.
>
>
> Aparentemente o erro está nessa linha:
>
> a_rec(v_idx).SRC_CD_OPRT_ORGN := r.SRC_CD_OPRT_ORGN;
>
> Você faz uma referência a seu cursor "r", porém, não existe essa coluna no
> seu cursor, simplesmente pq você não definiu o nome da coluna no select
> (que será o nome do campo de seu cursor).
>
> Nessa parte aqui:
>
> CASE
>
>   WHEN DIR_TRAFEGO = 'Outgoing' or large_account is not null
> then '63102' -- Angola
>
>   WHEN DIR_TRAFEGO = 'Incoming' or DIR_TRAFEGO = 'Forwarding'
> then
>
>
>  nvl(pais_orig||operador,nvl(ID_TRF_TRMN_PONT,-1))
>
>   Else '-1'
>
> END,--SRC_CD_OPRT_ORGN
>
>
> Substitua por
>
>
> CASE
>
>   WHEN DIR_TRAFEGO = 'Outgoing' or large_account is not null
> then '63102' -- Angola
>
>   WHEN DIR_TRAFEGO = 'Incoming' or DIR_TRAFEGO = 'Forwarding'
> then
>
>
>  nvl(pais_orig||operador,nvl(ID_TRF_TRMN_PONT,-1))
>
>   Else '-1'
>
> END as SRC_CD_OPRT_ORGN,--SRC_CD_OPRT_ORGN
>
>
> Isso vale para os outros erros mostrados.
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
>
> 2015-03-05 14:35 GMT-03:00 lmarinh...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br>:
>
>
>>
>> Olá Galera,
>>
>> Estou obtendo um erro bobo aqui que não estou conseguindo ver. Esta dando
>> erro que eu devo declarar algumas variáveis e as mesmas esta declaradas. O
>> Código abaixo
>>
>>
>> DECLARE
>>
>>   t0 number := dbms_utility.get_time;
>>
>>   v_idx number :=1;
>>
>>   type t_rec is record(
>>
>>   SRC_DT_CALL   NUMBER,
>>
>>   SRC_TM_CALL   VARCHAR2(30),
>>
>>   SRC_CD_BNSS_UNIT  VARCHAR2(30),
>>
>>   SRC_CD_CALL_AREA  VARCHAR2(30),
>>
>>   SRC_CD_NTWK_ELMT  VARCHAR2(30),
>>
>>   SRC_CD_OPRT_ORGN  VARCHAR2(30),
>>
>>   SRC_CD_OPRT_DSTN  VARCHAR2(30),
>>
>>   SRC_CD_PDSV   VARCHAR2(30),
>>
>>   SRC_CD_SBSC   VARCHAR2(30),
>>
>>   SRC_CD_PRCN_PLAN  VARCHAR2(30),
>>
>>   SRC_CD_TRF_WAYVARCHAR2(30),
>>
>>   SRC_CD_TRF_TYPE   VARCHAR2(30),
>>
>>   SRC_CD_TRF_SUB_TYPE   VARCHAR2 (30),
>>
>>   SRC_CD_TRF_NTWK   VARCHAR2 (30),
>>
>>   SRC_CD_TRF_RMNG_TYPE  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_PERD_TYPE  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_CHRG_CALL  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_LINE_TYPE  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_TRMN_PONT  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_DROP_CALL  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_HOME_ZONE  VARCHAR2 (30),
>>
>>   SRC_CD_TRF_TCNL   VARCHAR2 (30),
>>
>>   SRC_CD_FIN_BLNC_TYPE  VARCHAR2 (30),
>>
>>   SRC_CD_PAY_TYPE   VARCHAR2 (30),
>>
>>   SRC_CD_EQPM_MODL  VARCHAR2 (30),
>>
>>   SRC_NR_ORGN   VARCHAR2 (30),
>>
>>   SRC_NR_DSTN   VARCHAR2 (30),
>>
>>   SRC_QT_DRTN_TRFC  NUMBER   (22),
>>
>>   SRC_QT_CHRG_DRTN_TRFC NUMBER   (22),
>>
>>   SRC_QT_UPLD_TRFC  NUMBER   (22),
>>
>>   SRC_QT_DWLD_TRFC  NUMBER   (22),
>>
>>   SRC_VL_TRFC   NUMBER   (22),
>>
>>   SRC_VL_BLNC_USED  NUMBER   (22),
>>
>>   X_VL_TRFC_UTT NUMBER   (22),
>>
>>   X_VL_TRFC_USD NUMBER   (22),
>>
>>   V_TIMESTAMP date,
>>
>>   X_CD_GLOB_CALL_REFVARCHAR2 (30),
>>
>>   X_FL_RMNG NUMBER   (22),
>>
>>   SRC_CD_TRF_CHRG_TYPE  number(22),
>>
>>   X_CD_MCC_ROAM number(22),
>>
>>   X_CD_MNC_ROAM number(22),
>>
>>   X_QT_DRTN_TRFC_FREE   NUMBER   (22),
>>
>>   X_CD_FAF  NUMBER   (22),
>>
>>   X_DS_SRC_SYST VARCHAR2 (30),
>>
>>   X_VL_PRVS_BLNCNUMBER   (22),
>>
>>   X_VL_BLNC NUMBER   (22),
>>
>>   X_QT_TOTL_DATA_TRFC   NUMBER   (22),
>>
>>   X_CD_SRCE_FILENUMBER   (22),
>>
>>   NSEQ_TRF  NUMBER(22),
>>
>>   X_CD_SERV_CLSSNUMBER   (22));
>>
>>   type t_rec_array is table of t_rec index by pls_integer;
>>
>>   a_rec t_rec_array;
>>
>>BEGIN
>>
>> for r in(SELECT SUBSTR(A.DATA_EVENTO,1,8)AS
>> SRC_DT_CALL,SUBSTR(A.DATA_EVENTO,9,6)AS SRC_TM_CALL,-1 AS
>

Re: [oracle_br] Usando o FORALL

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Cara... Bom, vou me ater ao erro e não à qualidade do código, blza?

Se precisar de um help pra dar uma melhorada no código, estamos por aqui.


Aparentemente o erro está nessa linha:

a_rec(v_idx).SRC_CD_OPRT_ORGN := r.SRC_CD_OPRT_ORGN;

Você faz uma referência a seu cursor "r", porém, não existe essa coluna no
seu cursor, simplesmente pq você não definiu o nome da coluna no select
(que será o nome do campo de seu cursor).

Nessa parte aqui:

CASE

  WHEN DIR_TRAFEGO = 'Outgoing' or large_account is not null
then '63102' -- Angola

  WHEN DIR_TRAFEGO = 'Incoming' or DIR_TRAFEGO = 'Forwarding'
then


 nvl(pais_orig||operador,nvl(ID_TRF_TRMN_PONT,-1))

  Else '-1'

END,--SRC_CD_OPRT_ORGN


Substitua por


CASE

  WHEN DIR_TRAFEGO = 'Outgoing' or large_account is not null
then '63102' -- Angola

  WHEN DIR_TRAFEGO = 'Incoming' or DIR_TRAFEGO = 'Forwarding'
then


 nvl(pais_orig||operador,nvl(ID_TRF_TRMN_PONT,-1))

  Else '-1'

END as SRC_CD_OPRT_ORGN,--SRC_CD_OPRT_ORGN


Isso vale para os outros erros mostrados.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


2015-03-05 14:35 GMT-03:00 lmarinh...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Olá Galera,
>
> Estou obtendo um erro bobo aqui que não estou conseguindo ver. Esta dando
> erro que eu devo declarar algumas variáveis e as mesmas esta declaradas. O
> Código abaixo
>
>
> DECLARE
>
>   t0 number := dbms_utility.get_time;
>
>   v_idx number :=1;
>
>   type t_rec is record(
>
>   SRC_DT_CALL   NUMBER,
>
>   SRC_TM_CALL   VARCHAR2(30),
>
>   SRC_CD_BNSS_UNIT  VARCHAR2(30),
>
>   SRC_CD_CALL_AREA  VARCHAR2(30),
>
>   SRC_CD_NTWK_ELMT  VARCHAR2(30),
>
>   SRC_CD_OPRT_ORGN  VARCHAR2(30),
>
>   SRC_CD_OPRT_DSTN  VARCHAR2(30),
>
>   SRC_CD_PDSV   VARCHAR2(30),
>
>   SRC_CD_SBSC   VARCHAR2(30),
>
>   SRC_CD_PRCN_PLAN  VARCHAR2(30),
>
>   SRC_CD_TRF_WAYVARCHAR2(30),
>
>   SRC_CD_TRF_TYPE   VARCHAR2(30),
>
>   SRC_CD_TRF_SUB_TYPE   VARCHAR2 (30),
>
>   SRC_CD_TRF_NTWK   VARCHAR2 (30),
>
>   SRC_CD_TRF_RMNG_TYPE  VARCHAR2 (30),
>
>   SRC_CD_TRF_PERD_TYPE  VARCHAR2 (30),
>
>   SRC_CD_TRF_CHRG_CALL  VARCHAR2 (30),
>
>   SRC_CD_TRF_LINE_TYPE  VARCHAR2 (30),
>
>   SRC_CD_TRF_TRMN_PONT  VARCHAR2 (30),
>
>   SRC_CD_TRF_DROP_CALL  VARCHAR2 (30),
>
>   SRC_CD_TRF_HOME_ZONE  VARCHAR2 (30),
>
>   SRC_CD_TRF_TCNL   VARCHAR2 (30),
>
>   SRC_CD_FIN_BLNC_TYPE  VARCHAR2 (30),
>
>   SRC_CD_PAY_TYPE   VARCHAR2 (30),
>
>   SRC_CD_EQPM_MODL  VARCHAR2 (30),
>
>   SRC_NR_ORGN   VARCHAR2 (30),
>
>   SRC_NR_DSTN   VARCHAR2 (30),
>
>   SRC_QT_DRTN_TRFC  NUMBER   (22),
>
>   SRC_QT_CHRG_DRTN_TRFC NUMBER   (22),
>
>   SRC_QT_UPLD_TRFC  NUMBER   (22),
>
>   SRC_QT_DWLD_TRFC  NUMBER   (22),
>
>   SRC_VL_TRFC   NUMBER   (22),
>
>   SRC_VL_BLNC_USED  NUMBER   (22),
>
>   X_VL_TRFC_UTT NUMBER   (22),
>
>   X_VL_TRFC_USD NUMBER   (22),
>
>   V_TIMESTAMP date,
>
>   X_CD_GLOB_CALL_REFVARCHAR2 (30),
>
>   X_FL_RMNG NUMBER   (22),
>
>   SRC_CD_TRF_CHRG_TYPE  number(22),
>
>   X_CD_MCC_ROAM number(22),
>
>   X_CD_MNC_ROAM number(22),
>
>   X_QT_DRTN_TRFC_FREE   NUMBER   (22),
>
>   X_CD_FAF  NUMBER   (22),
>
>   X_DS_SRC_SYST VARCHAR2 (30),
>
>   X_VL_PRVS_BLNCNUMBER   (22),
>
>   X_VL_BLNC NUMBER   (22),
>
>   X_QT_TOTL_DATA_TRFC   NUMBER   (22),
>
>   X_CD_SRCE_FILENUMBER   (22),
>
>   NSEQ_TRF  NUMBER(22),
>
>   X_CD_SERV_CLSSNUMBER   (22));
>
>   type t_rec_array is table of t_rec index by pls_integer;
>
>   a_rec t_rec_array;
>
>BEGIN
>
> for r in(SELECT SUBSTR(A.DATA_EVENTO,1,8)AS
> SRC_DT_CALL,SUBSTR(A.DATA_EVENTO,9,6)AS SRC_TM_CALL,-1 AS
> SRC_CD_BNSS_UNIT,-1 AS SRC_CD_CALL_AREA,nvl(ID_CELULA,-1) AS
> SRC_CD_NTWK_ELMT,
>
> CASE
>
>   WHEN DIR_TRAFEGO = 'Outgoing' or large_account is not null
> then '63102' -- Angola
>
>   WHEN DIR_TRAFEGO = 'Incoming' or DIR_TRAFEGO = 'Forwarding'
> then
>
>
>  nvl(pais_orig||operador,nvl(ID_TRF_TRMN_PONT,-1))
>
>   Else '-1'
>
> END,--SRC_CD_OPRT_ORGN
>

Re: [oracle_br] Meu novo/velho BLOG, por José Lauri ndo Chiappa

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Chiappa, se me permite uma sugestão.

Pq você não dá inicio num esquema parecido com o que o Tom Kite faz, no
asktom.oracle.com ?

Digo isso pq, é muito raro um guru Brasileiro. Eu tive a felicidade de
trabalhar com um, o Marcelo Laurenti, dono do blog "Had to fail" (
http://marcelolaurenti.blogspot.com.br/) e acompanho seus posts aqui no
grupo e não tem como não elogiar a maneira como você aborda a quase todas
as perguntas do grupo de forma muito didática e até paciente (rss)

Eu creio que seria muito bom, já que não conheço uma ferramenta do tipo em
português e também criaria uma base de conhecimento centralizada na web,
totalmente em português em dinâmica, que cresceria conforme as dúvidas
respondidas diretamente no blog.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 12 de fevereiro de 2015 16:40, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Agradeço muito as palavras gentis , e como eu disse, é um início modesto
> mas ao menos eu iniciei, depois de (literalmente) anos  de enrolação...
>
>  []s
>
>   Chiappa
>  
>

Re: [oracle_br] Sub Query

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

select 1 mesmo
ou select null.
O importante é a query retornar algum valor.
* tbm funciona, mas você vai foçar dados que não vai usar pra memória, o
que não é interessante.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 3 de fevereiro de 2015 17:22, Emerson Sanches emerson.sanc...@gmail.com
[oracle_br]  escreveu:

>
>
> Acho que voce matou Evandro. Só uma duvida, no 1 exemplo a sintaxe é where
> exists (select 1 from ou .where exists (select * from?
>
> Muito obrigado.
>
> Emerson Sanches
> Analista de Sistemas
>
> Em 3 de fevereiro de 2015 16:55, Evandro Giachetto
> evandrogiache...@gmail.com [oracle_br] 
> escreveu:
>
>>
>>
>> Não sei se entendi muito bem sua dúvida, se não, peço desculpas.
>>
>> Tente algo do tipo:
>>
>>
>> Select *
>> from Mestre
>> where exists (select 1 from Detalhe
>>  where  Detalhe.NumNota = 
>> Mestre.NumNota
>> and Detalhe.Serie = Mestre.Serie and Detalhe.Fornecedor =
>> Mestre.Fornecedor and Detalhe.TipoMovto = Mestre.TipoMovto and Detalhe.Item
>> = &item).
>>
>> Ou
>>
>> Select *
>> from Mestre
>> where (NumNota, Serie, Fornecedor, TipoMovto) in (select NumNota, Serie,
>> Fornecedor, TipoMovto from Detalhe where Item = &item);
>>
>>
>> Só lembrando.
>>
>> Por questão de performance.
>>
>> Se seu Subselect (select ... from Detalhe where Item = %Item) trouxer um
>> número pequeno de dados, então o segundo exemplo deve exectuar mais rápido.
>>
>> Se por ventura, este subselect trouxer um número muito grande de
>> resultados, então a primeira opção deve apresentar uma performance melhor.
>>
>> Se a quantidade de resultados for balanceada entre as duas queries, então
>> as duas opções devem mostrar performance semelhante.
>>
>>
>> Evandro Giachetto
>> Oracle DBA
>> evandrogiache...@gmail.com
>>
>>
>> Em 3 de fevereiro de 2015 16:41, Emerson Sanches
>> emerson.sanc...@gmail.com [oracle_br] 
>> escreveu:
>>
>>
>>>
>>> Bom tarde a todos do grupo. Em meu sistema tenho uma tabela de NF cuja
>>> chave primaria são os campos NumNota, Serie, Fornecedor, TipoMovto e outra
>>> tabela com os detalhes dessa nota com chave primaria composta por NumNota,
>>> Serie, Fornecedor, TipoMovto e Item. Ate tudo normalíssimo, acredito que
>>> todos tenham uma normalização desse tipo em seus sistemas.
>>> O problema é que meu chefe quer que eu faça uma pesquisa de notas
>>> fiscais, mas quer ter como parâmetro de busca o item da nota fiscal, ou
>>> seja, ele quer pesquisar pelo código de entrada do produto. Para resolver
>>> isso fiz um subquery assim:
>>>
>>> Select *
>>> from Mestre
>>> where  Mestre.NumNota in (Select  Detalhe.NumNota
>>>  fromDetalhe
>>>  where  Detalhe.Item = &item)
>>>
>>>
>>> Essa solução funciona parcialmente, pois vai me trazer a nota do item
>>> pesquisado, mas também vai trazer a nota de outro fornecedor qualquer, que
>>> tenha uma nota com o mesmo numero cadastrado no sistema. Para resolver isso
>>> eu teria que passar no subquery todos o campos da PK da tabela Mestre, e é
>>> exatamente isso que não sei como fazer. Se alguém tiver alguma sugestão,
>>> todas serão bem vindas.
>>>
>>> Obrigado
>>>
>>>
>>>
>>> Emerson Sanches
>>>
>>>
>>
>  
>

Re: [oracle_br] Sub Query

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Não sei se entendi muito bem sua dúvida, se não, peço desculpas.

Tente algo do tipo:


Select *
from Mestre
where exists (select 1 from Detalhe
 where  Detalhe.NumNota =
Mestre.NumNota
and Detalhe.Serie = Mestre.Serie and Detalhe.Fornecedor = Mestre.Fornecedor
and Detalhe.TipoMovto = Mestre.TipoMovto and Detalhe.Item = &item).

Ou

Select *
from Mestre
where (NumNota, Serie, Fornecedor, TipoMovto) in (select NumNota, Serie,
Fornecedor, TipoMovto from Detalhe where Item = &item);


Só lembrando.

Por questão de performance.

Se seu Subselect (select ... from Detalhe where Item = %Item) trouxer um
número pequeno de dados, então o segundo exemplo deve exectuar mais rápido.

Se por ventura, este subselect trouxer um número muito grande de
resultados, então a primeira opção deve apresentar uma performance melhor.

Se a quantidade de resultados for balanceada entre as duas queries, então
as duas opções devem mostrar performance semelhante.


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 3 de fevereiro de 2015 16:41, Emerson Sanches emerson.sanc...@gmail.com
[oracle_br]  escreveu:

>
>
> Bom tarde a todos do grupo. Em meu sistema tenho uma tabela de NF cuja
> chave primaria são os campos NumNota, Serie, Fornecedor, TipoMovto e outra
> tabela com os detalhes dessa nota com chave primaria composta por NumNota,
> Serie, Fornecedor, TipoMovto e Item. Ate tudo normalíssimo, acredito que
> todos tenham uma normalização desse tipo em seus sistemas.
> O problema é que meu chefe quer que eu faça uma pesquisa de notas fiscais,
> mas quer ter como parâmetro de busca o item da nota fiscal, ou seja, ele
> quer pesquisar pelo código de entrada do produto. Para resolver isso fiz um
> subquery assim:
>
> Select *
> from Mestre
> where  Mestre.NumNota in (Select  Detalhe.NumNota
>  fromDetalhe
>  where  Detalhe.Item = &item)
>
>
> Essa solução funciona parcialmente, pois vai me trazer a nota do item
> pesquisado, mas também vai trazer a nota de outro fornecedor qualquer, que
> tenha uma nota com o mesmo numero cadastrado no sistema. Para resolver isso
> eu teria que passar no subquery todos o campos da PK da tabela Mestre, e é
> exatamente isso que não sei como fazer. Se alguém tiver alguma sugestão,
> todas serão bem vindas.
>
> Obrigado
>
>
>
> Emerson Sanches
>
>  
>

Re: [oracle_br] EXPDP EXCLUDE

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Supondo, obviamente, que seu user system tem permissão de exportar outros
schemas.

Caso contrário, tente usar o próprio usuário que você quer exportar para se
conectar ao expdp, ou utilize sysdba

vi export.par
#param file
EXCLUDE=TABLE:"LIKE 'SMW%' "

$ expdp MASTER/** directory=EXPORT dumpfile=EXP_MASTER.dmp
logfile=EXP_MASTER.log parfile=export.par



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 27 de janeiro de 2015 10:45, Evandro Giachetto <
evandrogiache...@gmail.com> escreveu:

> Bom dia Ednilson.
>
> Me parece correto seu comando.
>
> A sintaxe do EXCLUDE ficaria mais ou menos assim:
>
> EXCLUDE=TABLE:"LIKE 'SMW%' "
>
> Note que o 'SMW%' está entre aspas simples.
>
> No entanto, você não pode passar acentos diretamente através do shell no
> linux, devendo incluir um \ antes de cada ' e "
>
> Para facilitar, coloque a cláusula EXCLUDE dentro de um arquivo de
> parametros e utilize o PARFILE no seu EXPDP, assim:
>
> vi export.par
> #param file
> EXCLUDE=TABLE:"LIKE 'SMW%' "
>
> $ expdp SYSTEM/sys123 SCHEMAS=MASTER directory=EXPORT
> dumpfile=EXP_MASTER.dmp logfile=EXP_MASTER.log parfile=export.par
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
>
> Em 27 de janeiro de 2015 10:35, 'Ednilson Silva' ednilson.si...@jbs.com.br
> [oracle_br]  escreveu:
>
>
>>
>> Bom Dia,
>>
>> Preciso fazer um EXPDP de um SCHEMA mas excluindo todas as tabelas SWM_%,
>> alguém poderia dar uma ajuda?
>>
>>
>>
>> Estou tentando da seguinte forma.
>>
>>
>>
>> $ expdp SYSTEM/sys123 SCHEMAS=MASTER directory=EXPORT
>> dumpfile=EXP_MASTER.dmp logfile=EXP_MASTER.log EXCLUDE=TABLE:"LIKE 'SMW_%'"
>>
>>
>>
>> Oracle Database 10g Enterprise Edition Release 10.2.0.5.0
>>
>>
>>
>> Grato,
>>
>> Ednilson
>>
>>  
>>
>
>

Re: [oracle_br] EXPDP EXCLUDE

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Bom dia Ednilson.

Me parece correto seu comando.

A sintaxe do EXCLUDE ficaria mais ou menos assim:

EXCLUDE=TABLE:"LIKE 'SMW%' "

Note que o 'SMW%' está entre aspas simples.

No entanto, você não pode passar acentos diretamente através do shell no
linux, devendo incluir um \ antes de cada ' e "

Para facilitar, coloque a cláusula EXCLUDE dentro de um arquivo de
parametros e utilize o PARFILE no seu EXPDP, assim:

vi export.par
#param file
EXCLUDE=TABLE:"LIKE 'SMW%' "

$ expdp SYSTEM/sys123 SCHEMAS=MASTER directory=EXPORT
dumpfile=EXP_MASTER.dmp logfile=EXP_MASTER.log parfile=export.par

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 27 de janeiro de 2015 10:35, 'Ednilson Silva' ednilson.si...@jbs.com.br
[oracle_br]  escreveu:

>
>
> Bom Dia,
>
> Preciso fazer um EXPDP de um SCHEMA mas excluindo todas as tabelas SWM_%,
> alguém poderia dar uma ajuda?
>
>
>
> Estou tentando da seguinte forma.
>
>
>
> $ expdp SYSTEM/sys123 SCHEMAS=MASTER directory=EXPORT
> dumpfile=EXP_MASTER.dmp logfile=EXP_MASTER.log EXCLUDE=TABLE:"LIKE 'SMW_%'"
>
>
>
> Oracle Database 10g Enterprise Edition Release 10.2.0.5.0
>
>
>
> Grato,
>
> Ednilson
>
>  
>

[oracle_br] Re: Uma ajuda com restore de TAPE

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Alguém ?

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 6 de janeiro de 2015 13:26, Evandro Giachetto  escreveu:

> Bom dia pessoal do grupo.
>
> Nunca tive problemas com backups pois até hoje sempre trabalhei com
> backups locais e uma cópia para Fita feita no nível de SO.
>
> Nesta empresa onde estou, o backup é feito diretamente para devices do
> tipo SBT e são armazenados na rede.
>
>
> Quando tento fazer um restore de um determinado datafile, ele diz que o
> arquivo é remoto (???)
>
> Alguém com mais experiência nesse tipo de ambiente poderia "dar uma luz" ?
>
> Obs: Oracle 10.2.0.4.0
>
> Este é o script que estou utilizando:
>
> connect target user/@database
> connect catalog ruser/@rcatalog
> RUN {
> ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
> ALLOCATE CHANNEL t2 DEVICE TYPE sbt;
>
> restore datafile 236;
> recover datafile 236;
>
> release channel t1;
> release channel t2;
> }
>
>
> List of remote backup files
> 
> Handle: GWP01_vvpr6s6a_1_1   Media: 002386
> released channel: t1
> RMAN-00571: ===
> RMAN-00569: === ERROR MESSAGE STACK FOLLOWS ===
> RMAN-00571: ===
> RMAN-03002: failure of restore command at 01/06/2015 15:22:23
> RMAN-20507: some targets are remote - aborting restore
>
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
>

[oracle_br] Uma ajuda com restore de TAPE

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Bom dia pessoal do grupo.

Nunca tive problemas com backups pois até hoje sempre trabalhei com backups
locais e uma cópia para Fita feita no nível de SO.

Nesta empresa onde estou, o backup é feito diretamente para devices do tipo
SBT e são armazenados na rede.


Quando tento fazer um restore de um determinado datafile, ele diz que o
arquivo é remoto (???)

Alguém com mais experiência nesse tipo de ambiente poderia "dar uma luz" ?

Obs: Oracle 10.2.0.4.0

Este é o script que estou utilizando:

connect target user/@database
connect catalog ruser/@rcatalog
RUN {
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
ALLOCATE CHANNEL t2 DEVICE TYPE sbt;

restore datafile 236;
recover datafile 236;

release channel t1;
release channel t2;
}


List of remote backup files

Handle: GWP01_vvpr6s6a_1_1   Media: 002386
released channel: t1
RMAN-00571: ===
RMAN-00569: === ERROR MESSAGE STACK FOLLOWS ===
RMAN-00571: ===
RMAN-03002: failure of restore command at 01/06/2015 15:22:23
RMAN-20507: some targets are remote - aborting restore


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com

Re: [oracle_br] Como matar uma sessão ?

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Não senhor.

É um ambiente 12c, num banco Pluggable.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 24 de novembro de 2014 17:00, Andre Santos andre.psantos...@gmail.com
[oracle_br]  escreveu:

>
>
> Evandro
>
> Está em ambiente RAC ?
> Se estiver, o kill session tem um terceiro parâmetro (opcional), para
> indicar em qual instância encontra-se a sessão.
>
> [ ]
>
> André
>
>
> 2014-11-24 16:43 GMT-02:00 Evandro Giachetto evandrogiache...@gmail.com
> [oracle_br] :
>
>
>>
>> Por favor, não riam da pergunta.
>>
>> Parece extremamente Newby e é, visto que estou iniciando neste exato
>> momento no ambiente 12c.
>>
>> Bom, basicamente:
>>
>> SQL> select SID,JOB,INSTANCE from dba_jobs_running;
>>
>>SIDJOB   INSTANCE
>> -- -- --
>>364 89  0
>>
>>
>> SQL> select a.sid||','||a.serial# from v$session a where a.sid=364;
>>
>> A.SID||','||A.SERIAL#
>>
>> -
>> 364,20413
>>
>>
>> SQL> alter system kill session '364,20413' immediate;
>> alter system kill session '364,20413' immediate
>> *
>> ERROR at line 1:
>> ORA-00026: missing or invalid session ID
>>
>>
>> Detalhes.
>>
>> Eu me conectei no banco Container e alterei a sessão para utilizar o
>> banco Pluggable, dessa forma:
>>
>> alter session set container=pdb;
>>
>> Evandro Giachetto
>> Oracle DBA
>> evandrogiache...@gmail.com
>>
>>
>  
>

Re: [oracle_br] Como matar uma sessão ?

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Eu também imaginei isso, mas se você olhar no número da instance, que
aparece na dba_jobs_running, verá que é 0 (?)

No impeto de matar a sessão eu olhei exatamente na v$instance, para qual
seria a INST_ID. Na v$INSTANCE o ID é 1.

Mas, mais tarde eu imaginei que esse id que aparece na v$instance
trataria-se da id do banco container, e não do pluggable.

Não tive tempo de testar com 0, pois o job terminou antes disso, e a sessão
foi finalizada.

Mas, fiquei com essa dúvida.

Se alguém souber como proceder, seria de grande valia.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 24 de novembro de 2014 17:02, Evandro Giachetto <
evandrogiache...@gmail.com> escreveu:

> Não senhor.
>
> É um ambiente 12c, num banco Pluggable.
>
> Evandro Giachetto
> Oracle DBA
> evandrogiache...@gmail.com
>
>
> Em 24 de novembro de 2014 17:00, Andre Santos andre.psantos...@gmail.com
> [oracle_br]  escreveu:
>
>
>>
>> Evandro
>>
>> Está em ambiente RAC ?
>> Se estiver, o kill session tem um terceiro parâmetro (opcional), para
>> indicar em qual instância encontra-se a sessão.
>>
>> [ ]
>>
>> André
>>
>>
>> 2014-11-24 16:43 GMT-02:00 Evandro Giachetto evandrogiache...@gmail.com
>> [oracle_br] :
>>
>>
>>>
>>> Por favor, não riam da pergunta.
>>>
>>> Parece extremamente Newby e é, visto que estou iniciando neste exato
>>> momento no ambiente 12c.
>>>
>>> Bom, basicamente:
>>>
>>> SQL> select SID,JOB,INSTANCE from dba_jobs_running;
>>>
>>>SIDJOB   INSTANCE
>>> -- -- --
>>>364 89  0
>>>
>>>
>>> SQL> select a.sid||','||a.serial# from v$session a where a.sid=364;
>>>
>>> A.SID||','||A.SERIAL#
>>>
>>> -
>>> 364,20413
>>>
>>>
>>> SQL> alter system kill session '364,20413' immediate;
>>> alter system kill session '364,20413' immediate
>>> *
>>> ERROR at line 1:
>>> ORA-00026: missing or invalid session ID
>>>
>>>
>>> Detalhes.
>>>
>>> Eu me conectei no banco Container e alterei a sessão para utilizar o
>>> banco Pluggable, dessa forma:
>>>
>>> alter session set container=pdb;
>>>
>>> Evandro Giachetto
>>> Oracle DBA
>>> evandrogiache...@gmail.com
>>>
>>>
>>  
>>
>
>

[oracle_br] Como matar uma sessão ?

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Por favor, não riam da pergunta.

Parece extremamente Newby e é, visto que estou iniciando neste exato
momento no ambiente 12c.

Bom, basicamente:

SQL> select SID,JOB,INSTANCE from dba_jobs_running;

   SIDJOB   INSTANCE
-- -- --
   364 89  0


SQL> select a.sid||','||a.serial# from v$session a where a.sid=364;

A.SID||','||A.SERIAL#
-
364,20413


SQL> alter system kill session '364,20413' immediate;
alter system kill session '364,20413' immediate
*
ERROR at line 1:
ORA-00026: missing or invalid session ID


Detalhes.

Eu me conectei no banco Container e alterei a sessão para utilizar o banco
Pluggable, dessa forma:

alter session set container=pdb;

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com

Re: [oracle_br] Re: Ajuda com Characteres Chineses

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Sim senhor.

No entanto, eu descobri onde estava o problema.

O Windows, pelomenos aqui, por padrão salva os arquivos texto como UNICODE.

Simplesmente fiz a conversão do arquivo .txt no windows para UTF-8 usando o
notepad++.

Agora sim. Ao enviar o arquivo por sftp ele não quebrou.

O VI (que é um aliás para o VIM em distribuições mais novas de linux) tem
suporte para UNICODE. Por isso eu conseguia ver os caracteres chineses
quando abria por ele.

Ao converter o arquivo para UTF-8 desde o principio, tudo funcionou
normalmente pois, obviamente, meu linux está trabalhando em UTF-16, que é
possível fazer a conversão/ou é compatível com UTF-8.

Assim, consegui carregar tudo, criar a tabela externa e fazer select nos
char chineses normalmente.


Valeu pela ajuda aí pessoal.

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 24 de setembro de 2014 09:43, ederson200...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Só um palpite: quando vc faz o scp, vc tá especificando BIN? é que pode
> ser que tá subindo ASCI e daí acontece uma certa conversão que pode ser a
> causa dos caracteres se perderem (filtro).
>
>
> Ederson Elias
> DBA Oracle - http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
>  Labor improbus omnia vincit
>  
>

Re: [oracle_br] Re: Ajuda com Characteres Chineses

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Oi Chiappa. Mais uma vez, obrigado por sua resposta.

Os Charset que estou usando, conforme meu ultimo e-mail:

NLS_CHARACTERSET   WE8ISO8859P1
NLS_NCHAR_CHARACTERSET AL16UTF16


Depois de algum trabalho ontem eu percebi que o problema está na hora de
copiar o arquivo txt que irá alimentar minha tabela externa do windows para
o linux.

O desenvolvedor estava enviando pelos utilitários scp e psftp, no entanto,
em ambos os casos, ao ser copiado para o linux, o arquivo foi quebrado
(Caracteres se perderam).

Logando via ssh no servidor linux, e criando um arquivo com o utilitário
VI, colando o texto do arquivo, funcionou perfeitamente.


Eu realmente não tenho muita experiência em trabalhar com caracteres
diferentes do que usamos habitualmente, portanto, estou um pouco perdido.


as Var de ambiente do meu Linux são:

oragwp01@lxdwprddb01>env | grep NLS
NLS_SORT=BINARY
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
NLS_DATE_LANGUAGE=AMERICAN
NLS_NUMERIC_CHARACTER=.,
ORA_NLS33=/oracle/GWP01/home/server/10.2.0/ocommon/nls/admin/data
NLS_DATE_FORMAT=DD-MON-RR


Seria necessário setar essas mesmas variáveis no ambiente windows do qual
estou acessando via sftp para transferencia do arquivo?



*O que não funcionou:*

Enviar o arquivo via PSFTP ou SCP.
  *Ao dar um cat os caracteres se perdem. Ao ler o arquivo com VI é
possível ver os caracteres em chines normalmente.


*O que funcionou:*

Criar um novo arquivo diretamente no servidor linux através de ssh, usando
o VI e colando o texto do arquivo lá.
  *Tanto ao dar cat quanto ao ler o arquivo com VI os caracteres chineses
funcionam.
  *A tabela externa carregou o conteúdo do arquivo perfeitamente, exibindo
os caracteres em chinês ao fazermos select nela.




Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com


Em 23 de setembro de 2014 18:19, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
>   Sorry, mas não é só uma questão de "variáveis" : além disso, outro ponto
> aí é que o database possui um conjunto de caracteres próprio instalado, que
> é usado para a exibição : Óbvio ululante que se o conjunto de caracters
> (characterset) em uso não conter todos os caracteres chineses que vc
> precisa, vc VAI ter perda/conversão de caracter aí, né não ???
>Os dois conjuntos de caracter que o database Oracle pode ter são o
> principal (o NLS_CHARACTERSET, que é usado para as string VARCHAR e CHAR) e
> o conjunto NCHAR (o NLS_NCHAR_CHARACTERSET), que é usado para as strings de
> datatype NCHAR : como estão esses dois no seu database ?? Vc os vê
> consultando a nls_database_parameters ... A questão aqui é que, como
> Sabemos, os alfabetos asiáticos possuem mais de 255 caracteres possíveis,
> então só um byte não dá pra representar tudo, vc TEM que estar usando um
> conjunto de caracteres que use mais de um byte para representar cada
> caracter, normalmente adota-se o UNICODE, cfrme
> https://asktom.oracle.com/pls/asktom/f?p=100:11:0P11_QUESTION_ID:10250420313043
> mostra - outros são possíveis (cfrme
> http://en.wikipedia.org/wiki/Chinese_character_encoding), mas a tendência
> é mesmo UNICODE.. Um dos dois charactersets TEM que ser multibyte, seja o
> default (se vc usar char/varchar) seja o nchar, se vc usar colunas NCHAR
> Isso ok, aí é setar o Sistema Operacional, instalando as fontes de
> exibição necessárias e fazendo os ajustes de linguagem necessários, ajustar
> o teu software de terminal se tem algum em uso (a maioria deles, como o
> putty, possui opção de conjunto de caracteres a utilizar), e só DEPOIS
> disso setar as variáveis NLS : imagino que a mais importante vai ser a de
> characterset apontando para a versão de UNICODE que vc esteja usando...
>
>  []s
>
>Chiappa
>  
>

[oracle_br] Ajuda com Characteres Chineses

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Boa tarde grupo.

Gostaria da ajuda de vocês, em especial dos mais experientes em Linux,
quanto à exibição de caracteres em Chinês.

O problema é o seguinte:

Surgiu uma solicitação do time de desenvolvimento para fosse criada uma
tabela externa a partir de um arquivo csv que já foi transferido para o
servidor.

O problema é que esse arquivo contem tanto texto em Ingles quanto texto em
Chinês.

Ao criar a tabela externa, os caracteres em chinês não são exibidos da
forma correta.

O interessante é que, se eu abrir o arquivo com o VI, os caracteres são
exibidos normalmente. Em contrapartida, o cat mostra os caracteres
quebrados, assim como aparecem na tabela.

Alguém já enfrentou um problema desses?

Eu sei que basicamente meu problema está nas variáveis de ambiente
"Nacionais", no entanto, não sei para quais devo setar para que esses
caracteres chineses sejam carregados corretamente para a tabela externa.

Coluna que deve receber os caracteres em chines foi criada como NVARCHAR2.

Red Hat Enterprise Linux Server release 5.10 (Tikanga)
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

oragwp01@lxdwprddb01>env | grep NLS
NLS_SORT=BINARY
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
NLS_DATE_LANGUAGE=AMERICAN
NLS_NUMERIC_CHARACTER=.,
ORA_NLS33=/oracle/GWP01/home/server/10.2.0/ocommon/nls/admin/data
NLS_DATE_FORMAT=DD-MON-RR


SQL> select * from nls_database_parameters;

PARAMETER  VALUE
-- 
NLS_LANGUAGE   AMERICAN
NLS_TERRITORY  AMERICA
NLS_CURRENCY   $
NLS_ISO_CURRENCY   AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET   WE8ISO8859P1
NLS_CALENDAR   GREGORIAN
NLS_DATE_FORMATDD-MON-RR
NLS_DATE_LANGUAGE  AMERICAN
NLS_SORT   BINARY
NLS_TIME_FORMATHH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT   DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMATDD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY  $
NLS_COMP   BINARY
NLS_LENGTH_SEMANTICS   BYTE
NLS_NCHAR_CONV_EXCPFALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION  10.2.0.4.0

20 rows selected.



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com

Re: [oracle_br] Re: Ajuda com Tune de query

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Chiappa, eu esqueci de mencionar.

Eu usei a query como passei para testar sua execução pois estava com
preguiça de setar as binds :P

Na verdade a query roda dessa forma:


SELECT  fcal.business_owner_dim_id,
fcal.date_dim_id,
dprd.call_type_cd,
DPRD.call_type_nm,
fcal.gl_product_dim_id,
CM.CLASS_OF_SERVICE_ID,
TRUNC (SYSDATE) start_effective_date,
SUM (billable_minutes) minutes,
COUNT ( * ) calls,
SUM (FCAL.ACTUAL_CONNECTIONS) connections,
SUM (netbasetotcallamt) revenue,
ut.USE_TYPE_CATEGORY,
:g_msg_program,
SYSDATE,
:g_msg_program,
SYSDATE
 FROM   gdwhs_adm.f_call fcal,
gdwhs_adm.d_product dprd,
ODS_SFDC.SFDC_BTC_GL_COS_MAP cm,
gdwhs_adm.d_use_type ut
WHERE   partition_key BETWEEN :i_6c_bi_from_date AND :i_refresh_date
AND fcal.product_dim_id = dprd.product_dim_id
AND FCAL.GL_PRODUCT_DIM_ID = CM.GL_PRODUCT_DIM_ID
AND FCAL.USE_TYPE_DIM_ID = UT.USE_TYPE_DIM_ID
GROUP BY   fcal.business_owner_dim_id,
fcal.date_dim_id,
dprd.call_type_cd,DPRD.call_type_nm,
fcal.gl_product_dim_id,
ut.USE_TYPE_CATEGORY,
CM.CLASS_OF_SERVICE_ID;

Dessa forma, o indice também não foi ativado.

Chiappa, me corrija se eu estiver errado, por favor. No caso do indice
quando usamos uma função.

Nessa query, o predicado não está usando função alguma (partition_key)
apenas o valor pelo qual essa coluna deve ser comparada, que no caso é
sysdate - 6 meses.

Se eu utilizar a mesma clausula em um count, por exemplo, então o indice é
utilizado:

select count(*) from f_cal
WHERE   partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6)
 AND  SYSDATE


SQL> set pages 999 lines 180
SQL> explain plan for
  2  select count(*) from
  3  gdwhs_adm.f_call fcal
  4  where partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6) AND
 SYSDATE;

Explained.

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT

Plan hash value: 3191905543

--
| Id  | Operation  | Name   |
Rows  | Bytes | Cost (%CPU)| Time | Pstart| Pstop |TQ  |IN-OUT| PQ
Distrib |
--
|   0 | SELECT STATEMENT   ||
  1 | 8 |75   (0)| 00:00:02 |   |   ||  |
 |
|   1 |  SORT AGGREGATE||
  1 | 8 ||  |   |   ||  |
 |
|*  2 |   PX COORDINATOR   ||
|   ||  |   |   ||  |
 |
|   3 |PX SEND QC (RANDOM) | :TQ1   |
  1 | 8 ||  |   |   |  Q1,00 | P->S | QC
(RAND)  |
|   4 | SORT AGGREGATE ||
  1 | 8 ||  |   |   |  Q1,00 | PCWP |
 |
|*  5 |  FILTER||
|   ||  |   |   |  Q1,00 | PCWC |
 |
|   6 |   PX BLOCK ITERATOR||
 20M|   155M|75   (0)| 00:00:02 |   KEY |   KEY |  Q1,00 | PCWC |
 |
|   7 |BITMAP CONVERSION COUNT ||
 20M|   155M|75   (0)| 00:00:02 |   |   |  Q1,00 | PCWP |
 |
|*  8 | BITMAP INDEX FAST FULL SCAN| F_CALL_PARTITION_KEY_BMIDX |
|   ||  |   KEY |   KEY |  Q1,00 | PCWP |
 |
--

Predicate Information (identified by operation id):
---

   2 - filter(ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6)<=SYSDATE@!)
   5 - filter(ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6)<=SYSDATE@!)
   8 - filter("PARTITION_KEY">=ADD_MONTHS(TRUNC(SYSDATE@!,'fmmm'),-6) AND
"PARTITION_KEY"<=SYSDATE@!)

22 rows selected.


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com



Em 14 de julho de 2014 17:18, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Bom, a primeira coisa que Salta aos olhos é que vc tá metendo uma
> alteração na coluna partition_key :
>
>
> WHERE   partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6) AND
> SYSDATE
>
> é via função TRUNC, no caso, mas fosse Qualquer outra alteração caímos na
> mesma situação, que é : no RDBMS Oracle, se vc alterar a coluna indexada
> dentro da cláusula WHERE , o índice na esmagadora maioria das veze

[oracle_br] Ajuda com Tune de query

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Boa tarde, caros colegas.

Estou neste momento trabalhando no tune de uma query em particular e
gostaria da opinião de vocês quanto à tomada de decisão.

Banco 10.2.0.4.0

Existe essa query que faz parte de uma procedure que roda diariamente.

SELECT  fcal.business_owner_dim_id,
   fcal.date_dim_id,
   dprd.call_type_cd,
   DPRD.call_type_nm,
   fcal.gl_product_dim_id,
   CM.CLASS_OF_SERVICE_ID,
   TRUNC (SYSDATE) start_effective_date,
   SUM (billable_minutes) minutes,
   COUNT ( * ) calls,
   SUM (FCAL.ACTUAL_CONNECTIONS) connections,
   SUM (netbasetotcallamt) revenue,
   ut.USE_TYPE_CATEGORY
FROM   gdwhs_adm.f_call fcal,
   gdwhs_adm.d_product dprd,
   ODS_SFDC.SFDC_BTC_GL_COS_MAP cm,
   gdwhs_adm.d_use_type ut
   WHERE   partition_key BETWEEN ADD_MONTHS (TRUNC (SYSDATE, 'mm'), -6)
 AND  SYSDATE
   AND fcal.product_dim_id = dprd.product_dim_id
   AND FCAL.GL_PRODUCT_DIM_ID = CM.GL_PRODUCT_DIM_ID
   AND FCAL.USE_TYPE_DIM_ID = UT.USE_TYPE_DIM_ID
GROUP BY   fcal.business_owner_dim_id,
   fcal.date_dim_id,
   dprd.call_type_cd,
   DPRD.call_type_nm,
   fcal.gl_product_dim_id,
   ut.USE_TYPE_CATEGORY,
   CM.CLASS_OF_SERVICE_ID


O plano de execução para a mesma é o seguinte:

---
| Id  | Operation  | Name| Rows  |
Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |TQ  |IN-OUT| PQ
Distrib |
---
|   0 | SELECT STATEMENT   | |   339K|
 29M|   |   137K  (1)| 00:32:10 |   |   ||  |
 |
|*  1 |  PX COORDINATOR| |   |
  |   ||  |   |   ||  |
   |
|   2 |   PX SEND QC (RANDOM)  | :TQ10004|   339K|
 29M|   |   137K  (1)| 00:32:10 |   |   |  Q1,04 | P->S | QC
(RAND)  |
|   3 |SORT GROUP BY   | |   339K|
 29M|67M|   137K  (1)| 00:32:10 |   |   |  Q1,04 | PCWP |
 |
|   4 | PX RECEIVE | |   339K|
 29M|   |   137K  (1)| 00:32:10 |   |   |  Q1,04 | PCWP |
 |
|   5 |  PX SEND HASH  | :TQ10003|   339K|
 29M|   |   137K  (1)| 00:32:10 |   |   |  Q1,03 | P->P | HASH
  |
|   6 |   SORT GROUP BY| |   339K|
 29M|67M|   137K  (1)| 00:32:10 |   |   |  Q1,03 | PCWP |
 |
|*  7 |FILTER  | |   |
  |   ||  |   |   |  Q1,03 | PCWC |
   |
|*  8 | HASH JOIN  | |   339K|
 29M|   |   137K  (1)| 00:32:10 |   |   |  Q1,03 | PCWP |
 |
|   9 |  PX RECEIVE| |  2189 |
45969 |   |85   (0)| 00:00:02 |   |   |  Q1,03 | PCWP |
   |
|  10 |   PX SEND BROADCAST| :TQ10001|  2189 |
45969 |   |85   (0)| 00:00:02 |   |   |  Q1,01 | P->P |
BROADCAST  |
|  11 |PX BLOCK ITERATOR   | |  2189 |
45969 |   |85   (0)| 00:00:02 |   |   |  Q1,01 | PCWC |
   |
|  12 | TABLE ACCESS FULL  | D_PRODUCT   |  2189 |
45969 |   |85   (0)| 00:00:02 |   |   |  Q1,01 | PCWP |
   |
|* 13 |  HASH JOIN | |   339K|
 22M|   |   137K  (1)| 00:32:09 |   |   |  Q1,03 | PCWP |
 |
|  14 |   BUFFER SORT  | |   |
  |   ||  |   |   |  Q1,03 | PCWC |
   |
|  15 |PX RECEIVE  | |73 |
 1898 |   | 3   (0)| 00:00:01 |   |   |  Q1,03 | PCWP |
   |
|  16 | PX SEND BROADCAST  | :TQ1|73 |
 1898 |   | 3   (0)| 00:00:01 |   |   || S->P |
BROADCAST  |
|  17 |  TABLE ACCESS FULL | SFDC_BTC_GL_COS_MAP |73 |
 1898 |   | 3   (0)| 00:00:01 |   |   ||  |
   |
|* 18 |   HASH JOIN| |   339K|
 14M|   |   137K  (1)| 00:32:09 |   |   |  Q1,03 | PCWP |
 |
|  19 |PX RECEIVE  | |10 |
 60 |   | 2   (0)| 00:00:01 |   |   |  Q1,03 | PCWP |
 |
|  20 | PX SEND BROADCAST  | :TQ10002|10 |
 60 |   | 2   (0)| 00:00:01 |   |   | 

Re: [oracle_br] EXP

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

>> 13  BUFFER_POOL DEFAULT
>>
>> 14  FLASH_CACHE DEFAULT
>>
>> 15  CELL_FLASH_CACHE DEFAULT)
>>
>> 16  TABLESPACE "TBS_DATA"
>>
>> 17* PARALLEL 1
>>
>> SQL>
>>
>>
>>
>> E mesmo tirando todos os parâmetros da criação índice, ele ainda dá erro:
>>
>>
>>
>>
>>
>>   1  CREATE UNIQUE INDEX "I9_WMS_892"."UK_MABARCODE"
>>
>>   2  ON "I9_WMS_892"."MANDATOR" ("MA_BARCODE")
>>
>>   3*  TABLESPACE "TBS_DATA"
>>
>> SQL> connect system
>>
>> Enter password:
>>
>> Connected.
>>
>> SQL> l
>>
>>   1  CREATE UNIQUE INDEX "I9_WMS_892"."UK_MABARCODE"
>>
>>   2  ON "I9_WMS_892"."MANDATOR" ("MA_BARCODE")
>>
>>   3*  TABLESPACE "TBS_DATA"
>>
>> SQL> /
>>
>> CREATE UNIQUE INDEX "I9_WMS_892"."UK_MABARCODE"
>>
>> *
>>
>> ERROR at line 1:
>>
>> ORA-03113: end-of-file on communication channel
>>
>> Process ID: 6492
>>
>> Session ID: 464 Serial number: 45
>>
>>
>>
>> O problema principal foi esse:
>>
>>
>> *RA-01455:*converting column overflows integer datatype *Cause:*The
>> converted form of the specified expression was too large for the specified
>> datatype. *Action:*Define a larger datatype or correct the data.
>>
>>
>> Depois pra resolver foram apagadas 2 constraints UK, fiz update na base
>> do campo respectivo para NULL, e problema resolvido.
>>

>>
>>
>>
>> Att,
>>
>>
>>
>>
>>
>> Em 9 de julho de 2014 15:47, Evandro Giachetto evandrogiache...@gmail.com
>> [oracle_br]  escreveu:
>>
>>
>>>
>>> Olha, incrementando meu último e-mail:
>>>
>>>  - Há algum erro no alert?
>>>  - Você tem espaço suficiente no mount point onde está sendo gerado o
>>> dump?
>>>  - Tem absoluta certeza que não há nenhum bloco corrompido nos blocos
>>> que está exportando?
>>>  - Qual foi o comando completo que utilizou para gerar o export?
>>>  - Qual o motivo de não conseguir exportar esses mesmos dados usando
>>> expdp?
>>>  - O Characterset de seu banco é compativel com o NLS_LANG em seu SO ?
>>>
>>> Evandro Giachetto
>>> Oracle DBA
>>> evandrogiache...@gmail.com
>>>
>>>
>>>
>>> Em 9 de julho de 2014 11:23, 'Milton Bastos Henriquis Jr.'
>>> miltonbas...@gmail.com [oracle_br] 
>>> escreveu:
>>>
>>>>
>>>>
>>>> Oracle 11.2.0.1 rodando no Windows 8
>>>>
>>>> Tentando rodar um export... EXP antigo (pois o datapump não tá rolando)
>>>>
>>>> Alguém conhece esse erro?
>>>>
>>>>
>>>> EXP-00015: erro na linha 18326 da tabela LOG_ACTIONS, coluna ANL_DT,
>>>> tipo de dados 12
>>>> EXP-1: truncamento do campo de dados - tamanho da coluna=7, tamanho
>>>> do buffer=8 tamanho real=48
>>>> . . exportando tabelaLOGGING  0 linhas
>>>> exportadas
>>>> . . exportando tabela   MANDATOR
>>>> EXP-00015: erro na linha 213695 da tabela MANDATOR, coluna MA_FAX, tipo
>>>> de dados 1
>>>> EXP-1: truncamento do campo de dados - tamanho da coluna=100,
>>>> tamanho do buffer=100 tamanho real=105
>>>> . . exportando tabela   MANDATOR_PALLETIZING  0 linhas
>>>> exportadas
>>>> . . exportando tabela   MESSAGES   1140 linhas
>>>> exportadas
>>>>
>>>>
>>>>
>>>>
>>>> Att,
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>

Re: [oracle_br] EXP

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olha, incrementando meu último e-mail:


 - Há algum erro no alert?
 - Você tem espaço suficiente no mount point onde está sendo gerado o dump?
 - Tem absoluta certeza que não há nenhum bloco corrompido nos blocos que
está exportando?
 - Qual foi o comando completo que utilizou para gerar o export?
 - Qual o motivo de não conseguir exportar esses mesmos dados usando expdp?
 - O Characterset de seu banco é compativel com o NLS_LANG em seu SO ?


Evandro Giachetto
Oracle DBA

evandrogiache...@gmail.com






Em 9 de julho de 2014 11:23, 'Milton Bastos Henriquis Jr.'
miltonbas...@gmail.com [oracle_br]  escreveu:


>
>
> Oracle 11.2.0.1 rodando no Windows 8
>
> Tentando rodar um export... EXP antigo (pois o datapump não tá rolando)
>
> Alguém conhece esse erro?
>
>
> EXP-00015: erro na linha 18326 da tabela LOG_ACTIONS, coluna ANL_DT, tipo
> de dados 12
> EXP-1: truncamento do campo de dados - tamanho da coluna=7, tamanho do
> buffer=8 tamanho real=48
> . . exportando tabelaLOGGING  0 linhas
> exportadas
> . . exportando tabela   MANDATOR

> EXP-00015: erro na linha 213695 da tabela MANDATOR, coluna MA_FAX, tipo de
> dados 1
> EXP-1: truncamento do campo de dados - tamanho da coluna=100, tamanho
> do buffer=100 tamanho real=105
> . . exportando tabela   MANDATOR_PALLETIZING  0 linhas
> exportadas
> . . exportando tabela   MESSAGES   1140 linhas
> exportadas
>
>
>
>
> Att,
>
>
>
>
>

Re: [oracle_br] EXP

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Milton, alguma mensagem no Alert ?



Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com



Em 9 de julho de 2014 11:23, 'Milton Bastos Henriquis Jr.'
miltonbas...@gmail.com [oracle_br]  escreveu:

>
>
> Oracle 11.2.0.1 rodando no Windows 8
>
> Tentando rodar um export... EXP antigo (pois o datapump não tá rolando)
>
> Alguém conhece esse erro?
>
>
> EXP-00015: erro na linha 18326 da tabela LOG_ACTIONS, coluna ANL_DT, tipo
> de dados 12
> EXP-1: truncamento do campo de dados - tamanho da coluna=7, tamanho do
> buffer=8 tamanho real=48
> . . exportando tabelaLOGGING  0 linhas
> exportadas
> . . exportando tabela   MANDATOR
> EXP-00015: erro na linha 213695 da tabela MANDATOR, coluna MA_FAX, tipo de
> dados 1
> EXP-1: truncamento do campo de dados - tamanho da coluna=100, tamanho
> do buffer=100 tamanho real=105
> . . exportando tabela   MANDATOR_PALLETIZING  0 linhas
> exportadas
> . . exportando tabela   MESSAGES   1140 linhas
> exportadas
>
>
>
>
> Att,
>
>
>
>   
>

Re: [oracle_br] Erro IMPDP

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Bom dia amigo.

Eu vi apenas o Chiappa comentar sobre a diferença nas versões em que você
informou que o dump foi gerado (expdp) de um banco na versão 11.2.0.3 e
você está importando na versão 11.2.0.1.

Teoricamente, se você não informou o datapump utiliza o VERSION como
COMPATIBLE por default, o que permitiria que você importasse esse dump em
outros bancos dentro da mesma release, neste caso, o 11gR2.

Apenas a título de curiosidade. Você tentou gerar o export usando o
parametro VERSION=11.2.0.1 ?

Neste caso, o seu dump seria gerado especificamente para a versão 11.2.0.1,
mesmo sendo gerado a partir da versão 11.2.0.3

De qualquer forma, quando você usa o DATA_ONLY, por padrão o
TABLE_EXISTS_ACTION passa a usar como default o valor APPEND.

TABLE_EXISTS_ACTION

Default: SKIP (Note that if CONTENT=DATA_ONLY is specified, then the
default is APPEND, not SKIP.)

Purpose

Tells Import what to do if the table it is trying to create already exists.

Syntax and Description

TABLE_EXISTS_ACTION=[SKIP | APPEND | TRUNCATE | REPLACE]


Ou seja, como você disse que funcionou quando você trocou CONTENT=DATA_ONLY
por TABLE_EXISTS_ACTION=APPEND, então, muito provavelmente você atingiu um
bug quando do import entre versões.

Por isso eu perguntei se utilizou o parâmetro VERSION.

Talvez valha a pena passar a utilizar este parâmetro sempre que o dump que
estiver sendo gerado destine-se a um banco com versão diferente, mesmo
dentro da mesma release.


Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com



Em 7 de julho de 2014 17:10, 'Milton Bastos Henriquis Jr.'
miltonbas...@gmail.com [oracle_br]  escreveu:

>
>
> Pra gente não vale a pena, pois não temos base de produção - usamos apenas
> para desenvolvimento.
> O nível de criticidade é próximo a zero.
>
> Só fiquei curioso com esse erro do IMPDP porque ele aconteceu em duas
> bases diferentes:
>  - 11.2.0.3 no OEL 6.5
>  - 11.2.0.1 no Windows 8
>
> Em abos deu o seguinte problema:
> ao chegar na fase de importar ÍNDICES ele dá um "fatal error" e termina o
> import.
>
>
>
> Em 7 de julho de 2014 16:25, jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br> escreveu:
>
>>
>>
>> Então : pode ou não estar relacionado com os problemas que vc teve, mas
>> necessariamente todo e qualquer erro ORA-00600 e ORA-07445 implica em BUG
>> (nem que seja um simples bug de documentação, não indicando uma sintaxe
>> necessária, digamos, ou mesmo BUG do SO e/ou de camadas externas ao
>> database, talvez), mas BUG...
>>  Então vc necessariamente deveria ter Suporte para esse ambiente para
>> poder abrir um Chamado , OU ao menos o pessoal deveria comprar Suporte para
>> um outro produto Oracle qualquer dos mais baratinhos, só para que pelo
>> menos vc possa baixar uma versão mais atualizada do RDBMS e testar se os
>> problemas continuam ou não na versão mais atualizada... Afora isso, não tem
>> muito o que se fazer, então acione os responsáveis pelo Ambiente em questão
>> e veja o que consegue nesse sentido, senão não terás mais ações possíveis
>> que não sejam work-arounds pontuais, mas sempre sem saber causa-raiz...
>>
>>   []s
>>
>> Chiappa
>>
>
>  
>

Re: [oracle_br] Instalacao Oracle-XE em maq.virtual Parallels no Macbook

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Só complementando o que o Chiappa disse.
No ubuntu é mais complicado mesmo, no entanto existem alguns pacotes
disponibilizados em que a instalação é automática.
Assim, após importar o repositório, vc instala com apt-get install
oracle-xe

Mas lógico, eu também recomendo utilizar uma versão homologada. E, dentre
os Linux free, vc pode usar o Oracle, open Suse e alguns so baseados em red
hat, como é o caso do próprio Oracle Linux ou do CentOS que, apesar de não
ser homologado, você pode usar a mesma documentação de instalação do red
hat que dá certinho.
Em 03/06/2014 17:50, "Sergio Lima sergiosouzal...@gmail.com [oracle_br]" <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Obrigado Chiappa pelas explicações.
>
> Amanha vou seguir direitinho o que vc escreveu ai.
>
> Depois deixo os resultados aqui.
>
>
> Grato,
>
> ---
> Sergio Lima 
>
>- CAPM Certified
>- ITIL Foundation
>- COBIT Foundation
>
>
>
> 2014-06-03 17:46 GMT-03:00 jlchia...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br>:
>
>>
>>
>>  Colega, deixe-me dar uns pitacos -  primeiro, quando o serviço do
>> database não sobre automaticamente (como parece ser o seu caso),
>> tipicamente ficou faltando algum dos requisitos de Windows , que são :
>>
>>  a)  o mínimo de memória recomendado na máquina Windows (a VM no seu
>> caso) é de 1 GB, vc seguiu isso ?? Em muitos softwares de virtyualização o
>> default pra uma VM é inferior a isso, confira no teu tal software aonde e
>> como se muda a qtdade de RAM a alocar para a VM
>>
>>  b) o usuário com que vc está logado no Windows *** TEM *** que ser um
>> Administrador local , assegure-se disso
>>
>>  c) swap area no Windows deve ser 2x a qtdade de RAM, E preferencialmente
>> vc deve configurar no Windows controle e tamanho manuais , desabilitando a
>> opção de Gerenciar automaticamente o tamanho do arquivo de paginação de
>> todas as unidades.
>>
>>  d) mesmo o usuário estando no Grupo de Admins Locais, por causa das
>> restrições de segurança mais "apertadas" que vêm por default nos Windows
>> mais recentes, vc na hora de rodar o setup ** TEM ** que clickar com o
>> botão direito no setup.exe e usar a opção de "run As Administrator/Executar
>> como Administrador"
>>
>> Tomando esses cuidados, não vejo por que falharia a instalação : zera
>> essa VM aí, cria uma nova com os pré-requisitos e executa novamente, que
>> não tem porque falhar ...
>>
>>  Já sobre o Ubuntu, aí é totalmente OUTRA questão : o RDBMS Oracle não é
>> e nunca foi homologado nem Suportado de nenhuma forma no Ubuntu, então a
>> recomendação maior seria usar outras distros Linux suportadas - das
>> gratuitas, a distro Linux da própria Oracle (o Oracle Enterprise Linux,
>> OEL) seria a mais indicada, por ser a mais conhecida : googla por oracle xe
>> install on oel que vc acha uns tantos quantos exemplos Até dá pra fazer
>> funcionar o Ubuntu mesmo mas com Certeza vc vai ter que instalar diversos
>> itens/componentes que não vêm por default, vai ter dar muuuito mais
>> trabalho...
>>
>>   []s
>>
>> Chiappa
>>
>
>  
>

Re: [oracle_br] Re: Exportar dados de um banco com o datafile sysaux01.dbf corrompido

[Evandro Giachetto evandrogiache...@gmail.com [oracle_br]]

Olha, eu confesso que peguei o bonde andando e não lí o primeiro e-mail da
thread.. mas pelo que pude entender, seu banco está com a sysaux zuada e,
aparentemente o banco não está em modo archive.

Minha pergunta é.

Datapump está funcionando?

Eu tive um problema parecido, mas a sysaux não estava "corrompida". Apenas
não era possível modificar a tablespace que era pre-requisito para upgrade
de 10g para 11g.

O banco era muito grande (cerca de 10Tera) então, a solução que usei nessa
ocasião foi:

Criar um banco 11g "From scratch" (com uma sysaux integra).
Exportar apenas os objetos PL/SQL do banco de origem, 10g.
"Instalar" todos os recursos que seu banco 10g utilizava, como por exemplo,
Java ou XML.
Criar todos os usuários no banco 11g e importar os objetos PL/SQL (mesmo
que todos fiquem inválidos neste momento)
Em seguida, coloquei todas as outras tablespaces do banco 10g, excluindo a
sysaux, system, temp e undo, em read-only e as exportei como Transportable
Tablespace.
Baixei o banco 10g e importei essas transportable tablespace no novo banco
11g.

Tanto o export como o import foram bem rápidos pois o datapump vai,
simplesmente, "Plugar" meus datafiles do banco 10g no meu novo banco 11g.
Não vai exportar dados.

Em seguida, no banco 11g, vc muda as tablespaces para read-write e roda o
utlrp para recompilar seus objetos inválidos.

Obviamente, falei bem por cima os passos que segui naquela ocasião. Vale
uma leitura pelo google afora para maiores detalhes sobre este processo.


Se não for possível rodar o datapump por causa de sua sysaux, me perdoe,
mas o que escreví alí acima pode ser útil para mais alguém.

Forte abraço

Evandro Giachetto
Oracle DBA
evandrogiache...@gmail.com



Em 28 de maio de 2014 13:26, jlchia...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Sim, veja lá na minha resposta que eu cito : existem N maneiras de se
> recuperar uma tablespace corrupta/incompleta/não-atualizada (entre elas,
> FLASHBACK DATABASE, Block recover do RMAN, o RECOVER da tablespace (ie,
> aplicação dos logs de alteração em cima de último backup reconhecidamente
> íntegro, entre outras) , mas TODAS exigem que ou o banco esteja em modo de
> archive e vc tenha os archived redo logs todos e/ou que existam backups
> próprios e/ou que vc tenha flashback logs/FRA ativos... Pelo que vc
> descreve , se nem dump de dados neguim tinha aí nesse coiso, quanto mais
> esperar por coisas como essas que cito... Dá uma pesquisada aí pra ver se
> causalmente vc tem algo assim mas eu sinceramente duvido...
>
>  []s
>
>Chiappa
>  
>