Visão geral dos cubos OLAP do Service Manager para análise avançada

No Service Manager, os dados presentes no data warehouse podem ser consolidados de várias fontes. Ele é apresentado por meio do Service Manager usando cubos de dados OLAP (Processamento Analítico Online da Microsoft) predefinidos e personalizados. Em resumo, a análise avançada no Service Manager consiste em publicar, exibir e manipular dados de cubo, geralmente no Microsoft Excel ou no Microsoft SharePoint. O Excel é usado principalmente por si só para exibir e manipular dados. O SharePoint é usado principalmente como um meio de publicação e compartilhamento de dados do cubo.

O Service Manager inclui um data warehouse em todo o System Center. Portanto, os dados do Operations Manager, Configuration Manager e Service Manager podem ser consolidados no data warehouse, onde você pode usar facilmente várias exibições de dados para obter qualquer informação desejada. Essa também é uma interface em que você pode colocar dados no mesmo data warehouse de suas próprias fontes personalizadas, como aplicativos SAP ou um aplicativo de recursos humanos de terceiro. Essa consolidação cria um modelo de dados comum e permite análises enriquecidas para ajudar a criar um data warehouse em sua organização de TI (Tecnologia de Informação) que pode atender a todas as necessidades de emissão de relatórios e business intelligence.

Quando seus dados estão em um modelo comum, você pode manipular informações e ter definições comuns e uma taxonomia comum para sua empresa inteira. Você pode fazer isso implantando os cubos de dados OLAP e acessando as informações dos cubos, usando ferramentas padrão como o Excel e o SharePoint. Isso possibilita que os usuários empreguem habilidades que já conhecem. Você controla a definição da lógica de seu negócio de uma maneira centralizada. Por exemplo, você pode definir indicadores-chave de desempenho, como os limites de tempo para resolução de incidente, e quais valores dos limites são verde, amarelo ou vermelho. Você pode controlar essas opções de uma maneira centralizada e pode incentivar seus usuários a usar facilmente os dados, mas deve ter a definição comum exibida em relatórios do Excel ou em painéis do SharePoint.

Sobre cubos OLAP do Service Manager

Os cubos OLAP (processamento analítico online) são um recurso no Service Manager que usa a infraestrutura de data warehouse existente para fornecer recursos de business intelligence de autoatendimento aos usuários finais.

Um cubo OLAP é uma estrutura de dados que supera as limitações dos bancos de dados relacionais, proporcionando rápida análise de dados. Os cubos podem exibir e somar grandes quantidades de dados enquanto fornecem aos usuários acesso pesquisável a quaisquer pontos de dados. Dessa forma, os dados podem ser acumulados, divididos e divididos conforme necessário para lidar com a mais ampla variedade de perguntas relevantes para a área de interesse de um usuário.

Fornecedores de software ou desenvolvedores de TI (tecnologia da informação) com conhecimento prático de cubos OLAP podem criar pacotes de gerenciamento para definir seus próprios cubos OLAP extensíveis e personalizáveis criados na infraestrutura do data warehouse. Esses cubos são armazenados no SQL Server Analysis Services (SSAS). As ferramentas do business intelligence de autoatendimento, como Excel e SQL Server Reporting Services (SSRS), podem direcionar esses cubos no SSAS e serem utilizadas para analisar os dados a partir de várias perspectivas.

Os bancos de dados que uma empresa usa para armazenar todas as suas transações e registros são chamados bancos de dados OLTP (processamento de transações online). Esses bancos de dados geralmente têm registros, inseridos um a um, contendo uma grande quantidade de informações que podem ser usadas por estrategistas para tomar decisões mais conscientes sobre seus negócios. Os bancos de dados usados para armazenar os dados, no entanto, não foram projetados para análise. Portanto, a recuperação de respostas com base nesses bancos de dados é cara em termos de tempo e esforço. Os bancos de dados OLAP são bancos especializados que foram desenvolvidos para ajudar a extrair dos dados as informações de business intelligence.

Os cubos OLAP podem ser considerados a última peça do quebra-cabeça para uma solução do data warehouse. Um cubo OLAP, também conhecido como cubo multidimensional ou hipercubo, é uma estrutura de dados no SQL Server Analysis Services (SSAS) criada, usando bancos de dados OLAP, para permitir a análise quase instantânea dos dados. A topologia desse sistema é mostrada na ilustração a seguir.

