Brazil Condition Based Tax Calculation V1.9

DB2 LUW and SAP
Funcionalidades e características
únicas do DB2 para ambientes SAP
Eduardo Akisue
WW DB2/SAP Technical Sales
akisue@us.ibm.com
IBM Corporation Page 1 3/21/2011

DB2 LUW and SAP
Disclaimer & Trademarks
© Copyright 2009 IBM Corporation. All Rights Reserved.

Neither this documentation nor any part of it may be copied or reproduced in any form
or by any means or translated into another language, without the prior consent of all of the
above mentioned copyright owners.
IBM makes no warranties or representations with respect to the content hereof and specifically
disclaims any implied warranties of merchantability or fitness for any particular purpose. IBM
assumes no responsibility for any errors that may appear in this document. The information
contained in this document is subject to change without any notice. IBM reserves the right to
make any such changes without obligation to notify any person of such revision or changes. IBM
makes no commitment to keep the information contained herein up to date.
The information in this document concerning non-IBM products was obtained from the
supplier(s) of those products. IBM has not tested such products and cannot confirm the accuracy
of the performance, compatibility or any other claims related to non-IBM products. Questions
about the capabilities of non-IBM products should be addressed to the supplier(s) of those].
References in this publication to IBM products or services do not imply that IBM intends to
make them available in all countries in which IBM operates.
Trademarks
DB2, DB2 Universal Database, AIX, the ebusiness logo, IBM, the IBM logo, xSeries, and the
eServer logo are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries or both.
A full list of U. S. trademarks owned by IBM may be found at http://
iplswww.nas.ibm.com/wpts/trademarks/trademar.htm.
Linux is a registered trademark of Linus Torvalds.
SAP, R/3 and all other SAP product and service names mentioned herein are trademarks or
registered trademarks of SAP AG in Germany and several other countries.
Oracle is a registered trademark of Oracle Corporation in the United Status and/or other
countries.
UNIX is a registered trademark of The Open Group in the United States and/or other
countries.
Java and all Java- based trademarks and logos are trademarks of Sun Microsystems, Inc. in
the United States and/ or other countries.
Other company, product or service names may be trademarks or service marks of others.

DB2 LUW and SAP
Introdução
Desde 2004 a IBM e SAP tem fortalecido sua relação de parceria, e dessa aliança nasceu a
primeira versão do DB2 conhecido como “Otimizado para SAP”. Dessa versão (8.2.2) surgiram o
DB2 9.1, 9.5, 9.7 e 9.8 (DB2 9.7 com pureScale), que mantiveram o mesmo conceito de
integração e otimização para SAP.
Além das diversas funcionalidades oferecidas pelo DB2, é importante salientar como a SAP
as explora em suas solucões. A forte parceria entre IBM e SAP garante que a tecnologia
disponibilizada pelo DB2 seja prontamente integrada em aplicações SAP.
Este documento foi criado com o objetivo de apontar e descrever funcionalidades técnicas
únicas do DB2 para um ambiente SAP Netweaver.
Os pontos mencionados nesse documento são suportados por notas técnicas da SAP, que
serão citadas em cada seção.
Inovação tecnológica
A IBM e a SAP tem o compromisso de fornecer a melhor e mais nova tecnologia para seus
clientes, por isso planejam o desenvolvimento de seus produtos em conjunto.
A IBM disponibiliza novas versões do DB2 em curtos períodos de tempo, normalmente a cada
18~24 meses, provendo assim novas funcionalidades no banco de dados que são prontamente
utilizados e explorados pelas aplicações SAP.
O DB2 encontra-se na versão 9.7 (com a opção de instalação da funcionalidade pureScale,
que quando instalada, muda a versção para 9.8), que foi lançada em Junho de 2009 e foi
certificada pela SAP algumas semanas depois (Agosto de 2009). A opção de pureScale (DB2
9.8) está em fase piloto pela SAP nesse momento. O quadro abaixo demonstra a forte sinergia
que existe entre as duas empresas:
DB2 Release and SAP Database Certification

Database (DB) Database GA SAP DB GA GA Comments
Delta
DB2 v8.2.2 April 29, 2005 June 3, 2005 4 weeks 1st DB2 optimized for SAP
Software release
DB2 9 July 28, 2006 Aug 31, 4 weeks 2nd DB2 optimized for SAP
2006 Software release
Backward comp. 3.1I
DB2 9.5 Oct 31, 2007 Dec 20, 7 weeks Optimized for NetWeaver 7.0
2007 SR3
DB2 9.7 19 June 2009 Aug 28 2009 10 Optimized for NW 7.2, NW7.0
weeks EP2 SP2
As novas versões do DB2 também são certificadas para versões antigas de aplicações SAP,
com o objetivo de beneficiar não somente clientes novos ou que estão em fase de atualização de
seus pacotes corporativos, mas também clientes que possuem versões mais antigas que ainda
são suportadas pela SAP. Um exemplo desse compromisso tecnológico é a solução de ERP da
SAP. A versão ERP 6.0 EHP4 (Kernel 7.01), e o DB2 9.7 está disponível e certificado para esse
pacote, em várias plataformas de Sistema Operacional, como AIX, HP-UX, Solaris, Linux e
Windows.

