Funcionalidades e características únicas do DB2 para ambientes SAP

Transcrição

1 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

2 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 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. IBM Corporation Page 2 3/21/2011

3 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) DB2 v8.2.2 DB2 9 DB2 9.5 Database GA April 29, 2005 July 28, 2006 Oct 31, 2007 SAP DB GA June 3, 2005 Aug 31, 2006 Dec 20, 2007 GA Delta 4 weeks 4 weeks 7 weeks Comments 1st DB2 optimized for SAP Software release 2nd DB2 optimized for SAP Software release Backward comp. 3.1I Optimized for NetWeaver 7.0 SR3 DB June 2009 Aug weeks Optimized for NW 7.2, NW7.0 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. IBM Corporation Page 3 3/21/2011

4 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 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: IBM Corporation Page 4 3/21/2011

5 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 IBM Corporation Page 5 3/21/2011

6 Figure 4: DBACOCKPIT - Monitorção e administração de espaço em disco IBM Corporation Page 6 3/21/2011

7 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: IBM Corporation Page 7 3/21/2011

8 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 diz o seguinte a respeito do suporte de compressão do DB2: IBM Corporation Page 8 3/21/2011

9 You can use row compression with DB2 OEM license without additional costs and for any table Como referências, olhar notas e Para comprovar as limitações de uso pela SAP da funcionalidade de compressão do nosso concorrente, olhar notas , e Algumas citações interessantes dessas notas: You can only use table compression in the cases described in note (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 ). 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 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 IBM Corporation Page 9 3/21/2011

10 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 Group (German Engineering) Super De Boer (Dutch Retailer) 100 TB under Oracle Database 8TB Largest Database source 4.7TB ECC under Oracle 100 TB reduced to 60TB under DB2. 8TB reduced to 4.5TB Database after DB2 Migration with Compression. Reduced to 1.6TB with DB2 Compression (66% reduction) Tellabs (US Telco) 656 GB Oracle BW Production 456 GB DB2 BW Production. Data Load times cut in half. Coca Cola Bottling (US CPG) UK Services Company 950GB Oracle ERP 1.5TB Oracle ERP 575GB Compressed in DB2. Also included UNICODE conversion. 750GB with DB2 Compression 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 ). IBM Corporation Page 10 3/21/2011

11 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 IBM Corporation Page 11 3/21/2011

12 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 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): IBM Corporation Page 12 3/21/2011

13 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: IBM Corporation Page 13 3/21/2011

14 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: 100% Node Failure DB2 purescale Data availability 0% 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 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: IBM Corporation Page 14 3/21/2011

15 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: IBM Corporation Page 15 3/21/2011

16 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 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 IBM Corporation Page 16 3/21/2011

17 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 IBM Corporation Page 17 3/21/2011

18 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 IBM Corporation Page 18 3/21/2011

19 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 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) IBM Corporation Page 19 3/21/2011

20 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 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 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 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. IBM Corporation Page 20 3/21/2011

21 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: IBM Corporation Page 21 3/21/2011

22 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 IBM Corporation Page 22 3/21/2011

23 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 Inovação Tecnológica Facilidade administração do banco de - Última versão (DB2 9.5) disponível e certificada pela SAP Referências: - Interface DBA Cockpit foi primeiramente criada para DB2, com funcionalidades para total administração do banco pelo SAP GUI Referências: library/uuid/c0e e5c-2b f38ccf8da350 Concorrente - Última versão certificada pela SAP depois de 2.5 anos! Referências: - DBA Cockpit também é oferecido, porém com muito menos funcionalidades. - Utilizado basicamente para monitoração e agendamento de tarefas Referências: library/uuid/f079d393-a806-2a10-84a4-d821d4ee092c IBM Corporation Page 23 3/21/2011

24 Compressão de Dados - Alta taxa de compressão e totalmente suportado pela SAP Referências: Notas e index2.htm?numm= index2.htm?numm= Restrito a SAP BW Referências: Notas , e ndex2.htm?numm= ndex2.htm?numm= ndex2.htm?numm= 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 index2.htm?numm= Redbook SAP BW 60TB l?open Alta Disponibilidade Gerenciamento de Cargas de trabalho - DB2 HADR forcene failover super rápido. DB2 purescale fornece disponibilidade contínua, e é transparente a aplicação - Funcionalidade única no DB2. Integrado ao DBACOCKPIT Tecnologia semelhante não fornece o mesmo grau de disponibilidade Tecnologia única a DB2 Referências: Artigo SDN da SAP Computação Autonômica library/uuid/d046f3f5-13c5-2b10-179d-80b6ae7b Instalação automática do DB2 pelo SAPINST. REORG, STMM Referências: Manual de instalação SAP Netweaver 7.0 EHP1 - Otimização do banco para aplicações SAP utilizando a variável DB2_WORKLOAD=SAP Referências: Nota SAP Instalação manual do banco de dados, não integrado ao SAPINST. Referências: Manual de instalação SAP Netweaver 7.0 EHP1 para o nosso concorrente - Automatic Storage Management ainda não suportada pela SAP Referências: Nota SAP Auto-Storage, Auto RUNSTATS, Auto IBM Corporation Page 24 3/21/2011

25 index2.htm?numm= notes/index2.htm?numm= Automatic Storage Management totalmente suportado pela SAP Referências: Nota SAP index2.htm?numm= Particionamento e Organização física de dados - MDC é uma melhor alternativa que Range Partitioning, pois permite a organização física dos dados por várias dimensões. Referências: Nota index2.htm?numm= Artigo de recomendações no uso de MDC em ambientes SAP - Uso de Range Partitioning, limitado a apenas uma dimensão. - Tecnologia baseada em modelos unidimensionais, sendo que SAP BW é baseado em modelos multi-dimensionais. ebindex/wp Archiving de Dados Near- Line (NLS) - Implementação única com DB2. Facilita o gerenciamento de sistemas BW, melhoria de performance Funcionalidade única com DB2 Referências adicionais de funcionalidades DB2 suportadas pela SAP: Nota : Using DB2 9.1 with SAP Software Nota : Using DB2 Version 9.5 with SAP Software Nota : 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 : Support for Oracle functions in the SAP environment IBM Corporation Page 25 3/21/2011

26 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. IBM Corporation Page 26 3/21/2011