O recurso útil de um cubo OLAP é que os dados contidos nele podem estar em um formato agregado. Para o usuário, o cubo parece ter as respostas antecipadamente, pois as classificações de valores já estão pré-calculadas. Sem precisar consultar o banco de dados OLAP de origem, o cubo pode responder, quase instantaneamente, uma ampla gama de perguntas.

O principal objetivo dos cubos OLAP do Service Manager é fornecer aos fornecedores de software ou desenvolvedores de TI (tecnologia da informação) a capacidade de executar análises quase instantâneas de dados para fins de análise histórica e tendências. O Service Manager faz isso:

• Permitindo que você defina cubos OLAP em pacotes de gerenciamento que serão criados automaticamente no SSAS na implantação do pacote de gerenciamento.
• Fazendo a manutenção automática do cubo sem intervenção do usuário, executando tarefas como: processamento, particionamento, tradução e localização, e alterações de esquema.
• Permitindo que os usuários usem ferramentas de business intelligence de autoatendimento, como Excel, para analisar os dados a partir de várias perspectivas.
• Salvando relatórios gerados pelo Excel para referência futura.

Para ver como os cubos do data warehouse são representados no console do Service Manager, navegue até o espaço de trabalho do Data Warehouse e selecione Cubos.

Cubos OLAP do Service Manager

A ilustração a seguir mostra uma imagem do SQL Server BIDS (Business Intelligence Development Studio) que representa as principais partes necessárias aos cubos OLAP. Essas partes são: fonte de dados, exibição da fonte de dados, cubos e dimensões. As seções a seguir descrevem as partes do cubo OLAP e as ações que os usuários podem executar com elas.

Fonte de dados

Uma fonte de dados é a origem de todos os dados que estão contidos em um cubo OLAP. Um cubo OLAP conecta-se a uma fonte de dados para ler e processar dados brutos a fim de executar agregações e cálculos para as medidas associadas. A fonte de dados para todos os cubos OLAP do Service Manager são os data marts, que incluem os data marts do Operations Manager e do Configuration Manager. As informações de autenticação sobre a fonte de dados devem ser armazenadas no SSAS (SQL Server Analysis Services) para se estabelecer o nível correto de permissões.

Exibição da fonte de dados

A DSV (exibição da fonte de dados) é uma coleção de exibições que representam as tabelas de dimensão, fato e subdimensão da fonte de dados, como os data marts do Service Manager. A DSV contém todas as relações entre tabelas, como chaves primárias e estrangeiras. Em outras palavras, a DSV especifica como o banco de dados do SSAS será mapeado para o esquema relacional e fornece uma camada de abstração por sobre o banco de dados relacional. Usando esse camada de abstração, podem ser definidas relações entre tabelas de fatos e de dimensões, ainda que nenhuma relação exista no banco de dados relacional de origem. Também podem ser definidos na DVS cálculos nomeados, medidas personalizadas e novos atributos que podem não existir nativamente no esquema dimensional do data warehouse. Por exemplo, um cálculo nomeado que define um valor booleano para Incidentes resolvidos calcula o valor como verdadeiro se o status de um incidente for resolvido ou fechado. Usando o cálculo nomeado, Service Manager pode definir uma medida para exibir informações úteis, como a porcentagem de incidentes resolvidos, o número total de incidentes resolvidos e o número total de incidentes que não são resolvidos.

Outro exemplo rápido de um cálculo nomeado é ReleasesImplementedOnSchedule. Esse cálculo nomeado faz uma rápida verificação do status de integridade na série de registros de liberação cujas datas finais são menores ou iguais à data final agendada.

Cubos OLAP

Um cubo OLAP é uma estrutura de dados que supera limitações de bancos de dados relacionais, proporcionando rápida análise de dados. Os cubos OLAP podem exibir e somar grandes quantidades de dados, ao mesmo tempo em que fornecem aos usuários acesso pesquisável a quaisquer pontos de dados para que os dados possam ser acumulados, divididos e divididos conforme necessário para lidar com a mais ampla variedade de perguntas relevantes para a área de interesse de um usuário.

Dimensões