DB2 LUW and SAP
ERP 6.0 EHP4 para NW7.01:
Figure 1: Versões de DB2 para AIX e ERP6.0 EHP4
A versão mais antiga da solução R/3 que segue suportada pela SAP é a R/3 4.6C (Kernel
4.6D_EXT), e esta versão também suporta as versões 9.1, 9.5 e 9.7 do DB2:
R/3 4.6C
Figure 2: Versões de DB2 para AIX e R/3 4.6C
Essas informações podem ser confirmadas no site SAP Product Availability Matrix
No entanto, esse alinhamento de versões do banco de dados com aplicativos SAP não é o
mesmo com o nosso concorrente. A versão mais recente do nosso concorrente foi
disponibilizada em 2007, porém a mesma só foi certificada pela SAP em 2010. Clientes desse
concorrente estiveram presos a uma versão antiga do banco de dados por 2.5 anos!
A comprovação desse fato também pode ser visualizado no site citado acima.
Facilidade de administração do Banco de Dados: Total

integração com o ambiente SAP GUI
A administração de um ambiente de infraestrutura SAP é bastante complexa e requer
profissionais com conhecimento profundo da camada SAP Netweaver (evolução do SAP Basis).
Esses profissionais, conhecidos como SAP Basis (proveniente do antigo nome), em muitos
casos também são responsáveis por conhecer a administração do banco de dados, pois o SAP
Netweaver tem uma relação bastante próxima com o mesmo. Em algumas empresas o próprio
profissional Basis também tem a função de DBA do banco de dados.
O objetivo da IBM e da SAP foi de disponibilizar uma interface intuitiva e poderosa com o
banco de dados, em um ambiente já familiar para o administrador Basis. Essa interface foi
implementada como uma transação SAP, e é chamada de SAP DBA Cockpit. Essa transação é
executada dentro do ambiente SAP GUI, assim como todas as outras transações SAP.
Utilizando essa ferramenta o administrador pode realizar basicamente quase todos os
procedimentos necessários para a manutenção e bom rendimento do banco de dados, como:

DB2 LUW and SAP
• Monitoração de Performance
• Visualização de indicadores históricos de Performance
• Gerenciamento e ajustes de prioridades para cargas de trabalho
• Monitoração e Gerenciamento de espaço
• Visualização e Configuração de parâmetros do banco de dados
• Agendamento de taferas administrativas, como “backups”, atualização de estatísticas e
reorganização de objetos
• Visualização de Alertas disparados pelo sistema de monitoração CCMS da SAP
• Acesso as informações de diagnóstico do banco para suporte em resoluções de
problemas
Figure 3: DBACOCKPIT - Monitoração de Performance

DB2 LUW and SAP
Figure 4: DBACOCKPIT - Monitorção e administração de espaço em disco

DB2 LUW and SAP
Figure 5: DBACOCKPIT - Monitoração e administração de parâmetros de configuração
O SAP DBA Cockpit foi inicialmente desenvolvido para o DB2, sendo que o código inicial da
transação SAP era DB6COCKPIT (DB6 é o nome interno da SAP para o DB2 para Linux, Unix e
Windows), e foi recentemente mudado para DBACOCKPIT pelo fato dessa interface agora estar
disponível para outros fabricantes de bancos de dados.
No entanto, é importante ressaltar que essas interfaces variam muito de um banco de dados
para outro. A ferramenta de administração mais completa segue sendo a do DB2, já que é uma
interface bastante madura e novas funcionalidades são implementadas nessa plataforma
primeiro.
O DBA Cockpit do nosso concorrente é muito mais simples e não contém as mesmas
funcionalidades que se encontram na interface para o DB2. Basicamente o DBA Cockpit do
nosso concorrente é utilizado para monitoração de performance (ST04) e agendamento de
tarefas (DB13).
A grande vantagem de administração do DBA Cockpit do DB2 pode ser comprovada na
comparação desses dois documentos:
Manual SAP do DBA Cockpit do DB2
Manual SAP do DBA Cockpit do concorrente
Para mais informações em relação ao uso dessa poderosa ferramenta de administração no

DB2, sugerimos a leitura do seguinte livro:

DB2 LUW and SAP
Compressão de Dados
Diversos fatores influenciam no tamanho de um banco de dados SAP, como o porte da
empresa, a versão da aplicação SAP utilizada (novas versões contém muito mais tabelas e
consequentemente contribuem para que o banco de dados consuma mais espaço em disco), os
regulamentos impostos pelo governo em relação a manutenção de dados históricos, a utilização
de várias línguas e a representação de caracteres em novas versões SAP (UNICODE, que é a
unica maneira suportada de se utilizar várias línguas na aplicação – MDMP já não é mais
suportado).
Em relação a requerimentos de espaço em disco, vale relembrar também que um “landscape”
SAP é composto de pelo menos 3 sistemas: Produção, Qualidade e Desenvolvimento. Alguns
clientes também optam por ter outros sistemas no mesmo “landscape”, como treinamento e
“sandbox”. Ou seja, é necessário contabilizar todos esses ambientes que compõem o
“landscape” para se availar a real necessidade de armazenamento em disco.
Tendo em conta essa grande demanda por armazenamento em disco, a funcionalidade de
compressão de dados do DB2 pode ajudar de maneira significativa no custo total de manutenção
do ambiente SAP (Total Cost of Ownership).
A compressão de dados do DB2 é baseada em um algoritmo muito eficiente e a tecnologia é
comprovadamente madura, já que essa funcionalidade foi inicialmente implementada no DB2
para alta plataforma (mainframe), e portada para o DB2 para Linux, Unix e Windows (LUW).
Essa funcionalidade no DB2 é completamente suportada pela SAP para todo tipo de solução
(ERP ou BW), fato que não é valido para o nosso concorrente, onde a compressão é somente
certificada para ambientes SAP BW.
A nota SAP 930487 diz o seguinte a respeito do suporte de compressão do DB2:

DB2 LUW and SAP
“You can use row compression with DB2 OEM license without additional costs and for
any table”
Como referências, olhar notas 930487 e 980067

Para comprovar as limitações de uso pela SAP da funcionalidade de compressão do nosso
concorrente, olhar notas 701235, 105047 e 1289494
Algumas citações interessantes dessas notas:
“You can only use table compression in the cases described in note 701235” (Objetos
BW)
“The focus … should clearly be located on the space savings”
“New data will always be stored uncompressed. In order to compress data a DBA has
to do a reorganization of the table (insert as select… or import/export)”
Outra clara vantagem dessa tecnologia no DB2 é a taxa de compressão atingida em certas
tabelas, que pode chegar a 70% ~ 80% (suportado também pela nota 930487).
A profunda integração do DB2 com aplicações SAP também garante uma outra vantagem no
quesito do gerenciamento da compressão, já que esta pode ser administrada diretamente do
DBA Cockpit:
Figure 6: DBACOCKPIT - Compressão de Dados Integrada
A compressão também pode ser administrada por um programa ABAP criado pela SAP
especificamente para suporte da funcionalidade em versões mais antigas do SAP que não
possuem a integração diretamente no DBA Cockpit.
Para utilizar e instalar o programa de compressão, olhar a nota 980067
A versão 9.7 do DB2 também possibilita a compressão de outros objetos de banco de dados,
como índices, tabelas temporárias e dados do tipo LOB inline. Para a compressão de índices, o
DB2 utiliza 3 diferentes algoritmos para máxima compressão, diminuindo o tamanho dos índices
em ate 50%. Tabelas temporárias são automaticamente comprimidas pelo DB2, sem a
necessidade de intervenção do administrador. A compressão de objetos temporários pode

DB2 LUW and SAP
acarretar em um dimensionamento menor de table spaces temporárias, bem como o aumento de

rendimento em consultas SQL pesadas que envolvem a criação de tabelas temporárias para
ordenação dos dados (melhor rendimento de I/O para operações em tabelas temporárias). Tipos
de dados LOB inline também podem contribuir, tanto para a economia de espaço em disco como
para um rendimento melhor nas tabelas que contém esses tipos de dados, já que LOBs inline
também podem ser comprimidos e suas operações sao manipuladas em memória (buffer pool).
Alguns exemplos de compressão em clientes reais que migraram de outras plataformas de
Banco de Dados para o DB2:
Customer Before Compression After Compression
Schaeffler 100 TB under Oracle 100 TB reduced to 60TB under

Group Database DB2.
(German 8TB Largest Database source 8TB reduced to 4.5TB

Engineering) Database after DB2 Migration
with Compression.
Super De Boer 4.7TB ECC under Oracle Reduced to 1.6TB with DB2
(Dutch Compression (66% reduction)
Retailer)
Tellabs 656 GB Oracle BW Production 456 GB DB2 BW Production.
(US Telco) Data Load times cut in half.
Coca Cola 950GB Oracle ERP 575GB Compressed in DB2.

Bottling (US Also included UNICODE
CPG) conversion.
UK Services 1.5TB Oracle ERP 750GB with DB2 Compression

Company
Escalabilidade e processamento paralelo

Atualmente, em uma economia globalizada, é vital para uma empresa conhecer
profundamente o seu negócio e ser ágil em suas decisões para conquistar novos mercados e
clientes. Um número crescente de empresas está adotando tecnologias de “Business
Inteligence” (BI) para suporte de decisões para seus executivos. A SAP também fornece
aplicações de BI, baseado no SAP BW (novo nome para o SAP BI). Outras aplicações OLAP
(Online Analytical Processing) baseadas no SAP BW incluem: SAP SCM, SAP APO e SAP
SEM).
Essas aplicações também são suportadas pela camada SAP Netweaver, e portanto, pelo
banco de dados. Bancos de dados para suporte a decisão tendem a ser muito grandes por
conter grandes quantidades de dados referente ao negócio de uma empresa, portanto é comum
encontrarmos banco de dados BI que atingem a ordem de vários Terabytes em empresas de
grande porte. Outro fator notado atualmente em grandes empresas é a necessidade de se obter
respostas rápidas de seus sistemas de suporte a decisão (“near real time BI”).

DB2 LUW and SAP
Para atender essa necessidade de gerenciamento de grandes quantidades de dados e de

