Alessandro Guimarães – Oracle Blog

January 10, 2013

2012 in review

Filed under: banco de dados — agleite @ 1:27 pm

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 5,000 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 8 years to get that many views.

Click here to see the complete report.

August 14, 2012

GUOB 2012 | Sucesso

Filed under: banco de dados — agleite @ 2:03 pm

Quem foi aproveitou e muito o evento GUOB 2012. Mais uma vez o evento confirmou por que é um dos melhores deste tipo no Brasil.

Quem não foi, como eu ;( , poderá ter acesso as apresentações dos palestrantes no site do GUOB.

Parabens ao Eduardo Hanh, Rodrigo Almeida, Vinicius, Portilho entre outros e que venha mais um GUOB em 2013

July 11, 2012

GUOB | Tech Day 2012

Filed under: banco de dados — Tags: , — agleite @ 2:16 pm

Image

Participe deste grande evento organizado pelo GUOB. Até o dia 14/07/2012garanta sua inscrição antecipada com desconto de 45%.


O GUOB realizará a edição 2012 do grande encontro de usuários de tecnologia Oracle do Brasil com a participação de palestrantes internacionais e nacionais no dia 11/08/2012, sábado, em São Paulo, no Hotel Blue Tree Morumbi.

Já temos as presenças confirmadas de Tom Kyte, Graham Wood, Andrew Holdsworth, Bruno Souza, Craig Shallahamer, Dana Singleterry, Dimitri Gielies, Patanjali Venkatacharaya, Tim tow  e Francisco Alvarez.

Aproveite esta grande oportunidade de estar próximo de grandes autores e referências em tecnologia Oracle no mundo.

Este ano estaremos apresentando temas como:

  • Administração de Banco de dados
  • Desenvolvimento de aplicações
  • Oracle Middleware
  • Java
  • MySQL
  • BPM/BI
  • Oracle Applications
  • Oracle VM
  • Oracle Linux

Faça já sua inscrição clicando aqui. Vagas limitadas!

Para mais informações, acesse nosso site www.guob.com.br ou entre em contato pelo emailcontato@guob.com.br.

July 23, 2011

GUOB 2011 | Comentários, Feedbacks e Impressões

Filed under: banco de dados — agleite @ 12:08 pm

O Guob 2011 foi,  assim como o  Guob2010,   um sucesso.  Destaco a excelência dos palestrantes internacionais (Arup Nanda, uassi Mensah, Kai Yu, Graham Wood,  Debra Lilley ) e nacionais (Marcos Vinicius, Rodrigo Mufalani, entre outros),  organização, comodidade, conforto e acessibilidade do local escolhido, principalmente para aqueles que vem de fora, como eu .

Na web já existem vários comentários sobre o evento  como no blog do Eduardo Legattiaprenderoracle PHPDBA, que colocaram de forma clara e concisa a experiencia do evento.

Espero que eventos deste nível,  aconteçam com mais frequencia não somente em São Paulo mas em  outras regiões do País

June 21, 2011

GUOB TECH DAY 2011

Filed under: banco de dados — Tags: , — agleite @ 10:50 am


O Guob Tech Day está chegando. Organizem suas agendas.

Agende-se para mais este grande evento organizado pelo GUOB com apoio do LAOUC e OTN. Acontecerá no dia 16/07/2011,sábado, em São Paulo no Hotel Blue Tree Morumbi, a edição 2011 do grande encontro de usuários de tecnologia Oracle do Brasil com a participação de palestrantes internacionais e nacionais.

Este ano contamos com a presença de Arup Nanda, Graham Wood, Debra Lilley, Kay Yu, Hans Forbrich e Francisco Munoz.

Aproveite esta grande oportunidade de estar próximo de grande autores e referências em tecnologia Oracle no mundo.

Faça sua associação gratuita ao GUOB através da opção no menu ASSOCIE-SE em nosso site. Você poderá ser o ganhador de um dos 3 convites para associados ao GUOB para um almoço com os palestrantes durante o GUOB TECH DAY 2011.

Participem e divulguem o evento.

Acesse nosso site http://www.guob.com.br para maiores informações. GUOB TECH DAY 2011.

GUOB – Grupo de Usuários de Tecnologia Oracle do Brasil

June 16, 2011

Extended Statistics – Multicolumn Statistics

Filed under: banco de dados — Tags: , , , — agleite @ 3:05 pm

Extendend Statistics é uma feature do 11g que ajuda o otimizador baseado em custo (CBO) tomar melhores decisões utilizando estatisticas  em grupo de colunas, quando várias colunas de um tabela estão na clausula where da consulta.

Além das estatisticas padrão, histogramas também podem ser criados nestes grupos de colunas melhorando a estimativa de custos quando existe um desvio na distribuição dos dados do grupo de colunas.

Para o CBO decidir como executar um consulta, ele utiliza as estatísticas disponíveis para calcular o custo de possíveis metodos de acesso.   Seletividade por exemplo, é um dos fatores utilizados neste calculo e consequentemente na escolha do melhor metodo de acesso.  Antes do 11g, as estatisticas so podiam ser criadas em colunas separadamente. A inabilidade do CBO de perceber o relacionamento entre colunas de uma tabela limitava significativamente a exatidão na estimativa do custo.

Para demonstrar como funciona a feature primeiro vamos criar uma tabela de pedidos

ALESSANDRO@orcl> create table pedidos
2  as
select level nr
3    4           , ‘Cliente ‘ || to_char(level) Nome_Cliente
5            , case
6              when level <= 500 then ‘Ipanema’
when level <= 550 then ‘Lagoa’
7    8              when level <= 600 then ‘Olinda’
9              when level <= 650 then ‘Centro’
10             when level <= 700 then ‘Bexiga’
11             when level <= 750 then ‘Areinha’
when level <= 800 then ‘Aldeota’
12   13             when level <= 850 then ‘Itapoa’
14             when level <= 900 then ‘Pajucara’
15             else ‘Bessa’
16             end Bairro
, case
17   18             when level <  500 then ‘RJ’
when level <= 550 then ‘MG’
when level <= 600 then ‘PE’
19   20   21             when level <= 650 then ‘TE’
22             when level <= 700 then ‘SP’
when level <= 750 then ‘MA’
23   24             when level <= 800 then ‘CE’
25             when level <= 850 then ‘BA’
26             when level <= 900 then ‘AL’
else ‘PB’
27   28             end UF
from dual
29   30  connect by level <= 1000
/
31
Table created.

Vamos dar uma olhada no conteudo da tabela

ALESSANDRO@orcl> select bairro, count(*)
2  from pedidos
3  group by bairro
4  order by bairro desc;

BAIRRO     COUNT(*)
——– ———-
Pajucara         50
Olinda           50
Lagoa            50
Itapoa           50
Ipanema         500
Centro           50
Bexiga           50
Bessa           100
Areinha          50
Aldeota          50

10 rows selected.

ALESSANDRO@orcl> select uf, count(*)
2  from  pedidos
3  group by uf
4  order by count(*) desc;

UF   COUNT(*)
— ———-
RJ        499
PB        100
MG         51
TE         50
MA         50
CE         50
BA         50
AL         50
SP         50
PE         50

10 rows selected.

Temos  então 10 bairros e 10 UF, com uma associação clara entre bairro e UF.

Vamos então gerar as estatisticas

ALESSANDRO@orcl> exec dbms_stats.gather_table_stats(user,’pedidos’);

PL/SQL procedure successfully completed.

Ok, Agora vamos dar uma olhada na seguinte query.
ALESSANDRO@orcl> explain plan
2  for
3  select * from pedidos
4  where bairro=’Ipanema’
5  and   UF = ‘RJ’
6  /

1* select * from table(dbms_xplan.display)
ALESSANDRO@orcl> /

PLAN_TABLE_OUTPUT
——————————————————————————–
Plan hash value: 3882451908

—————————————————————————–
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————–
|   0 | SELECT STATEMENT  |         |    10 |   260 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| PEDIDOS |    10 |   260 |     4   (0)| 00:00:01 |
—————————————————————————–

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

PLAN_TABLE_OUTPUT
——————————————————————————–

1 – filter(“BAIRRO”=’Ipanema’ AND “UF”=’RJ’)

13 rows selected.

ALESSANDRO@orcl>

Como não geramos histogramas o CBO previu 10 linhas. Isto aconteceu por que o predicado bairro=’Ipanema’  tem 10 valores distintos, o mesmo acontece com  UF=’RJ’ .  O calculo que o CBO faz : 1000 linhas *(1/10)*(1/10) = 10 linhas.

Veja o que acontece quando faço esta pesquisa agora

ALESSANDRO@orcl> explain plan
2  for
3  select * from pedidos
4  where bairro=’Ipanema’ and UF=’PE';

Explained.

ALESSANDRO@orcl> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
——————————————————————————–
Plan hash value: 3882451908

—————————————————————————–
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————–
|   0 | SELECT STATEMENT  |         |    10 |   260 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| PEDIDOS |    10 |   260 |     4   (0)| 00:00:01 |
—————————————————————————–

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

PLAN_TABLE_OUTPUT
——————————————————————————–

1 – filter(“BAIRRO”=’Ipanema’ AND “UF”=’PE’)

13 rows selected.

Esta consulta não retorna linhas e ainda assim o resultado é o mesmo.

Vamos dar uma ajudinha para o otimizador gerando histogramas
ALESSANDRO@orcl> exec dbms_stats.gather_table_stats(user, ‘pedidos’, method_opt=>’FOR ALL COLUMNS’);

PL/SQL procedure successfully completed.

ALESSANDRO@orcl> explain plan
2  for
3  select * from pedidos
4  where bairro=’Ipanema’
5  and   uf=’RJ';

Explained.

ALESSANDRO@orcl> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
——————————————————————————–
Plan hash value: 3882451908

—————————————————————————–
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————–
|   0 | SELECT STATEMENT  |         |   250 |  6500 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| PEDIDOS |   250 |  6500 |     4   (0)| 00:00:01 |
—————————————————————————–

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

PLAN_TABLE_OUTPUT
——————————————————————————–

1 – filter(“BAIRRO”=’Ipanema’ AND “UF”=’RJ’)

13 rows selected.

Agora a previsão foi de 250 linhas. Isto foi calculado atraves do histogramas que dizem ao CBO que ipanema ocorre 500 vezes em 1000 e rj ocorre 499 vezes em 100

E para Ipanema em PE temos :

ALESSANDRO@orcl> explain plan
2  for
3  select * from pedidos
4  where bairro=’Ipanema’
5  and   uf=’PE';

Explained.

ALESSANDRO@orcl>  select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
——————————————————————————–
Plan hash value: 3882451908

—————————————————————————–
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————–
|   0 | SELECT STATEMENT  |         |    25 |   650 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| PEDIDOS |    25 |   650 |     4   (0)| 00:00:01 |
—————————————————————————–

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

PLAN_TABLE_OUTPUT
——————————————————————————–

1 – filter(“BAIRRO”=’Ipanema’ AND “UF”=’PE’)

13 rows selected.

Ai está 25 linhas.

Antes do 11g isso é o melhor que podiamos conseguir. Com multicolumns statistics o calculo fica bem mais exato

ALESSANDRO@orcl> exec dbms_stats.gather_table_stats(user,’pedidos’,method_opt=>’FOR COLUMNS (bairro,uf)’);

ALESSANDRO@orcl> explain plan
2  for
3  select * from pedidos
4  where bairro=’Ipanema’
5  and   uf=’PE';

Explained.

ALESSANDRO@orcl>  select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
——————————————————————————–
Plan hash value: 3882451908

—————————————————————————–
| Id  | Operation         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
—————————————————————————–
|   0 | SELECT STATEMENT  |         |     1 |    27 |     4   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| PEDIDOS |     1 |    27 |     4   (0)| 00:00:01 |
—————————————————————————–

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

PLAN_TABLE_OUTPUT
——————————————————————————–

1 – filter(“BAIRRO”=’Ipanema’ AND “UF”=’PE’)

13 rows selected.

ALESSANDRO@orcl>

Agora sim. Como o otimizador não vai calcular 0 (zero) ele usa 1. Quanto mais preciso for o calculo, melhor vai ser o metodo de acesso que o otimizador vai escolher para uma determinada consulta, se vai utilizar indexes ou não por exemplo

Isto pode fazer uma enorme diferença em um ambiente de produção.

Com esta pequena demostração vimos como influenciar o otimizador sem alterar uma linha de codigo.
Se quiserver ver em pdf clica extendstats

February 20, 2011

Hoje eu sou um DBA

Filed under: banco de dados — Tags: , , — agleite @ 8:42 pm

Visitando o blog do Rodrigo Almeida, vi este clipe do The Sprinters, hoje eu sou um dba. Muito Legal !

January 21, 2011

ORACLE 11G R2 | LIMITS

Filed under: banco de dados — agleite @ 12:27 pm

Começar o ano com um post bem simples, apenas informativo. Abaixo tem uma lista com os limites do Oracle Database.

Dividida  em 4 categorias mais uma com  limites do compilador PL/SQL.

É uma agregação de 5 paginas  da documentação do Oracle Database 11g Release 2, ficando assim mais facil para consultar :)