Uma dimensão no SSAS faz referência a uma dimensão do data warehouse do Service Manager. No Service Manager, uma dimensão é aproximadamente equivalente a uma classe de pacote de gerenciamento. Cada classe de pacote de gerenciamento possui uma lista de propriedades, ao passo que cada dimensão contém uma lista de atributos, sendo cada atributo mapeado para uma propriedade em uma classe. As dimensões permitem filtrar, agrupar e rotular os dados. Por exemplo, você pode filtrar computadores por sistema operacional instalado e agrupar pessoas em categorias por sexo ou idade. Os dados podem então ser apresentados em um formato em que os dados são categorizados naturalmente nessas hierarquias e categorias para permitir uma análise mais aprofundada. As dimensões também podem ter hierarquias naturais para permitir que os usuários "façam uma busca detalhada" para níveis de detalhes mais detalhados. Por exemplo, a dimensão Data possui uma hierarquia que pode ser detalhada sucessivamente por Ano, Trimestre, Mês, Semana e Dia.

A ilustração a seguir mostra um cubo OLAP que contém as dimensões de Data, Região e Produto.

Por exemplo, os membros da equipe da Microsoft podem querer um resumo rápido e simples das vendas do console de jogos Xbox One na versão aplicável. Eles podem detalhar ainda mais para obter números de vendas para um período de tempo mais direcionado. Os analistas de negócios podem querer examinar como as vendas dos consoles Xbox One foram afetadas pelo lançamento do novo design do console e do Kinect para Xbox One. Isso ajuda a determinar quais tendências de vendas estão ocorrendo e quais são as possíveis revisões necessárias à estratégia de negócios. Por meio da filtragem na dimensão Data, essas informações podem ser rapidamente fornecidas e consumidas. Essa segmentação e análise de dados é possível somente porque as dimensões foram projetadas com atributos e dados que podem ser facilmente filtrados e agrupados pelo cliente.

No Service Manager, todos os cubos OLAP compartilham um conjunto comum de dimensões. Todas as dimensões utilizam o data mart do data warehouse primário como fonte, mesmo em cenários com vários data marts. Em cenários com vários data marts, isso pode, possivelmente, levar a erros de chave de dimensão durante o processamento do cubo.

Grupo de medidas

Um grupo de medidas tem o mesmo conceito que um fato em uma terminologia de data warehouse. Assim como fatos contêm medidas numéricas em um data warehouse, um grupo de medidas contém medidas para um cubo OLAP. Todas as medidas em um cubo OLAP derivadas de uma única tabela de fatos em uma exibição de fonte de dados também podem ser consideradas como um grupo de medidas. Pode haver ocasiões, entretanto, em que haverá várias tabelas de fatos das quais se derivam as medidas em um cubo OLAP. Medidas do mesmo nível de detalhe são unidas em um mesmo grupo de medidas. Grupos de medidas definem quais dados serão carregados no sistema, como os dados serão carregados e como os dados serão associados ao cubo multidimensional.

Cada grupo de medidas também pode conter uma lista de partições, que mantêm os dados reais em seções separadas e não sobrepostas. Os grupos de medidas também contêm design de agregação, que define os conjuntos de dados pré-resumidos que são calculados para cada grupo de medidas, para melhorar o desempenho das consultas do usuário.

Medidas

Medidas são os valores numéricos que os usuários desejam dividir, dividir, agregar e analisar; eles são uma das razões fundamentais pelas quais você deseja criar cubos OLAP usando a infraestrutura de armazenamento de dados. Usando SSAS, você pode construir cubos OLAP que se aplicarão às regras de negócios e aos cálculos para formatar e exibir medidas em um formato personalizado. Boa parte de seu tempo no desenvolvimento de cubos OLAP será gasto determinando e definindo quais medidas serão exibidas e como elas serão calculadas.

Medidas são valores que, geralmente, são mapeados para colunas numéricas em uma tabela de fatos do data warehouse, mas também podem ser criadas em atributos de dimensão e de dimensão de degeneração. Essas medidas são os valores mais importantes de um cubo OLAP que são analisados e são o principal interesse dos usuários finais que pesquisam o cubo OLAP. Um exemplo de uma medida que existe no data warehouse é ActivityTotalTimeMeasure. ActivityTotalTimeMeasure é uma medida de ActivityStatusDurationFact que representa o tempo que cada atividade permanece em um determinado status. O nível de detalhe de uma medida é composto por todas as dimensões que são referenciadas. Por exemplo, o nível de detalhe do fato de relação ComputerHostsOperatingSystem consiste nas dimensões Computador e Sistema Operacional.