performance, é extremamente importante que o banco de dados que suporte a infraestrutura de
BI possua as funcionalidades para tanto.
O DB2 possui uma tecnologia para processamento paralelo chamado “Database Partitioning
Feature”, ou simplesmente DPF. Essa tecnologia é baseada em uma arquitetura conhecida
como “shared nothing”, onde vários servidores (ou LPARs) trabalham de maneira independente
(memória, CPUs e discos) em partes do banco de dados de maneira paralela. Essa maneira de
trabalho do DPF é baseado no conceito “Divide and Conquer”, que significa basicamente dividir a
carga de trabalho para conquistar o objetivo.
Figure 7: DB2 com DPF - Escalabilidade de até 1000 partições

DB2 LUW and SAP
Figure 8: Paralelismo de execução de consultas em ambiente DPF
A funcionalidade DPF é suportada e utilizada pela SAP em ambientes BW desde a versão

SAP BW 2.0B (a mais nova versão é a 7.0), sendo muito confiável e adotado pela maioria de
clientes SAP BW que utilizam o DB2.
O número máximo de partições ou nós (podem ser físicos ou lógicos) suportados pelo DPF é
1000, ou seja, o DPF provê uma escalabilidade bastante grande para acomodar todo tipo de
aplicação SAP BW.
As maiores implementações de SAP BW a nível mundial utilizam essa tecnologia para
escalabilidade e performance, fato que pode ser confirmado na prova de conceito realizada com
um grande cliente SAP/DB2. Este cliente decidiu provar essa tecnologia em uma base BW de
60TB. Os resultados foram bastante satisfatórios e hoje essa prova é referência para outras
implementações.
Os resultados dessa prova de conceito podem ser confirmadas no redbook entitulado
Infrastructure Solutions: Design, Manage, and Optimize a 60 TB SAP NetWeaver Business
Intelligence Data Warehouse
A nota SAP 374502 possui um conjunto de notas que são relevantes ao DPF e mostram que
a funcionalidade é suportada pela SAP desde a versão SAP BW 2.0B.
Alta Disponibilidade
Estamos vivendo em uma era dominada por informações que fluem pela internet e pelo
comércio eletrönico, em que a cada segundo, milhares de novas transações chegam a sistemas
corporativos para serem processadas. Cada segundo em que esses sistemas não estão
operativos pode significar a perda de muito dinheiro, seja na forma de clientes de internet que
deixam de fazer suas compras em um determinado web site que não está processando
transações, ou por companhias que deixam de publicar seu material de propaganda em um site
que está constantemente em manutenção.
Um dos principais requerimentos de sistemas atuais é que eles sejam altamente disponíveis,
e que atendam as necessidades do negócio. Isso significa que cada vez mais, sistemas críticos
devem estar quase 100% disponíveis, tanto para paradas planejadas (manutenção), quanto para
paradas não planejadas (por exemplo, problemas de Hardware).
O DB2 fornece duas funcionalidades que minimiza o efeito de interrupções no sistema:
DB2 High Availability and Disaster Recovery (HADR):

DB2 LUW and SAP
O DB2 HADR fornece uma maneira simples e direta de se criar um sistema “standby” para o
Banco de Dados. A arquitetura do HADR é baseada em replicação de log buffer, garantindo
assim a rápida sincronização do banco secundário em relação ao banco primário. Como o
servidor secundário está constantemente aplicando transações que estão sendo enviadas pelo
servidor primário, a processo de “failover” é extremamente rápido e transparente para a
aplicação. O processo de “failover” no HADR é realizado em apenas alguns segundos, já que o
banco secundário já está completamente operacional, processos DB2 já estão executando e a
memória já está alocada. Não há a necessidade de reinício do banco ou processo de
recuperação. Em soluções tradicionais de cluster, esse processo pode atingir alguns minutos,
devido a natureza de como essas soluções funcionam (redirecionamento de IP, montagem dos
discos, reinício do banco, processo de recuperação).
Com DB2 HADR também é possivel a atualização de componentes de software (por exemplo,
instalação de Fixpacks do DB2) e hardware sem a necessidade de parada da operação. A idéia
é de se atualizar o servidor secundário primeiro, enquanto o servidor primário segue operativo.
Logo, o secundário volta a se unir ao cluster e automaticamente é resincronizado com o servidor
primário. Troca-se o papel dos servidores (primário passa a ser o secundário e vice-versa) e
aplica-se o mesmo procedimento. Esse método de manutenção sem interrupção é conhecido
como “Rolling Upgrade”. Veja o diagrama abaixo para melhor vizualização:
Figure 9: Manutenção sem interrupção operacional
DB2 pureScale:
DB2 pureScale oferece um novo nível de alta disponibilidade para sistemas SAP OLTP.
Baseado em uma arquitetura de disco compartilhado, essa tecnologica provém da plataforma
conhecida como a mais confiável e altamente disponível do mundo: System Z. pureScale foi
criado com base na arquitetura parallel sysplex do System Z e portado para sistemas POWER e
System X.
DB2 pureScale fornece as seguintes funcionalidades:

DB2 LUW and SAP
• Disponibilidade contínua
• Transparëncia para aplicações (aplicações não precisam ser codificadas
especificamente para o ambiente de cluster)
• Escalabilidade quase linear
• Distribuição de carga de trabalho automática
Um problema em um dos membros do cluster pureScale somente afeta dados “in-flight”, ou

