Esse post abaixo teve alguns comentários muito interessantes, resolvi publicar esse pois tem muito comentário e vale a pena ler. Bom proveito.
—- Na integra! —-
Um novo comentário ao artigo “IBM DB2 Workshop for Oracle Professionals – Part 1” está à espera da sua aprovação!
Autor: Ricardo Portilho Proni
Email : [email protected]
URL : http://nervinformatica.com.br/
Comentário:
“A compressao de dados no DB2 é melhor pois comprimi tudo que existe no database, diferente do Oracle…”
Retirado da documentação:
Oracle 11gR2 comprime dados, índices e LOBs (além de Backup e Log para Data Guard):
Oracle Advanced Compression provides comprehensive data compression capabilities to compress all types of data, backups, and network traffic in an application transparent manner. With Advanced Compression, Oracle includes table compression targeted at OLTP workloads, resulting in reduced storage consumption and improved query performance while incurring minimal write performance overhead. Advanced Compression can be used to compress any unstructured content using SecureFiles Compression.
DB2 LUW 9.7 comprime dados, índices, e parte dos LOBs (além de Backup):
Data stored in base table rows and log records is eligible for row compression. In addition, the data in XML storage objects is eligible for compression. LOB data that you place inline in a table row can be compressed; however storage objects for long data objects are not compressed.
——————–
“Com a compressao, a reorganizacao de tabelas nao se faz mais necessario.”
A reorganização (com a finalidade de habilitar a compressão) era necessária no DB2 LUW 9.1, para que se criasse um dicionário de dados estático com os dados existentes na tabela. Na versão 9.5, um dicionário é criado automaticamente quando uma tabela atinge 1MB de dados inseridos, e passa a comprimir os dados baseados neste dicionário. Mas pense que se seus dados mudarem muito, o dicionário de compressão continua o mesmo, ou seja, pode passar a nem comprimir mais.
Era desta forma (com dicionário estático) que a compressão no Oracle antes do 11gR2 funcionava: a chamada compressão OLAP, pois só comprimia o que vinha em uma carga de dados, como CTAS ou SQL*Loader. No 11gR2 passou a levar em conta apenas os dados de um block de dados, o que teoricamente deve comprimir menos por possuir menos dados para comparação, mas não tem o problema da alteração da proporção dos dados em relação ao dicionário.
Retirado da documentação:
DB2 LUW 9.7:
Row compression uses a static dictionary-based compression algorithm to compress data by row. The dictionary is used to map repeated byte patterns from table rows to much smaller symbols; these symbols then replace the longer byte patterns in the table rows. The compression dictionary is stored along with the table data rows in the data object portions of the table.
Oracle 11gR2:
You can store heap-organized tables in a compressed format that is transparent for any kind of application. Compressed data in a database block is self-contained, which means that all information needed to re-create the uncompressed data in a block is available within the block. A block is also compressed in the buffer cache. Table compression not only reduces the disk storage but also the memory usage, specifically the buffer cache requirements. Performance improvements are accomplished by reducing the amount of necessary I/O operations for accessing a table and by increasing the probability of buffer cache hits.
—–
DB2 tem outras vantagens muito boas. Por exemplo, a integração real com TSM (os Archives podem ser enviados diretamente para Fita) e AIX (você pode configurar o DB2 para utilizar automaticamente toda a memória que o DB2 tiver, sem utilizar Swap, e se beneficiar da compressão de RAM do SO no AIX 7.0). Ou a criação (e posterior eliminação) automática de Redo Logs secundários, o que minimiza o problema de lentidão no Oracle por falta de Redo Logs (o evento Checkpoint Not Complete).
O DB2 possui um BACKUP DATABASE real, enquanto no Oracle isto é uma coleção de DATAFILEs (você pode ter apenas meio backup de DATABASE na mão).
Já não encontrei comparação à OWI no Oracle, que possibilita Tuning sem Checklist no DB2.
Também faz falta no DB2 algo equiparável ai Rolling Upgrade com o Oracle Data Guard, ou sua flexibilidade (até 30 Standby, Cascaded Standby, Logical Standby, Snapshot Standby).
http://download.oracle.com/docs/cd/E11882_01/license.112/e10594/options.htm#DBLIC142
http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/build_db.htm#PFGRF94152
——- x ———-
Obrigado Portilho pelo apoio.
Att,
capin
Capin e Portilho,
A título de complemento, para feature compress no DB2 LUW temos 3 tipos na versão 9.7: Tabela, Índice e backup: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.dbobj.doc%2Fdoc%2Fc0054539.html
Para Rolling Updates no DB2 achei esta documentação que fala o que é possível fazer no HADR:
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.ha.doc%2Fdoc%2Ft0011766.html
abs,
Alexandre Torres.
Alexandre,
valeu, obrigado.
Abraços
capin
Oi Alexandre.
Veja o que diz no link que você enviou sobre Rolling Upgrade.
This procedure will not work to migrate from an earlier to a later version of a DB2 database system; for example, you cannot use this procedure to migrate from a version 8 to a version 9 database system. You can use this procedure to update your database system from one modification level to another only, for example by applying a fix pack.
Agora veja o Rolling Upgrade do Oracle:
Starting with Oracle Database 10g release 1 (10.1.0.3), you can use a logical standby database to perform a rolling upgrade of Oracle Database 10g software. During a rolling upgrade, you can run different releases of an Oracle database on the primary and logical standby databases while you upgrade them, one at a time, incurring minimal downtime on the primary database.
Ou seja, o do DB2 é equivalente à aplicação de OPatch (CPU Patch, por exemplo) sem indisponibiilidade do Oracle RAC, mas não equivalente ao Rolling Upgrade do Oracle Data Guard, onde você pode passar de 10gR1 para 11gR2 (por exemplo), apenas com a indisponibilidade do Switch.
Sobre a compressão, me lembrei que a do DB2 para backup comprime muito mais do que a do Oracle (testei em dois bancos SAP de 500GB), e é mais inteligente sobre o uso de processadores para isto.
Oi Portilho!
Só para ficar claro no Data Guard é possível a atualização através do Oracle Rolling Upgrade de apenas release ==> release ou também version ==> version? Como citado acima “onde você pode passar de 10gR1 para 11gR2 (por exemplo)”.
No DB2 como a aplicação de um fix pack pode ser uma atualização de release, fix pak 10 (se não me engano) do DB2 8 – de DB2 8.1 para 8.2; pode ser que seja possível a mudança entre releases no DB2 no HADR apenas fazendo switch e deixando um “cara” ativo. Mas é questão de tentar fazendo um lab.
vlw pelas infos!
Abs,
Alexandre Torres.
Oi Alexandre.
Sim, com o Oracle Data Guard, através de um Data Guard lógico, pode passar de 10.2.0.1 (10gR2) para 11.2.0.2 (11gR2), por exemplo. Isto só a partir do 10gR1.
A nomenclatura de correções do Oracle é o seguinte:
– Patch: não altera a versão (10.2.0.1, por exemplo), é aplicado com o utilitário OPatch.
– CPU Path: Conjunto trimestral de correções críticas de segurança, também aplicado com OPatch.
– PatchSet: é um upgrade de binários e database completo, tanto de 10.2.0.1 para 10.2.0.5 quanto de 10.2.0.1 para 11.2.0.2. Esta aplicação é com um instalador, e é separada do upgrade do banco de dados.
– PSU: PatchSet Update: é uma reaplicação de um mesmo Patchset, não muda a versão (10.2.0.1 fica 10.2.0.1).
Achei esta página do DB2 sobre os FixPack, mas não ficou claro a mudança de versão.
Vou aplicar um FixPack agressivo (FixPack 10 do 9.1) e testar.
https://www-304.ibm.com/support/docview.wss?uid=swg27007053
Abraço !
Oi Alexandre.
O RedBook SG24-7363-00 explica como fazer aplicação de FixPack sem indisponibilidade, mas o capítulo 7.2 diz o seguinte:
A rolling upgrade isn’t supported between DB2 version OR major subversion
upgrades, such as version 8.2 to 9.1. For these events, plan for a database
outage while the primary database is updated.
show Portilho! Dúvidas sanadas.
abs
Queria voltar na compressão do Oracle.
A compressão do Oracle é feita somente a nivel de page level, ou seja, o Oracle nao procura por padroes em page levels diferente. Isso faz com que o Oracle nao consiga buscar por padroes na tabela inteira.
Por este motivo o Oracle nao consegue varrer uma tabela e identificar padroes. Se um valor 1000 por exemplo, se repetir 1.000.000 de vezes o Oracle ira apenas identificar os valores 1000 que estao no mesmo page level, ou seja , o resto que sobra cria um novo padrao…..nao acredito que esse algoritmo de resolucao seja mto bom….mas espero que alguem me esclareca esse ponto…obrigado….
Sobre o OWI, o DB2 possui o Workload Management. Depois deem uma olhada…
Voce tambem pode utilizar o DB2TOP ou DB2PD para monitorar essas atividades…Pra quem gosta de SQL vc tambem pode utilizar as views administrativas para sessao…..
Migrado para o Certificação BD em 08/05/2012 por Capin!