Datatype Limits

Datatypes Limit Comments
BFILE Maximum size: 4 GB Maximum size of a file name: 255 characters Maximum size of a directory name: 30 characters Maximum number of open BFILEs: see Comments The maximum number of BFILEs is limited by the value of the SESSION_MAX_OPEN_FILES initialization parameter, which is itself limited by the maximum number of open files the operating system will allow.
BLOB Maximum size: (4 GB – 1) * DB_BLOCK_SIZE initialization parameter (8 TB to 128 TB) The number of LOB columns per table is limited only by the maximum number of columns per table (that is, 1000).
CHAR Maximum size: 2000 bytes None
CHAR VARYING Maximum size: 4000 bytes None
CLOB Maximum size: (4 GB – 1) * DB_BLOCK_SIZE initialization parameter (8 TB to 128 TB) The number of LOB columns per table is limited only by the maximum number of columns per table (that is, 1000).
Literals (characters or numbers in SQL or PL/SQL ) Maximum size: 4000 characters None
LONG Maximum size: 2 GB – 1 Only one LONG column is allowed per table.
NCHAR Maximum size: 2000 bytes None
NCHAR VARYING Maximum size: 4000 bytes None
NCLOB Maximum size: (4 GB – 1) * DB_BLOCK_SIZE initialization parameter (8 TB to 128 TB) The number of LOB columns per table is limited only by the maximum number of columns per table (that is, 1000).
NUMBER 999…(38 9′s) x10125 maximum value -999…(38 9′s) x10125 minimum value Can be represented to full 38-digit precision (the mantissa) Can be represented to full 38-digit precision (the mantissa)
Precision 38 significant digits None
RAW Maximum size: 2000 bytes None
VARCHAR Maximum size: 4000 bytes None
VARCHAR2 Maximum size: 4000 bytes None