seja, dados que estavam sendo manipulados por esse membro antes do problema. Todos os
outros membros e seus dados não são impactados. O diagrama abaixo representa essa
situação:
Node Failure
DB2 pureScale
100%
Data availability
All other nodes continue to process uninterrupted.

CA instantly knows what pages need recovery.
Surviving node processes log.
Recovery likely requires no I/O and done from memory
0% Time
Figure 10: Impacto no caso de problema em um membro do cluster
Um dos grandes desafios para essa arquitetura de disco compartilhado é a escalabilidade.

Como todos os membros do cluster podem acessar todos os dados do Banco de Dados, é
preciso uma forma muito eficiente para lidar com recursos compartilhados, como buffers e locks.
Quanto mais membros fazem parte desse cluster, mais difícil fica o gerenciamento desses
recursos globais. No DB2 pureScale, esses recursos são gerenciados exclusivamente por um
hardware dedicado, chamado de Cluster Caching Facility (CF). O CF é configurado para que
seja altamente disponível (CF secundário), já que é o componente central e crítico do cluster
pureScale. Devido a esse controle central de recursos, e o uso de funcionalidades de hardware
avançadas, como Remote Direct Memory Access (RDMA), a manipulação de objetos globais é
altamente eficiente e consequentemente acarreta um overhead menor quando novos membros
são adicionados ao cluster. A arquitetura do DB2 pureScale é representado pelo diagrama
abaixo:

DB2 LUW and SAP
Figure 11: Arquitetura do DB2 pureScale
Isso faz com que o DB2 pureScale forceça uma escalabilidade quase linear. Testes internos
demonstram que um cluster pureScale executando uma carga típica OLTP pode ter uma
escalabilidade de 90% ou mais, quando o cluster possui até 12 membros:

DB2 LUW and SAP
Figure 12: Escalabilidade do DB2 pureScale para ambientes OLTP
A SAP criou um programa piloto para clientes interessados na utilização do DB2 pureScale em
sistemas SAP. Para mais informações, veja a nota 1419433
Gerenciamento de cargas de trabalho

Sistemas de banco de dados podem atender uma ou mais soluções SAP, e um mesmo banco
de dados pode ser utilizado por várias aplicações SAP. Essas aplicações podem suportar
diversas áreas de negócio de uma empresa, que em determinados momentos podem ter
prioridades diferentes de processamento.
Mesmo ambientes que possuem bancos de dados dedicados para uma única aplicação SAP
também podem apresentar desafios em relação ao gerenciamento das diferentes cargas de
trabalho, já que todos os usuários e processos SAP dessa aplicação competem pelos mesmos
recursos do sistema de banco de dados.
O DB2 apresenta uma funcionalidade (Workload Management ou WLM) que pode ajudar
muito a priorização de diferentes cargas de trabalho que são processadas no banco de dados. O
WLM é baseado em conceitos como carga de trabalho (“Workload” ) e Classes de Serviço
(“Service Classes”). Para cada carga de trabalho definido no servidor, existe uma classe de
serviço para o seu processamento. As prioridades das classes de serviço podem ser ajustadas
de maneira dinâmica dependendo da necessidade do momento.
A SAP explora essa tecnologia de forma que cada um de seus processos (dialog, batch,
update, spool, etc) sejam definidos como carga de trabalho e sejam associados a classes de
serviços dedicados. Existem também a possibilidade de se criar cargas de trabalho baseados em
usuários ou transações SAP.
A profunda integração entre DB2 e SAP também resultou na implementação do “Workload
Management” (WLM) diretamente no DBA Cockpit. Dessa forma administradores podem definir e

DB2 LUW and SAP
controlar as diferentes cargas de trabalho e suas respectivas prioridades diretamente da mesma

interface que utlizam para as demais tarefas administrativas relacionadas ao banco de dados.
Figure 13: DBACOCKPIT - Funcionalidade de gerenciamento de cargas de trabalho (WLM)

integrada

DB2 LUW and SAP
Figure 14: DBACOCKPIT - Ajuste de prioridades para as classes de serviço
Essa funcionalidade é única no DB2 e para maiores detalhes, existe um artigo técnico
publicado pela SAP chamado SAP on DB2 for LUW: Exploitation of DB2’s Workload
Management in an SAP Environment
Computação autonômica
O intuito da IBM é de minimizar tarefas de administração do DB2, ou seja, o objetivo é que o
banco de dados seja inteligente o suficiente para se auto-configurar mediante situações diversas.
Esse objetivo é compartilhado pela SAP, que espera que cada vez mais o DB2 se torne
“invisível” aos olhos de um administrados SAP Basis.
Para alcançar esse objetivo a IBM e a SAP tem introduzido conceitos autonômicos desde a
instalação até a manutenção do ambiente DB2 e SAP.
Por exemplo, durante a instalação de uma aplicação SAP normalmente o banco de dados
deve ser instalado manualmente para que a execução do instalador SAPINST possa prosseguir.
A partir da versão SAP Netweaver 7.0 SR3, a instalação do DB2 faz parte da instalação da
aplicação SAP, fato que é unico para o DB2. Ou seja, o próprio instalador SAPINST instala e
configura o DB2 de maneira automática. Do manual de instalação SAP extraímos o seguinte:
“SAPinst automatically installs and deinstalls the database software”
A instalação automática do DB2 pelo SAPINST pode ser comprovada no manual de