Funções de agregação são calculadas sobre as medidas para permitir ainda mais análise dos dados. A função de agregação mais comum é a Soma. Por exemplo, uma consulta comum de cubo OLAP soma o tempo total de todas as atividades que estão In Progress. Outras funções de agregação comuns incluem Mín., Máx. e Contagem.

Depois que os dados brutos são processados em um cubo OLAP, os usuários podem executar consultas e cálculos mais complexos usando expressões multidimensionais (MDX) para definirem suas próprias expressões de medida ou membros calculados. MDX é um padrão do setor para consulta e acesso a dados armazenados em sistemas OLAP. O SQL Server não foi projetado para funcionar com o modelo de dados compatível com bancos de dados multidimensionais.

Busca detalhada (drill down)

Quando faz uma busca detalhada de dados em um cubo OLAP, o usuário está analisando os dados em um nível diferente de resumo. O nível de detalhe dos dados muda conforme o usuário vai detalhando a busca, examinando os dados em diferentes níveis na hierarquia. À medida que os usuários se aprofundam, eles passam de informações resumidas para dados com um foco mais restrito. Encontram-se, a seguir, exemplos de busca detalhada (drill down):

• Fazer uma busca detalhada nos dados para examinar informações demográficas sobre a população dos Estados Unidos, depois sobre o Estado de Washington, depois sobre a área metropolitana de Seattle, depois sobre a cidade de Redmond e, por fim, sobre a população na Microsoft.
• Detalhando os números de vendas dos consoles Xbox One para o ano civil de 2015, depois o quarto trimestre do ano, depois o mês de dezembro, depois a semana antes do Natal e, finalmente, a véspera de Natal.

Detalhamento

Quando os usuários detalham os dados, eles desejam ver todas as transações individuais que contribuíram para os dados agregados do cubo OLAP. Em outras palavras, o usuário pode recuperar os dados em um menor nível de detalhe para um respectivo valor da medida. Por exemplo, quando você recebe os dados de vendas de um determinado mês e categoria de produto, pode detalhar esses dados para ver uma lista de cada linha da tabela contida nessa célula de dados.

É comum confundir os termos detalhamento e detalhamento entre si. A principal diferença entre eles é que um detalhamento opera em uma hierarquia predefinida de dados - por exemplo, EUA, depois em Washington e em Seattle - dentro do cubo OLAP. Uma consulta drill-through vai diretamente ao menor nível de detalhe dos dados e recupera um conjunto de linhas dessa fonte de dados, que foram agregados em uma única célula.

Indicador-chave de desempenho