Logical Database Limits

Item Type of Limit Limit Value
GROUP BY clause Maximum length The GROUP BY expression and all of the nondistinct aggregate functions (for example, SUM, AVG) must fit within a single database block.
Indexes Maximum per table Unlimited
Indexes Total size of indexed column 75% of the database block size minus some overhead
Columns Per table 1000 columns maximum
Columns Per index (or clustered index) 32 columns maximum
Columns Per bitmapped index 30 columns maximum
Constraints Maximum per column Unlimited
Subqueries Maximum levels of subqueries in a SQL statement Unlimited in the FROM clause of the top-level query 255 subqueries in the WHERE clause
Partitions Maximum length of linear partitioning key 4 KB – overhead
Partitions Maximum number of columns in partition key 16 columns
Partitions Maximum number of partitions allowed per table or index 1024K – 1
Rows Maximum number per table Unlimited
Stored Packages Maximum size PL/SQL and Developer/2000 may have limits on the size of stored procedures they can call. The limits typically range from 2000 to 3000 lines of code.
Trigger Cascade Limit Maximum value Operating system-dependent, typically 32
Users and Roles Maximum 2,147,483,638
Tables Maximum per clustered table 32 tables
Tables Maximum per database Unlimited

Physical Database Limits

Item Type of Limit Limit Value
Database Block Size Minimum 2048 bytes; must be a multiple of operating system physical block size
Database Block Size Maximum Operating system dependent; never more than 32 KB
Database Blocks Minimum in initial extent of a segment 2 blocks
Database Blocks Maximum per datafile Platform dependent; typically 222 – 1 blocks
Controlfiles Number of control files 1 minimum; 2 or more (on separate devices) strongly recommended
Controlfiles Size of a control file Dependent on operating system and database creation options; maximum of 20,000 x (database block size)
Database files Maximum per tablespace Operating system dependent; usually 1022
Database files Maximum per database 65533 May be less on some operating systems Limited also by size of database blocks and by the DB_FILES initialization parameter for a particular instance
Database extents Maximum per dictionary managed tablespace 4 GB * physical block size (with K/M modifier); 4 GB (without K/M modifier)
Database extents Maximum per locally managed (uniform) tablespace 2 GB * physical block size (with K/M modifier); 2 GB (without K/M modifier)
Database file size Maximum Operating system dependent. Limited by maximum operating system file size; typically 222 or 4 MB blocks
MAXEXTENTS Default value Derived from tablespace default storage or DB_BLOCK_SIZE initialization parameter
MAXEXTENTS Maximum Unlimited
Redo Log Files Maximum number of logfiles Limited by value of MAXLOGFILES parameter in the CREATE DATABASE statement Control file can be resized to allow more entries; ultimately an operating system limit
Redo Log Files Maximum number of logfiles per group Unlimited
Redo Log File Size Minimum size 4 MB
Redo Log File Size Maximum Size Operating system limit; typically 2 GB
Tablespaces Maximum number per database 64 K Number of tablespaces cannot exceed the number of database files because each tablespace must include at least one file
Bigfile Tablespaces Number of blocks A bigfile tablespace contains only one datafile or tempfile, which can contain up to approximately 4 billion ( 232 ) blocks. The maximum size of the single datafile or tempfile is 128 terabytes (TB) for a tablespace with 32 K blocks and 32 TB for a tablespace with 8 K blocks.
Smallfile (traditional) Tablespaces Number of blocks A smallfile tablespace is a traditional Oracle tablespace, which can contain 1022 datafiles or tempfiles, each of which can contain up to approximately 4 million (222) blocks.
External Tables file Maximum size Dependent on the operating system.An external table can be composed of multiple files.

Process and Runtime Limits

Item Type of Limit Limit Value
Instances per database Maximum number of cluster database instances per database Operating system-dependent
Locks Row-level Unlimited
Locks Distributed Lock Manager Operating system dependent
SGA size Maximum value Operating system-dependent; typically 2 to 4 GB for 32-bit operating systems, and > 4 GB for 64-bit operating systems
Advanced Queuing Processes Maximum per instance 10
Job Queue Processes Maximum per instance 1000
I/O Slave Processes Maximum per background process (DBWR, LGWR, etc.) 15
I/O Slave Processes Maximum per Backup session 15
Sessions Maximum per instance 32 KB; limited by the PROCESSES and SESSIONS initialization parameters
Global Cache Service Processes Maximum per instance 10
Shared Servers Maximum per instance Unlimited within constraints set by the PROCESSES and SESSIONS initialization parameters, for instance
Dispatchers Maximum per instance Unlimited within constraints set by PROCESSES and SESSIONS initialization parameters, for instance
Parallel Execution Slaves Maximum per instance Unlimited within constraints set by PROCESSES and SESSIONS initialization parameters, for instance
Backup Sessions Maximum per instance Unlimited within constraints set by PROCESSES and SESSIONS initialization parameters, for instance

PL/SQL Compiler Limits