instalação SAP Netweaver 7.0 EHP1

DB2 LUW and SAP
A mesma integração não é encontrada no nosso concorrente, sendo necessário a instalação

manual do servidor de banco de dados, utilizando-se do instalador e procedimentos do
fabricante.
Esse fato pode ser comprovado no manual de instalação SAP Netweaver 7.0 EHP1 para o
nosso concorrente.
Durante a instalação do DB2 pelo SAPINST o banco de dados criado já é pré-configurado e
otimizado para uma aplicação SAP. Parâmetros de configuração utilizam valores definidos pela
SAP e uma variável de controle do DB2 chamado DB2_WORKLOAD é configurado com o valor
SAP. Isso faz com que vários outros parâmetros de controle sejam automaticamente
configurados para valores já comprovados para um ambiente SAP.
Figure 15: Variáveis configuradas automaticamente por DB2_WORKLOAD=SAP
Essa otimização automática do banco para uma aplicação SAP também é unica para o DB2,
nosso concorrente não possui a mesma integração.
O uso dessa variável pela SAP pode ser confirmada na nota SAP 899322
“For SAP systems you should only set the following registry variable(s) unless you
receive different instructions from SAP support: DB2_WORKLOAD=SAP”
Outras funcionalidades autonômicas no DB2 incluem:

• Gerenciamento automático de espaço em disco – “Automatic Storage Management”
(default)
• Estatísticas automáticas – “Automatic RUNSTATS” (default)
• Gerenciamento automático de memória – “Self Tuning Memory Management” (default)
• Reorganização automática de tabelas e indíces – “Auto REORG” (default para tabelas
menores que 1GB)

DB2 LUW and SAP
Das funcionalidades mencionadas acima, o método de gerenciamento automático de disco é

também disponibilizado pelo nosso concorrente, porém não é suportada pela SAP.
Isso esta documentado na nota SAP 105047
No DB2 o “Automatic Storage Management” não só é suportado pela SAP, mas é uma
funcionalidade habilitada por “default” durante a instalação. Como referência olhar nota 930487
Organização física de dados para melhor rendimento em

consultas de suporte a decisão
Como foi mencionado anteriormente, sistemas OLAP como SAP BW analisam grandes
quantidades de dados e por isso apresentam um grande desafio em relação a performance nos
tempos de resposta de seus relatórios.
Para melhorar o rendimento dessas aplicações, geralmente os dados de grandes tabelas sao
particionados e organizados (“clustered”) de maneira que o banco de dados possa disponibilizar
os dados requisitados pela aplicação OLAP em um tempo de resposta aceitável.
Existem várias tecnicas de particionamento e organização de dados, como por exemplo:
• Range Partitioning
• Hash Partitioning
• Cluster indexes
• Multi-Dimensional Clustering
Nossos concorrentes geralmente utilizam o método de “Range partitioning”. Embora o DB2

suporte todas os métodos mencionados, em um ambiente SAP geralmente não é necessáro a
implementação e uso do método “Range Partitioning”, porque o MDC (Multi-Dimensional
Clustering) oferece uma tecnologia superior e mais eficiente.
Essa preferência também e´compartilhada pela SAP, como podemos comprovar na nota
930487
“You can use DB2 9.1 to partition a table using ranges. Although range partitioning on
other database platforms is typically used for cubes in SAP BI, DB2 offers a better solution
with MDC that, in addition, requires no management. Therefore, SAP BI does not use
range partitioning on DB2”
A grande vantagem do MDC em relação a tecnologia de “Range Partitioning” é o fato de o

MDC suportar o particionamento e organização de uma tabela utilizando-se várias dimensões,
enquanto que o “Range Partitioning” somente permite uma única dimensão.
O MDC cobre de maneira mais eficiente os requisitos de aplicações OLAP, que são
naturalmente baseados em um modelo multi-dimensional. Com isso, consultas em modelos
multi-dimensionais são mais efetivas porque os dados já estão organizados fisicamente em disco
de acordo com as dimensões escolhidas, e portanto a eliminação de blocos de dados não
relevantes a consulta é muito mais eficiente.

DB2 LUW and SAP
Figure 16: Limitação de "Range Partitioning"
Figure 17: MDC - Solução adequada para modelos multi-dimensionais como SAP BW
Para maiores detalhes usar como referência o artigo de recomendações no uso de MDC em
ambientes SAP:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101143

DB2 LUW and SAP
Archiving de dados Near-Line (NLS)

Sistemas SAP BW geralmente são muito grandes, e o gerenciamento dos seus Bancos de
Dados impõem desafios operacionais a seus administradores. Backups se tornam mais
demorados, a performance de consultas demoram mais e podem afetar contratos com usuários
(SLAs), etc.
Para amenizar esse problema a SAP criou o processo de archiving de seus objetos, muito
utilizados por seus clientes. Objetos que são arquivados raramente são utilizados, e por isso não
necessitam estar armazenados no banco BW. Porém existe um outro tipo de objeto que não
pode ser considerado offline (pronto para archiving), mas ao mesmo tempo não é
constantemente utilizado por consultas BW (ou seja, também não é considerado online). Esses
objetos são categorizados pela SAP como objetos near-line (ou near-online). Para esses objetos
a SAP criou o conceito de Near-Line storage (NLS), em que esse tipo de dado pode ser movido
para uma área fora do banco principal BW.
O conceito de NLS é implementado por algumas empresas, utilizando-se hardware dedicados
(appliances), skills específicos e um possível alto custo de implementação. O mesmo conceito de
NLS também foi implementado com o DB2, com as seguintes vantagens:
• O Banco NLS é simplesmente um outro Banco de Dados DB2

