SQL Server Reporting Services: Monitorando instâncias no SQL Server

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (0)

Este artigo apresenta procedimentos que podem ser realizados para administrar instâncias SQL Server instaladas em servidores distintos. Para isso, será utilizado como apoio o Reporting Services alimentado por uma rotina em Integration Services.

Fique por dentro
Este artigo demonstra como administrar instâncias SQL Server instaladas em servidores distintos com o auxílio de relatórios construídos com Reporting Services, sendo estes alimentados por uma rotina em Integration Services.

Vamos demonstrar especificamente como visualizar o espaço disponível em disco de vários servidores, porém, usando a mesma ideia é possível criar inúmeros monitoramentos diferentes.
Autores: Walter Santos de Carvalho, Felipe Pereira Delage e Flavio Alexandre Martins

Atualmente, é comum nas corporações que vários servidores de bancos de dados estejam em produção com o SQL Server. Além disso, muitas vezes este ambiente é crítico e necessita de atenção diária em vários pontos como, por exemplo, espaço em disco, backups realizados, mensagens de erros da instância e do sistema operacional.

Quando um servidor está com pouco espaço em disco e por questões burocráticas não se pode comprar um novo disco e adicioná-lo de forma rápida ao servidor, o espaço livre se torna valioso, devendo ser monitorado a todo momento. Outro exemplo acontece quando se trabalha em um ambiente mais complexo com Failover Cluster, onde os dados estão armazenados em LUNs dentro de um Storage.

Especificamente neste cenário, mesmo que o Storage tenha bastante espaço não alocado que possa ser disponibilizado para as LUNs, não é uma boa prática simplesmente aumentar o espaço das mesmas sem definir uma quantidade que realmente atenda a demanda, pois deixar espaço livre em excesso nas LUNs ou em determinada LUN é um desperdício que deve ser evitado.

Nestes casos, quando for solicitada a criação de uma LUN para armazenar outros bancos de diferentes projetos e a nova LUN precisar de muitos gigabytes inicialmente, pode ser que o espaço alocado desnecessariamente em outras LUNs faça falta (ver BOX 1).

BOX1. LUN

LUN é uma unidade lógica ou um disco de um Storage. Através do uso de LUNs é possível obter uma flexibilidade que é muito importante no armazenamento de grandes volumes de dados e em ambientes críticos, pois as unidades lógicas podem ser movidas ou, em outras palavras, migradas para servidores diferentes de uma forma prática, garantindo uma indisponibilidade muito baixa para acesso aos dados contidos nelas.

Imagine um cenário no qual uma LUN de 100GB, ativa há anos, esteja 99% cheia, com bancos de clientes acessados frequentemente sofrendo inserções e atualizações de dados que geram uma média de crescimento mensal da LUN de 2GB.

Além disso, suponha que essa LUN esteja alocada em um Storage de 10 Terabytes que hospeda várias LUNs que também demandam crescimento constantemente e este Storage no momento encontra-se com apenas 300GB de espaço não alocado. Espaço este que pode acabar rapidamente se várias LUNs precisarem crescer ao mesmo tempo.

Em um ambiente como este, não se pode deixar acabar o espaço livre onde estão os arquivos de banco do SQL Server, pois as aplicações que escrevem no banco não conseguirão mais inserir ou alterar dados. Diante disso, torna-se necessário crescer a LUN para que ela tenha mais espaço livre.

Vale ressaltar aqui que não existe um número ideal para crescimento da LUN. Existe sim um custo benefício que deve ser analisado. Assim, se optarmos por aumentos curtos, algo em torno de 10GB a 30GB, teremos que nos preocupar com a monitoração do tamanho da LUN constantemente de forma mais recorrente, para evitar que se esgote dentro da unidade lógica.

Se crescermos 100GB, por exemplo, não será preciso nos preocuparmos com esta unidade lógica tão cedo, porém o Storage que estava com 3% de espaço não alocado passará para 2%.

Como mencionamos anteriormente, em algum momento pode ser indicada a criação de novas LUNs ou aumentar o tamanho das demais existentes.

Por isso, é uma boa prática adicionar espaço nas LUNs de acordo com a demanda, para que o Storage sempre tenha espaço não alocado que possa ser adicionado às LUNs que realmente necessitem.

Pensando neste problema vamos propor neste artigo um meio de monitorar recursos ou eventos que acontecem em instâncias e em servidores de banco de dados montando um mecanismo de mo" [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?