Item Limit
bind variables passed to a program unit 32768
exception handlers in a program unit 65536
fields in a record 65536
levels of block nesting 255
levels of record nesting 32
levels of subquery nesting 254
levels of label nesting 98
levels of nested collections no predefined limit
magnitude of a PLS_INTEGER or BINARY_INTEGERvalue -2147483648..2147483647
number of formal parameters in an explicit cursor, function, or procedure 65536
objects referenced by a program unit 65536
precision of a FLOAT value (binary digits) 126
precision of a NUMBER value (decimal digits) 38
precision of a REAL value (binary digits) 63
size of an identifier (characters) 30
size of a string literal (bytes) 32767
size of a CHAR value (bytes) 32767
size of a LONG value (bytes) 32760
size of a LONG RAW value (bytes) 32760
size of a RAW value (bytes) 32767
size of a VARCHAR2 value (bytes) 32767
size of an NCHAR value (bytes) 32767
size of an NVARCHAR2 value (bytes) 32767
size of a BFILE value (bytes) 4G * value of DB_BLOCK_SIZE parameter
size of a BLOB value (bytes) 4G * value of DB_BLOCK_SIZE parameter
size of a CLOB value (bytes) 4G * value of DB_BLOCK_SIZE parameter
size of an NCLOB value (bytes) 4G * value of DB_BLOCK_SIZE parameter