• O processador OLAP do SAP BW executa consultas transparentemente nos dois
bancos, caso as condições assim requeiram
• A licença para o banco NLS já está agregada a licença do SAP BW
• A instalação do banco NLS é parte do SAPINST
• Nenhum conhecimento adicional é necessario para se administrar o banco NLS, ele é
simplesmente mais um banco DB2
• O banco NLS pode ser catalogado e administrado diretamente do DBA Cockpit
• Dados movidos para o banco NLS automaticamente usam funcionalidades de
otimização, como MDC e compressão
• Implementação única no DB2

DB2 LUW and SAP
Figure 18: Implementação de NLS com DB2
Para mais informações de NLS com DB2, recomendamos o seguinte documento: Enabling an
SAP NetWeaver BW to use IBM DB2 for Linux, Unix and Windows as Near-Line Storage
Tabela Resumo
Funcionalidade DB2 Concorrente

Inovação Tecnológica - Última versão (DB2 9.5) disponível e - Última versão certificada pela SAP depois de
certificada pela SAP 2.5 anos!
Referências: http://www.service.sap.com/pam Referências: http://www.service.sap.com/pam
Facilidade de - Interface DBA Cockpit foi primeiramente - DBA Cockpit também é oferecido, porém com
administração do banco criada para DB2, com funcionalidades para muito menos funcionalidades.
total administração do banco pelo SAP GUI - Utilizado basicamente para monitoração e
Referências: agendamento de tarefas
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/
library/uuid/c0e16898-8e5c-2b10-7798-f38ccf8da350 Referências:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/
library/uuid/f079d393-a806-2a10-84a4-d821d4ee092c

DB2 LUW and SAP
Compressão de Dados - Alta taxa de compressão e totalmente - Restrito a SAP BW

suportado pela SAP Referências: Notas 701235, 105047 e
Referências: Notas 930487 e 980067
1289494
https://websmp230.sap-
ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/ https://websmp230.sap-
index2.htm?numm=930487 ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/i
ndex2.htm?numm=701235
ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/ https://websmp230.sap-
index2.htm?numm=980067 ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/i
ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/i
Escalabilidade e - Escalabilidade de até 1000 partições Tecnologia semelhante não fornece o mesmo
Processamento Paralelo utilizanbdo-se DPF. grau de escalabilidade
- Adotado pela SAP desde a versão SAP BW
2.0B para melhora de performance
Referências: Nota SAP 374502
ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/
index2.htm?numm=374502
Redbook SAP BW 60TB
http://www.redbooks.ibm.com/abstracts/sg247385.htm
l?Open
Alta Disponibilidade - DB2 HADR forcene failover super rápido. Tecnologia semelhante não fornece o mesmo
DB2 pureScale fornece disponibilidade grau de disponibilidade
contínua, e é transparente a aplicação
Gerenciamento de Cargas - Funcionalidade única no DB2. Integrado ao Tecnologia única a DB2
de trabalho DBACOCKPIT
Referências: Artigo SDN da SAP
https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/
library/uuid/d046f3f5-13c5-2b10-179d-80b6ae7b9657
Computação Autonômica - Instalação automática do DB2 pelo SAPINST. - Instalação manual do banco de dados, não
- Auto-Storage, Auto RUNSTATS, Auto- integrado ao SAPINST.
REORG, STMM
Referências: Manual de instalação SAP
Referências: Manual de instalação SAP
Netweaver 7.0 EHP1 para o nosso
Netweaver 7.0 EHP1 concorrente
https://websmp104.sap- ag.de/~sapidb/011000358700001530352008E
ag.de/~sapidb/011000358700001520722008E
- “Automatic Storage Management” ainda não

- Otimização do banco para aplicações SAP
suportada pela SAP
utilizando a variável DB2_WORKLOAD=SAP

https://websmp230.sap- https://websmp230.sap-
ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/ ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sap

DB2 LUW and SAP
index2.htm?numm=899322 notes/index2.htm?numm=105047
- “Automatic Storage Management” totalmente

suportado pela SAP
Particionamento e - MDC é uma melhor alternativa que “Range - Uso de “Range Partitioning”, limitado a
Organização física de Partitioning”, pois permite a organização física apenas uma dimensão.
dados dos dados por várias dimensões. - Tecnologia baseada em modelos uni-
dimensionais, sendo que SAP BW é baseado
Referências: Nota 930487 em modelos multi-dimensionais.
Artigo de recomendações no uso de MDC

em ambientes SAP
http://www.ibm.com/support/techdocs/atsmastr.nsf/W
ebIndex/WP101143
Archiving de Dados Near- - Implementação única com DB2. Facilita o Funcionalidade única com DB2
Line (NLS) gerenciamento de sistemas BW, melhoria de
performance
Referências adicionais de funcionalidades DB2