As organizações utilizam KPIs (indicadores chave de desempenho) (para indicar a integridade de seus negócios e seu desempenho, medindo seu progresso em relação às metas. Os KPIs são métricas de negócios que podem ser definidas para monitorar o progresso em relação a certos objetivos e metas predefinidos. Um KPI tem um valor alvo e um valor real, que representa uma meta quantitativa que é crítica para o sucesso da organização. Os KPIs são exibidos em grupos em um scorecard para mostrar a integridade geral do negócio em um instantâneo rápido.

Um exemplo de KPI seria concluir todas as solicitações de alteração dentro de 48 horas. Um KPI pode ser usado para medir a porcentagem de solicitações de alteração resolvidas dentro desse período. Você pode criar painéis para representar KPIs visualmente. Por exemplo, pode ser conveniente definir um valor fixado de KPI de até 75% para a conclusão de todas as solicitações de alteração dentro de 48 horas.

Partições

Uma partição é uma estrutura de dados que mantém alguns ou todos os dados em um grupo de medidas. Cada grupo de medidas é dividido em partições. Uma partição define um subconjunto dos dados de fatos que estão carregados no grupo de medidas. O SSAS Standard Edition permite uma única partição por grupo de medidas, ao passo que o SSAS Enterprise Edition permite que um grupo de medidas contenha várias partições. As partições são um recurso transparente para o usuário final, mas têm um grande impacto no desempenho e na escalabilidade dos cubos OLAP. Todas as partições de um grupo de medidas sempre existem no mesmo banco de dados físico.

As partições possibilitam que um administrador gerencie melhor um cubo OLAP e melhore o desempenho de um cubo OLAP. Por exemplo, você pode remover ou reprocessar os dados em uma partição de um grupo de medidas sem afetar o restante do grupo de medidas. Quando você carrega novos dados em um tabela de fatos, apenas as partições que devem conter os novos dados são afetadas.

O particionamento também melhora o desempenho de consulta e processamento de cubos OLAP. O SSAS pode processar várias partições paralelamente, levando a um uso muito mais eficiente dos recursos de memória e da CPU no servidor. Enquanto executa uma consulta, o SSAS busca, processa e agrega dados de várias partições também, somente as partições que contêm os dados relevantes para uma consulta são verificadas, o que reduz a quantidade geral de entrada e saída.

Um exemplo de uma estratégia de particionamento é colocar os dados de fato para cada mês em uma partição mensal. No fim de cada mês, todos os novos dados entram em uma nova partição, levando a uma distribuição natural de dados com valores não sobrepostos.

Agregações

As agregações em um cubo OLAP são conjuntos de dados resumidos antecipadamente. Eles são análogos a uma instrução SQL SELECT com uma cláusula GROUP BY. O SSAS pode usar essas agregações quando responde perguntas para reduzir a quantidade de cálculos necessários, retornando as respostas rapidamente ao usuário. Agregações internas no cubo OLAP reduzem a quantidade de agregação que o SSAS tem para executar no momento da consulta. A criação das agregações corretas pode melhorar drasticamente o desempenho da consulta. Isso geralmente é um processo evolutivo em todo o ciclo de vida útil do cubo OLAP, pois suas consultas e uso são alterados.

Um conjunto base de agregações geralmente é criado e será útil para a maioria das consultas do cubo OLAP. As agregações são criadas para cada partição de um cubo OLAP em um grupo de medidas. Quando uma agregação é criada, determinados atributos de dimensões são incluídos no conjunto de dados resumido anteriormente. Os usuários podem consultar rapidamente os dados com base nessas agregações quando navegam no cubo OLAP. As agregações devem ser cuidadosamente criadas, pois o número de agregações possíveis é tão grande que a criação de todas elas levaria um tempo e espaço de armazenamento não aceitável.

Service Manager usa as duas opções a seguir ao criar e projetar agregações em cubos OLAP do Service Manager:

• Ganhos de Desempenho
• Otimização Baseada no Uso

A opção Ganhos de Desempenho define a porcentagem de agregações que é criada. Por exemplo, definir essa opção como o valor padrão e recomendado de 30% significa que as agregações serão criadas para proporcionar ao cubo OLAP um ganho estimado de desempenho de 30%. No entanto, isso não significa que 30% das agregações possíveis serão construídas.

A otimização baseada no uso possibilita que o SSAS registre as solicitações de dados, de forma que quando uma consulta for executada, as informações entrarão no processo de design de agregação. Em seguida, o SSAS revisa os dados e recomenda quais agregações devem ser criadas para proporcionar o melhor ganho estimado de desempenho.

Particionamento de cubo do Service Manager

Cada grupo de medidas em um cubo é dividido em partições, em que uma partição define uma parte dos dados do fato que são carregados em um grupo de medidas. SQL Server Analysis Services (SSAS) no SQL Server Standard Edition permite apenas uma partição por grupo de medidas, enquanto várias partições são permitidas na Enterprise Edition. As partições são completamente transparentes para o usuário final, mas têm um impacto importante no desempenho e na escalabilidade. Por exemplo, as partições podem ser processadas de forma separada e em paralelo. Eles podem ter diferentes designs de agregação. É possível reprocessar uma partição sem afetar todas as outras partições de um grupo de medidas. Além disso, o SSAS verifica automaticamente apenas as partições que contêm os dados necessários a uma consulta, o que pode melhorar muito o desempenho da consulta.

O particionamento de cubos é realizado em cada execução de trabalho de manutenção do data warehouse, o que é feito, por padrão, de hora em hora. O módulo de processo específico executado é denominado ManageCubePartitions. Ele sempre é executado após a etapa CreateMartPartitions. Esses dados de dependência são armazenados na tabela infra.moduletriggercondition.

A DLL (biblioteca de vínculo dinâmico) principal, que controla o particionamento, está na DLL de utilitário de depósito, Microsoft.EnterpriseManagement.Warehouse.Utility, na classe PartitionUtil. Especificamente, há um método ManagePartitions() na classe que lida com toda a manutenção da partição. A DLL de manutenção do data warehouse, Microsoft.EnterpriseManagement.Warehouse.Maintenance, e a DLL de OLAP do data warehouse, Microsoft.EnterpriseManagement.Warehouse.Olap, são chamadas no Microsoft.EnterpriseManagement.Warehouse.Utility para controlar partições durante a manutenção e a implantação do cubo. É por esse motivo que a manipulação real da partição ocorre na DLL do utilitário de depósito comum, para evitar a duplicação da lógica ou do código.

A Manutenção de Particionamento de Cubos executa as seguintes tarefas:

• Criar partições
• Exclui partições
• Atualiza limites de partição

Para fazer isso, a tabela SQL (Structured Query Language) etl.TablePartition é lida para determinar todas as partições de fato que foram criadas para um grupo de medidas. As seguintes ações ocorrem:

1. Inicia o processamento de cubos para cada grupo de medidas no cubo
2. Obtém todas as partições da tabela etl.TablePartition referentes ao grupo de medidas
3. Exclui todas as partições existentes no grupo de medidas que estão faltando na tabela etl.TablePartition
4. Adiciona qualquer partição nova que tenha sido criada e que exista apenas na tabela etl.TablePartition
5. Atualiza qualquer partição que possa ter sido alterada, correspondendo cada partição a RangeStartDate e a RangeEndDate na tabela etl.TablePartition

Sobre o processamento de cubos, lembre-se de que:

• Somente os grupos de medidas direcionados a fatos contêm várias partições no SQL Server Standard Edition. Por padrão, todos os grupos de medidas e dimensões contêm apenas uma partição. Portanto, a partição não tem nenhuma condição de limite.
• Os limites de partição são definidos por uma associação de consulta baseada em datas-chave que sejam adequadas para as datas-chave da partição de fato correspondente na tabela etl.TablePartition.

Implantação de cubo OLAP do Service Manager

A implantação de cubo OLAP (processamento analítico online) usa a infraestrutura de implantação do Service Manager para criar cubos OLAP no banco de dados SQL Server Analysis Services (SSAS).

Para resumir, um elemento implantável retorna um implantador com uma coleção de recursos que são serializados e usados para criar o cubo OLAP no banco de dados do SSAS. Para cubos OLAP, o nome do objeto implantável é CubeDeployable para o elemento SystemCenterCube e CubeExtensionDeployable para o elemento CubeExtension. O implantador para os dois elementos é o CubeDeployer.

A tabela dbo.Selector no banco de dados DWStagingAndConfig contém uma entrada para os elementos do pacote de gerenciamento SystemCenterCube e CubeExtension. O mecanismo de implantação usa esses metadados, se o processamento da implantação adicional for necessário para um elemento do pacote de gerenciamento, quando esse pacote for importado para o data warehouse usando o trabalho MPSync.

As implantações usam a API (interface de programação de aplicativo) do AMO (Objetos de Gerenciamento de Análise) para criar e modificar todos os componentes de cubo no banco de dados do SSAS. Especificamente, o AMO no modo desconectado é usado porque o elemento CubeDeployable não terá uma conexão com o banco de dados do SSAS. Trabalhar com o AMO no modo desconectado possibilita criar toda a árvore de objetos AMO sem estabelecer uma conexão com o servidor. Em seguida, Service Manager serializa a hierarquia de objetos como recursos de fluxo e os anexa ao objeto implantador que é passado de volta para a infraestrutura de implantação. O objeto do implantador é desserializado, estabelece uma conexão com o banco de dados do SSAD e cria os objetos enviando as solicitações adequadas ao servidor.

Somente os objetos principais podem ser serializados. No AMO, os objetos principais são considerados classes que representam um objeto completo como uma entidade completa e não como parte de outro objeto. Por exemplo, os objetos principais incluem Server, Cube e Dimension, que são entidades independentes. O DimensionAttribute, no entanto, não é um objeto principal porque só pode ser criado como parte de um objeto principal pai de Dimension. Portanto, DimensionAttribute é um objeto secundário. O design do cubo OLAP se concentra na criação de todos os objetos principais necessários aos cubos, juntamente com quaisquer objetos secundários dependentes. Esses objetos principais são os objetos que serão serializados e, eventualmente, desserializados antes que os objetos sejam criados no banco de dados do SSAS.

Os recursos que agrupam os objetos principais devem ser criados em uma ordem específica, para que a implantação seja concluída com êxito e satisfaça os requisitos de dependência dos elementos do cubo OLAP. As duas listas a seguir ilustram a sequência de implantação para os elementos SystemCenterCube e CubeExtension, respectivamente:

1. Elementos DataSourceView
2. elementos de dimensão
3. elemento de dimensão de data
4. elemento de cubo
5. Elementos DataSourceView
6. elemento de cubo

Processamento de cubo OLAP do Service Manager

Quando um cubo OLAP (processamento analítico online) é implantado e todas as suas partições são criadas, ele está pronto para ser processado para que possa ser exibido. O processamento de um cubo é a etapa final após a execução de ETL (extração, transformação e carregamento). Essas etapas ocorrem da seguinte maneira:

1. Extração: extrai dados do sistema de origem
2. Transformação: aplica funções de acordo com os dados para um esquema dimensional padrão
3. Carregamento: carrega os dados no data mart para consumo
4. Processo: carrega os dados do data mart no cubo OLAP para navegação

O processamento de um cubo OLAP ocorre quando todas as agregações do cubo são calculadas e o cubo é carregado com essas agregações e esses dados. Tabelas de dimensões e fatos são lidas e os dados são calculados e carregados no cubo. Quando você projeta um cubo OLAP, o processamento deve ser cuidadosamente considerado por causa do possível efeito significativo que o processamento pode tem em um ambiente de produção em que podem existir milhões de registros. Um processo completo de todas as partições em tal ambiente pode levar de dias a até semanas, o que pode tornar a infraestrutura e os cubos do Service Manager inutilizáveis para os usuários finais. Uma recomendação é desabilitar o agendamento de processamento de todos os cubos que não estão sendo usados para reduzir a sobrecarga no sistema.

O processamento de cubos OLAP consiste em duas tarefas separadas:

1. Processamento de dimensão
2. Processamento de partição

Cada cubo OLAP tem um trabalho de processamento correspondente no console do Service Manager e é executado em um agendamento configurável pelo usuário. Cada tipo de tarefa de processamento é descrita nas seções a seguir.

Processamento de dimensão

Sempre que uma nova dimensão é adicionada ao banco de dados do SSAS (SQL Server Analysis Server), um processo completo deve ser executado na dimensão para colocá-la em um estado totalmente processado. No entanto, depois que uma dimensão for processada, não haverá garantia de que ela será processada novamente quando outro cubo direcionado à mesma dimensão for processado. Ao não reprocessar automaticamente a dimensão, impede que o Service Manager reprocesse todas as dimensões de cada cubo. Isso é especialmente verdadeiro se a dimensão tiver sido processada recentemente, pois é improvável que existam novos dados que ainda não tenham sido processados. Para otimizar a eficiência do processamento, há uma classe singleton, que é definida no pacote de gerenciamento Microsoft.SystemCenter.Datawarehouse.OLAP.Base, que é chamada Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval. A seguir está um exemplo dessa classe:

<!-- This singleton class defines the minimum interval of time in minutes that must elapse before a shared dimension is reprocessed. -->   
<ClassType ID="Microsoft.SystemCenter.Warehouse.Dimension.ProcessingInterval" Accessibility="Public" Abstract="false" Base="AdminItem!System.AdminItem" Singleton="true">  
<Property ID="IntervalInMinutes" Type="int" Required="true" DefaultValue="60"/>  
</ClassType>  

Essa classe singleton contém uma propriedade, IntervalInMinutes, que descreve com que frequência processar uma dimensão. Por padrão, essa propriedade é definida como 60 minutos. Por exemplo, se uma dimensão foi processada às 15h05 e outro cubo direcionado à mesma dimensão é processado às 15h45, a dimensão não será reprocessada. Uma desvantagem dessa abordagem é a maior probabilidade de erros de chave de dimensão. Um mecanismo de repetição manipula erros de chave de dimensão para reprocessar a dimensão e, em seguida, a partição de cubo. Para obter mais informações sobre falhas de processamento, consulte a seção "Problemas comuns com depuração e solução de problemas".

Depois que uma dimensão tiver sido completamente processada, será executado o processamento incremental com ProcessUpdate . A outra ocasião que o ProcessFull é executado é quando um esquema de dimensão muda, porque ele resulta na dimensão retornando para um estado não processado. Lembre-se de que, se ProcessFull for executado em uma dimensão, todos os cubos afetados e suas partições existirão em um estado não processado e terão que ser totalmente processados em sua próxima execução agendada.

Processamento de partição

O processamento de partição deve ser cuidadosamente considerado porque o reprocessamento de uma partição grande é lento e consome muitos recursos da CPU no servidor que hospeda o SSAS. O processamento de partição geralmente demora mais do que o processamento de dimensão. Ao contrário do processamento de dimensão, o processamento de uma partição não tem efeitos colaterais em outros objetos. Os únicos dois tipos de processamento executados nos cubos OLAP do System Center – Service Manager são ProcessFull e ProcessAdd.

Semelhante a dimensões, a criação de novas partições em um cubo OLAP requer uma tarefa ProcessFull para que a partição esteja em um estado em que ela possa ser consultada. Como uma tarefa ProcessFull é uma operação dispendiosa, você deve executá-la somente quando necessário, por exemplo, quando criar uma partição ou quando uma linha foi atualizada. Em cenários em que linhas foram adicionadas e nenhuma linha foi atualizada, Service Manager pode executar uma tarefa ProcessAdd. Para fazer isso, Service Manager usa marcas d'água e outros metadados. Especificamente, as tabelas etl.cubepartition e etl.tablepartition são consultadas para determinar que tipo de processamento executar.

O diagrama a seguir ilustra como Service Manager determina que tipo de processamento executar com base nos dados de marca d'água.

Quando uma tarefa ProcessAdd é executada, Service Manager limita o escopo da consulta usando marcas d'água. Por exemplo, se o valor de InsertedBatchId for 100 e o valor de WatermarkBatchId for 50, a consulta carregará dados somente do data mart em que o InsertedBatchId for maior do que 50 e menor do que 100.

Por fim, é importante observar que o Service Manager não dá suporte ao processamento manual de cubos OLAP usando o SSAS ou o Business Intelligence Development Studio. O processamento de cubos fora dos métodos fornecidos no System Center – Service Manager, incluindo o console do Service Manager e os cmdlets do Service Manager, não atualizará as tabelas de marca d'água. Portanto, é possível que ocorram problemas de integridade de dados. Se você reprocessou acidentalmente o cubo manualmente, uma possível solução alternativa é cancelar o processamento do cubo OLAP manualmente da mesma maneira. Em seguida, na próxima vez que Service Manager processar o cubo, ele executará automaticamente uma tarefa ProcessFull porque as partições estarão em um estado não processado. Isso atualizará todas as marcas d' água e metadados corretamente, de forma que todos os possíveis problemas de integridade de dados sejam corrigidos.

Manter cubos OLAP do Service Manager

As informações nas seções seguintes descrevem as práticas recomendadas de manutenção para cubos de OLAP (processamento analítico online).

Reprocessar periodicamente as dimensões do Analysis Services

As melhores práticas do SQL Server Analysis Services (SSAS) recomendam que as dimensões do SSAS devem ser, periodicamente, processadas por completo. O processamento completo das dimensões recria índices e otimiza o armazenamento de dados multidimensionais, aprimorando a consulta e o desempenho do cubo, que pode ser prejudicado com o passar do tempo. Isso é semelhante a desfragmentar periodicamente o disco rígido de um computador.

No entanto, o problema de processar por completo uma dimensão SSAS é que todos os cubos OLAP afetados se tornam não processados e deverão ser completamente processados para retornar ao estado em que você possa consultá-los. Service Manager não processa totalmente explicitamente nas dimensões do SSAS. Portanto, você deve decidir quando executar essa tarefa de manutenção.

Considerações sobre memória

Se você executar todas as operações de ETL (extração, transformação e carregamento) do data warehouse e as funções do cubo OLAP em um servidor, considere com atenção as necessidades de memória do sistema operacional, do data warehouse e do SSAS para verificar se o servidor pode controlar todas as operações executadas simultaneamente. Isso é especialmente importante porque o processamento de cubos OLAP é uma operação que utiliza muita memória.

Próximas etapas

• Modele cubos OLAP em pacotes de gerenciamento.