January 3, 2011

2010 in review

Filed under: banco de dados — agleite @ 11:43 am

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Minty-Fresh™.

Crunchy numbers

Featured image

A helper monkey made this abstract painting, inspired by your stats.

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 2,700 times in 2010. That’s about 6 full 747s.

 

In 2010, there were 7 new posts, growing the total archive of this blog to 48 posts.

The busiest day of the year was September 9th with 34 views. The most popular post that day was Data Guard | Papers.

Where did they come from?

The top referring sites in 2010 were google.com.br, diaadiaoracle.com.br, rodrigoalmeida.net, twitter.com, and en.wordpress.com.

Some visitors came searching, mostly for logminer, oracle logminer, logminer oracle, alessandro guimarães, and oracle vs sql server.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Data Guard | Papers August 2010

2

Log Miner | Muito além do FlashBack August 2009
2 comments

3

Indices e Estatisticas July 2008

4

Evolução do Gerenciamento de Memória no Oracle September 2008

5

Data Guard | Modos de Proteção May 2009
6 comments

September 5, 2010

Oracle | Bugs Esquecidos

Filed under: banco de dados — Tags: , , , — agleite @ 10:23 am

Esta semana me deparei com a seguinte situação: Migrar uma base Oracle Standard Edition 9.2 .0.1.  para 10.2.0.4

No script utilizado para exportação da base o parametro buffer estava para 800000. Para aqueles que não estão familiarizados com export, buffer determina em bytes o numero maximo de linhas em um array capturado pelo export. Se você, por exemplo, colocar 0 (zero) o export traz uma linha por vez.

Assim que olhei o parametro pensei: “Muito pequeno, vou aumentar e o export vai ser mais rapido”

Alterei entao de 800k para 80M . Como podes notar não aumentei muito por que existia uma limitação de memória no servidor.Mesmo assim isso deveria da para tornar a exportação mais rapida. Comecei então o export. Tudo ia bem até em uma determinada tabela onde o export parecia estar travado. Um olhadinha em v$session_wait (9i)  e o evento de espera para a sessão era SQL*Net message from client. Por curiosidade fui ver quantas linhas tinha esta tabela e o resultado foi 0(zero) linhas. Depois de uns 4 minutos o export voltou a fazer seu trabalho, no entanto voltou a travar novamente em uma outra tabela que também estava com zero linhas.

Search mental e…lembrei que na 9.2 tinha algum bug sobre export lentos com colunas CLOB. No entanto nenhuma das duas tabela de alguma coluna do tipo LOB. Apelei para o Metalink e achei :

ALERT: EXPORT with large BUFFER Can Silently Produce a Dump File with Corrupted Data [ID 223399.1]

Versões afetadas : 8.1.7.3 8.1.7.4  9.0.1.4  9.2.0.1 9.2.0.2

==>  data corruption *can* occur if: BUFFER = 3200000 (or higher)

Não tive duvidas e voltei o parametro para o valor inicial de 800K. Export executou como uma bala.

Older Posts »

The Silver is the New Black Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 79 other followers