suportadas pela SAP:
• Nota 930487: Using DB2 9.1 with SAP Software
• Nota 1089578: Using DB2 Version 9.5 with SAP Software
• Nota 1351160: Using DB2 9.7 with SAP Software
• SAP SDN Community for DB2 for LUW
Referências adicionais de funcionalidades do nosso

concorrente que não são completamentes suportadas
pela SAP:
• Nota 105047: Support for Oracle functions in the SAP environment

DB2 LUW and SAP
Sumário
O bom funcionamento de um sistema SAP depende da infraestrutura e dos profissionais que
o suportam, e nesse sentido o servidor de banco de dados DB2 fornece a tecnologia necessária
para atingir esse objetivo.
Da forte parceria entre IBM e SAP nasceu o DB2 “Otimizado para SAP”, que contém
funcionalidades únicas e importantes para um ambiente SAP, como: Instalação e configuração
automática, características de computação autonômica, alta disponibilidade, compressão de
dados, escalabilidade, entre outras.
Acima de tudo está o compromisso das duas empresas em disponibilizar o melhor ambiente
para aplicações corporativas, baseado nas inovações tecnologicas do IBM DB2 e SAP
Netweaver.

Brazil Condition Based Tax Calculation V1.9

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Brazil Condition Based Tax Calculation V1.9

Încărcat de

Drepturi de autor:

Formate disponibile

DB2 LUW and SAP

IBM Corporation Page 1 3/21/2011

Disclaimer & Trademarks

© Copyright 2009 IBM Corporation. All Rights Reserved.

IBM Corporation Page 2 3/21/2011

DB2 Release and SAP Database Certification

IBM Corporation Page 3 3/21/2011

ERP 6.0 EHP4 para NW7.01:

Figure 1: Versões de DB2 para AIX e ERP6.0 EHP4

Figure 2: Versões de DB2 para AIX e R/3 4.6C

Facilidade de administração do Banco de Dados: Total

IBM Corporation Page 4 3/21/2011

Figure 3: DBACOCKPIT - Monitoração de Performance

IBM Corporation Page 5 3/21/2011

Figure 4: DBACOCKPIT - Monitorção e administração de espaço em disco

IBM Corporation Page 6 3/21/2011

Figure 5: DBACOCKPIT - Monitoração e administração de parâmetros de configuração

Manual SAP do DBA Cockpit do DB2

Manual SAP do DBA Cockpit do concorrente

Para mais informações em relação ao uso dessa poderosa ferramenta de administração no

IBM Corporation Page 7 3/21/2011

IBM Corporation Page 8 3/21/2011

Como referências, olhar notas 930487 e 980067

Figure 6: DBACOCKPIT - Compressão de Dados Integrada

IBM Corporation Page 9 3/21/2011

acarretar em um dimensionamento menor de table spaces temporárias, bem como o aumento de

Customer Before Compression After Compression

Schaeffler 100 TB under Oracle 100 TB reduced to 60TB under

(German 8TB Largest Database source 8TB reduced to 4.5TB

Tellabs 656 GB Oracle BW Production 456 GB DB2 BW Production.

(US Telco) Data Load times cut in half.

Coca Cola 950GB Oracle ERP 575GB Compressed in DB2.

UK Services 1.5TB Oracle ERP 750GB with DB2 Compression

Escalabilidade e processamento paralelo

IBM Corporation Page 10 3/21/2011

Para atender essa necessidade de gerenciamento de grandes quantidades de dados e de

Figure 7: DB2 com DPF - Escalabilidade de até 1000 partições

IBM Corporation Page 11 3/21/2011

Figure 8: Paralelismo de execução de consultas em ambiente DPF

A funcionalidade DPF é suportada e utilizada pela SAP em ambientes BW desde a versão

DB2 High Availability and Disaster Recovery (HADR):

IBM Corporation Page 12 3/21/2011

Figure 9: Manutenção sem interrupção operacional

IBM Corporation Page 13 3/21/2011

Um problema em um dos membros do cluster pureScale somente afeta dados “in-flight”, ou

All other nodes continue to process uninterrupted.

Figure 10: Impacto no caso de problema em um membro do cluster

Um dos grandes desafios para essa arquitetura de disco compartilhado é a escalabilidade.

IBM Corporation Page 14 3/21/2011

Figure 11: Arquitetura do DB2 pureScale

IBM Corporation Page 15 3/21/2011

Figure 12: Escalabilidade do DB2 pureScale para ambientes OLTP

Gerenciamento de cargas de trabalho

IBM Corporation Page 16 3/21/2011

controlar as diferentes cargas de trabalho e suas respectivas prioridades diretamente da mesma

Figure 13: DBACOCKPIT - Funcionalidade de gerenciamento de cargas de trabalho (WLM)

IBM Corporation Page 17 3/21/2011

Figure 14: DBACOCKPIT - Ajuste de prioridades para as classes de serviço

“SAPinst automatically installs and deinstalls the database software”

A instalação automática do DB2 pelo SAPINST pode ser comprovada no manual de

IBM Corporation Page 18 3/21/2011

A mesma integração não é encontrada no nosso concorrente, sendo necessário a instalação

Figure 15: Variáveis configuradas automaticamente por DB2_WORKLOAD=SAP

Outras funcionalidades autonômicas no DB2 incluem: