Menu de navegação

[ramasineParticipante]

Bom dia!
Galera, tem um DW aqui que tem dados algumas dores de cabeça!
Aquele delete do outro post foi neste banco de dados.

O outro DBA tá enrolando e não quer pegar nesse pepino, pois eu vou fazer!
Queria a ajuda de vcs, para ver qual a melhor forma de começar a analisar esse cara. Sei que historicamente existem algumas parãmetros e algo do gênero que podemos modificar, como db_file_multiblock_read_count, que no meu caso está com 32..etc..

A aplicação faz uso do Discoverer…ainda estou buscando aprender mais como funciona esta ferramenta, a questão dos cadernos..etc
Também há o Logminer, do qual uma das aplicações faz uso…neste banco!

Alguns dados:

Oracle Enterprise Edition 10.2.0.3 em AIX 5.

Tablespace de UNDO: 11 Gb
Tablespace TEMP: 6Gb
Undo_retention: 900
sga_max_size big integer 2097152000
sga_target big integer 2097152000

Algumas coisas já começei a fazer, identificar as maiores tabelas e sugerir seu particionamento, isso já está em fase de testes, e me parece que vai bem, sugeri o range partition, pq há colunas de data em quase todas as tabelas….estão testando a criação por ano…os deletes tem sido bem mais rápidos…

Tenho procurado capturar e analisar as queries pesadas e sugerir modificações…

Mas tem mais alguma coisa, a nível maior..que possa ser feito para melhorar a performance de um DW ?

Abraço a todos.!

Ps: Rodrigo, boa..Senhor dos Anéis…rssssssss, me sinto o próprio Frodo, mas sem aquele chato do lado, prefiro uma boa “rapariga” !!!

[vieriParticipante]

qto de memôria RAM tem esse servidor ?
pode aumentando essa sga e jogando o buffer cache para 80%dela(SGA) !!

[vieriParticipante]

Como está a pga ? work_area_size_policy ?
manda um select na v$parameter para analisarmos seus parâmetros
se condizem com um ambiente de B.I .

[ramasineParticipante]

Como pedido!

processes 3 150
sessions 3 170
timed_statistics 1 TRUE
timed_os_statistics 3 0
resource_limit 1 FALSE
license_max_sessions 3 0
license_sessions_warning 3 0
cpu_count 3 4
sga_max_size 6 2097152000
pre_page_sga 1 FALSE
shared_memory_address 3 0
hi_shared_memory_address 3 0
use_indirect_data_buffers 1 FALSE
lock_sga 1 TRUE
shared_pool_size 6 0
large_pool_size 6 0
java_pool_size 6 0
streams_pool_size 6 0
shared_pool_reserved_size 6 11744051
java_soft_sessionspace_limit 3 0
java_max_sessionspace_size 3 0
spfile 2 /u01/apps/oradba/product/10.2.0/dbs/spfileBPODWH.ora
instance_type 2 RDBMS
trace_enabled 1 TRUE
nls_language 2 PORTUGUESE
nls_territory 2 PORTUGAL
nls_length_semantics 2 BYTE
nls_nchar_conv_excp 2 FALSE
filesystemio_options 2 SETALL
disk_asynch_io 1 TRUE
tape_asynch_io 1 TRUE
dbwr_io_slaves 3 0
backup_tape_io_slaves 1 FALSE
file_mapping 1 FALSE
gcs_server_processes 3 0
sga_target 6 2097152000
control_files 2 /dev/rBPODWHobjctl01, /dev/rBPODWHobjctl02, /dev/rBPODWHobjctl03
control_file_record_keep_time 3 7
db_block_buffers 3 0
db_block_checksum 2 TRUE
db_block_size 3 8192
db_cache_size 6 0
db_2k_cache_size 6 0
db_4k_cache_size 6 0
db_8k_cache_size 6 0
db_16k_cache_size 6 0
db_32k_cache_size 6 0
db_keep_cache_size 6 0
db_recycle_cache_size 6 0
db_writer_processes 3 1
db_cache_advice 2 ON
max_commit_propagation_delay 3 0
compatible 2 10.2.0.3.0
remote_archive_enable 2 true
log_archive_start 1 FALSE
log_archive_dest_1 2 LOCATION=/u02/oradbf/BPODWH/arch mandatory reopen=300
log_archive_dest_state_1 2 enable
log_archive_dest_state_2 2 enable
log_archive_dest_state_3 2 enable
log_archive_dest_state_4 2 enable
log_archive_dest_state_5 2 enable
log_archive_dest_state_6 2 enable
log_archive_dest_state_7 2 enable
log_archive_dest_state_8 2 enable
log_archive_dest_state_9 2 enable
log_archive_dest_state_10 2 enable
log_archive_max_processes 3 2
log_archive_min_succeed_dest 3 1
standby_archive_dest 2 ?/dbs/arch
log_archive_trace 3 0
log_archive_local_first 1 TRUE
log_archive_format 2 BPODWH_%t_%s_%r.arch
log_buffer 3 14254080
log_checkpoint_interval 3 0
log_checkpoint_timeout 3 1800
archive_lag_target 3 0
db_files 3 200
db_file_multiblock_read_count 3 32
read_only_open_delayed 1 FALSE
cluster_database 1 FALSE
parallel_server 1 FALSE
parallel_server_instances 3 1
cluster_database_instances 3 1
db_recovery_file_dest_size 6 0
standby_file_management 2 MANUAL
thread 3 0
fast_start_io_target 3 0
fast_start_mttr_target 3 0
log_checkpoints_to_alert 1 FALSE
recovery_parallelism 3 0
logmnr_max_persistent_sessions 3 1
db_flashback_retention_target 3 1440
dml_locks 3 748
ddl_wait_for_locks 1 FALSE
replication_dependency_tracking 1 TRUE
instance_number 3 0
transactions 3 187
transactions_per_rollback_segment 3 5
undo_management 2 AUTO
undo_tablespace 2 UNDOTBS1
undo_retention 3 900
fast_start_parallel_rollback 2 LOW
resumable_timeout 3 0
db_block_checking 2 FALSE
recyclebin 2 on
serial_reuse 2 disable
ldap_directory_access 2 NONE
os_roles 1 FALSE
max_enabled_roles 3 150
remote_os_authent 1 FALSE
remote_os_roles 1 FALSE
O7_DICTIONARY_ACCESSIBILITY 1 TRUE
remote_login_passwordfile 2 EXCLUSIVE
license_max_users 3 0
audit_sys_operations 1 FALSE
global_names 1 FALSE
distributed_lock_timeout 3 60
commit_point_strength 3 1
instance_name 2 BPODWH
service_names 2 BPODWH
dispatchers 2 (PROTOCOL=TCP) (SERVICE=BPODWHXDB)
shared_servers 3 1
cursor_space_for_time 1 FALSE
session_cached_cursors 3 20
remote_dependencies_mode 2 TIMESTAMP
plsql_v2_compatibility 1 FALSE
plsql_compiler_flags 2 INTERPRETED, NON_DEBUG
plsql_native_library_subdir_count 3 0
plsql_warnings 2 DISABLE:ALL
plsql_code_type 2 INTERPRETED
plsql_debug 1 FALSE
plsql_optimize_level 3 2
job_queue_processes 3 10
parallel_min_percent 3 0
create_bitmap_area_size 3 8388608
bitmap_merge_area_size 3 1048576
cursor_sharing 2 EXACT
parallel_min_servers 3 0
parallel_max_servers 3 80
parallel_execution_message_size 3 2152
hash_area_size 3 131072
shadow_core_dump 2 partial
background_core_dump 2 partial
background_dump_dest 2 /u01/apps/oradba/admin/BPODWH/bdump
user_dump_dest 2 /u01/apps/oradba/admin/BPODWH/udump
max_dump_file_size 2 UNLIMITED
core_dump_dest 2 /u01/apps/oradba/admin/BPODWH/cdump
use_sigio 1 TRUE
audit_file_dest 2 /u01/apps/oradba/admin/BPODWH/adump
object_cache_optimal_size 3 102400
object_cache_max_size_percent 3 10
session_max_open_files 3 10
open_links 3 4
open_links_per_instance 3 4
optimizer_features_enable 2 10.2.0.3
audit_trail 2 NONE
sort_area_size 3 65536
sort_area_retained_size 3 0
db_name 2 BPODWH
db_unique_name 2 BPODWH
open_cursors 3 300
sql_trace 1 FALSE
os_authent_prefix 2 ops$
optimizer_mode 2 ALL_ROWS
sql92_security 1 FALSE
blank_trimming 1 FALSE
star_transformation_enabled 2 TRUE
parallel_adaptive_multi_user 1 TRUE
parallel_threads_per_cpu 3 2
parallel_automatic_tuning 1 FALSE
optimizer_index_cost_adj 3 100
optimizer_index_caching 3 0
query_rewrite_enabled 2 TRUE
query_rewrite_integrity 2 enforced
sql_version 2 NATIVE
pga_aggregate_target 6 418381824
workarea_size_policy 2 AUTO
optimizer_dynamic_sampling 3 2
statistics_level 2 TYPICAL
skip_unusable_indexes 1 TRUE
optimizer_secure_view_merging 1 TRUE
aq_tm_processes 3 0
hs_autoregister 1 TRUE
dg_broker_start 1 FALSE
drs_start 1 FALSE
dg_broker_config_file1 2 /u01/apps/oradba/product/10.2.0/dbs/dr1BPODWH.dat
dg_broker_config_file2 2 /u01/apps/oradba/product/10.2.0/dbs/dr2BPODWH.dat
olap_page_pool_size 6 0
asm_power_limit 3 1
sqltune_category 2 DEFAULT

[Rodrigo AlmeidaParticipante]

Marcelo,

Segue algumas dicas sobre DW:

HARDWARE
========

O servidor deve ter muita memória e CPU, pois o DW por natureza consome muitos esses recursos devido ao alto processamento de dados e a instruções SQL e PL/SQL que são executadas que necessita de memória.

O hardware deve estar de modo exclusivo para o banco de dados que se encarregará de suportar o DW da empresa, pois o DW também tem um alto consumo de DISCO, naturalmente pelo seu tamanho e tráfego de REDE, pois caso tenha servidores de apoio, como um Data Mart, Data Mining, SAS, Discover, Cube Apps e etc, irá gerar um alto tráfego, então fique de olho nisso.

BANCO DE DADOS PARA DW
===================

Como dito, consumo de área temporária e UNDO é normal e elevado mesmo, isso é normal, existem DWs que a área temporária chega a ser 1/4 do tamanho da base devido aos tipos de processamento e configuração utilizada no ETL.

Outro ponto que deve ser levado em consideração, seja com os projetistas, se está utilizando o modo Snow flake ou Start Schema, pois dependendo do modelo de dados que o seu DW está utilizando, você pode configurar a instância de acordo com o modelo utilizado.

Exemplo, é um parâmetro chamado star_transformation_enabled, que trabalha bem com as dimensões e eu diria a “NORMALIZAÇÂO” do modelo Start Schema.

Onde esse parâmetro pode impactar se utilizar Snow Flake, onde as dimensões trabalham de forma diferente sobre as tabelas de fato.

Tabelas de FATO
===========

Esse é o calcanhar de aquiles no DW, as tabelas de FATO, por natureza, são enormes e vão dar origens as suas dimensões, então, essas tabelas DEVEM SIM, ser particionadas de acordo com a regra de negócio do DW.

Geralmente são SUBPARTICIONADAS por Mês (Range Partition) e a coluna que será a chave de Particionamento (Hash Parition), e alocadas em diferentes tablespaces conforme o ciclo de vida da informação no DW. A latência de dados que será armazenada.

Evite utilizar muitos índices nas FATOS, pois desde consumir muito espaço em disco, operações de INSERT do ETL ficaram mais lentas impactando no processo no geral! O número de índice irá depender de ambiente para ambiente.

Geralmente suas tablespaces possuem uma blocagem diferente, de 32KB, habilitando assim o Buffer para blocos de 32KB, por armazenar grande quantidade de informação.

DIMENSÕES
========

Alocadas sempre em tablespaces diferentes e com blocagem diferente, 8KB para baixo, pois pega apenas as informações necessárias das FATOS organizados os dados para outros processos ou relatórios.

As dimensões trabalham muito mais em memória, usando o SORT, PGA e SHARED_POOL. Por isso, esses parÂmetros serão alterados.

Para achar um valor adequado, use o AWR (10g) ou Statspack (8i/9i) para analisar o consumo das querys vindas das Dimensões.

Um detalhe importante é o uso do SQL MODEL, que tem um utilização anormal para MERGE JOINS e uso de SORT para agragação dos dados para os relatórios.

DICAS PARA INSTÂNCIA
================

• Trabalhar com Paralelismo nos processos de ETL, configurar os parâmetros parallel_max_servers, parallel_threads_per_cpu e parallel_min_servers de acordo com a quantidade de CPU.

• Trabalhar em NOARCHIVELOG, a recuperação é apartir de backup FULL ou por arquivos de FLAT FILE ou outra arquivo de carga para o DW.

• Distribuição dos datafiles entre os Volumes do Storage.

• db_writer_processes para um valor que a controladora suporte!

• Use sempre HBA!

  E acho que é isso… hehehehe…

  Abraços,

[ramasineParticipante]

Galera,

Tirei um AWR do meu DW..

de cara já vi:

miss de library cache (57%) na sql_area
muita contenção de dicionario em tabelas DC% o % de miss deveria ser abaixo de 2% tem coisa com 100%
Execute to Parse %: 71.17….

Vcs podem dar uma palpitada ai?
Publiquei o report no endereço abaixo:

http://dbaoracleramasine.blogspot.com/

Agradeço qq comentário!

[vieriParticipante]

ramasine percebi 3 coisas.

Vc está fazendo backup com rman em qual horário ?
está com compress?

e a coleta de etatistica roda junto com o bkp ?

Tente cursor_sharing = force; para ver se diminiu um pouco seus latch’s ….

[ramasineParticipante]

Fala Vieri, bom dia!
Vou checar essas informações e retorno!
Fiquei meio “fora do ar”…gripado em casa, mas não era a suína..rss!

Obrigado!

[David SiqueiraParticipante]

Marcelo, como vai tudo beleza?
Suas aplicações são em produtos Oracle (Forms e Reports) ou produtos não Oracle( Delphi, .Net, etc)

Caso sejam do tipo não-oracle (não nativas) , essa contenção na Library Cache pode ser ocasionada pelo BIND MISMATCH, muito frequente em aplicações Não Oracle, onde o seu Banco de Dados não consegue reaproveitar de maneira eficiente os comandos passados via Aplicação, forçando assim uma reavaliação do plano de execução, mesmo que esse seja identico ao anterior, o que vai geranro degradação na Library Cache.

Isso pode ser contornado com a adaptação do parametro CURSOR_SHARING para EXACT ou FORCE, isso você terá que adaptar de acordo com a necessidade e os testes de performance que você realizará em seu ambeinte, já passei por isso, tinha um Banco em 10.2.0.1 e a aplicação era DELPHI, usava cursor_sharing como SIMILAR, e tinha um indice muito alto de BIND_MISMATCH, alterei para EXACT e tive um bom resultado.

Abraço. Espero que minha contribuição o ajude.

[Autor]

Posts