Category Archives: MCM

Quem é o responsável por garantir os dados da minha database?

Ola pessoal,

Iniciando o aprofundamento dos estudos sobre os componentes do SQL Server, vou ser breve em mostrar quem é o responsável por garantir a integridade da minha database. O que muitas vezes vemos errorlog do SQL Server sao essas frases:

Recovery completed for database master (database ID 1) in 2 second(s) (analysis 691 ms, redo 318 ms, undo 602 ms.) This is an informational message only. No user action is required.

ou

1 transactions rolled forward in database ‘AdventureWorksDW’ (6). This is an informational message only. No user action is required.

ou

10 transactions rolled back in database ‘AdventureWorksDW’ (6). This is an informational message only. No user action is required.

Ai eu te pergunto quem realiza essas operaçoes? E voce me responde que isso é de responsabilidade das operacoes UNDO e REDO.

Por parte isso esta certo, mas ainda assim por traz desses dois nomes temos um processo por traz disso tudo chamado de WRITE-AHEAD LOGGING.

Toda essa magica de sincronização acontece graças a esse agente que é garantido que cada mudança ocorrida é enviada primeiramente para o transaction log antes que digamos que esteja como commitada, e que os registros do log são sempre escritos no disco antes que as paginas de dados onde as mudanças foram atualmente feitas sejam escritas.

Vale lembrar que a escrita nas paginas de dados muitas vezes ocorrem de forma assíncrona, pois todas as mudanças podem ser recuperadas do arquivo de log se necessário. É importante lembrar também que o componente de gerenciamento do transaction log gerencia também a operacao de logging, recoverying, e gerenciamento do buffer.
Temos ainda um tipo de wait para ele que se chama WRITELOG. Em um outro post em um outro dia vamos falar um pouco dele.

Espero que tenham gostado desse post, tentei ser o mais simples possivel. A medida que os estudos forem avançando, vou avançando o conteudo dos posts.. so…. stay tuned !!

Att,
Marcos Freccia
[MCTS|MCITP|MCT SQL Server 2008]

 

O que LazyWriter e Checkpoint tem em comum?

Bom pessoal,

Falar de assuntos internos do SQL Server é sempre complicado, porem acho extremamente importante falar desses dois processos internos do SQL Server e no que eles são tao parecidos, porem é claro possuem suas particularidades. Para entendermos melhor o que cada um faz vamos colocar uma breve descriçao de cada processo.

Checkpoint

Checkpoint escreve as paginas de dados sujas (modificadas) que estavam em memoria para o disco. O principal proposito deste processo é reduzir o tempo de recuperacao da base de dados, entao quando voce ve no errorlog: “20 transactions rolled forward in database ‘master'” é o Checkpoint realizando seu trabalho de sincronizar os arquivos LDF e MDF, que chamamos de fase UNDO e REDO.

LazyWriter

Periodicamente examina o data cache e escreve as paginas sujas (modificadas) no disco. Uma vez escrita a pagina então volta para a lista de paginas disponíveis, que manterão um certo nível de buffers livres para outras threads. O processo do LazyWriter seleciona as paginas de dados a partir de um algoritmo que marca as paginas que nao foram modificadas e/ou referenciadas por um periodo de tempo. 

Mas o que os dois possuem em comum?

Vimos que o papel dos dois processos é liberar espaço no data cache para a entrada de novos dados, retirando aqueles que foram modificados, ou que por um período de tempo não foram referenciados. Mas a grande jogada desses dois processos é que o LazyWriter que fica na camada do SQLOS atua somente quando existe uma pressão de memoria na instancia do SQL Server, fora esse caso em especifico o Checkpoint é o responsavel por realizar o gerenciamento das paginas de dados no Data Cache.

Pessoal, como viram esse post foi não teve nenhuma parte  pratica.. mas espero que tenha passado de uma maneira simples como funcionam esses dois processos do SQL Server.

Att,
Marcos Freccia
[MCTS|MCITP|MCT SQL Server 2008]

Planejamento de ambientes em SQL Server – MCM Pre-reading list

Pessoal,

Continuando a serie de posts, vamos colocar aqui quais os passos a serem tomados no momento de um projeto em SQL Server. Nos demais dias irei postando mais detalhes desse primeiro escopo.

Planejamento de ambientes em SQL Server 2008

Quais são os passos a serem avaliados?

  1. Quais aplicações estão no escopo do projeto?
    1. Os resultados desse passo irão determinar quais serão as roles do SQL Server necessárias.
  1. Determinar quais roles do SQL Server serão necessárias.
    1. Tarefa 1: Database Engine é necessário?
    2. Tarefa 2: Integration Services é necessário?
    3. Tarefa 3: Analisys Services é necessário?
    4. Tarefa 4: Reporting Services é necessário?
    5. Tarefa5: Master Data Services é necessário?
  1. Desenhar a infraestrutura necessária para a Database Engine.
    1. Tarefa 1: Determinar capacidade e desempenho.
      1. Storage necessita ser calculada para as bases de dados, transaction logs, índices e tempdb.
      2. Após estimar o tamanho da base de dados (formula fornecida no documento), adicione mais 5% por base de dados para overhead.
    1. Tarefa 2: Determinar se colocar a base de dados em uma instancia já existente
    2. Tarefa 3: Determinar se colocar a instancia em um servidor rodando SQL Server ou em um novo servidor.
    3. Tarefa 4: Determinar o numero de servidores depois de endereçar as necessidades de escalonamento e tolerância a falhas.
    4. Tarefa 5: Determinar a localização de cada nova instancia
    5. Tarefa 6: Determinar o hardware para o servidor.
  1. Desenhar a infraestrutura do SQL Server Integration Services
    1. Tarefa 1: Determinar os requerimentos.
    2. Tarefa 2: Determinar onde os pacotes do Integration Services serão armazenados.
    1. Tarefa 3: Determinar o numero de servidores para o SSIS.
    1. Tarefa 4: Determinar a localização.
  1. Desenhar a infraestrutura do SQL Server Analysis Services
    1. Tarefa 1: Determinar os requerimentos.
      1. SSAS utiliza bases de dados OLAP, ou cubos, armazenados no sistema de arquivos.
      2. Processamento da base de dados OLAP realiza muita leitura/escrita.
      3. Grupo de produto recomenda 4 – 8 GB de memoria por core de processador.
    1. Tarefa 2: Determinar a versão do SQL Server.
    2. Tarefa 3: Determinar se as bases de dados serão escaláveis e compartilhadas.
    3. Tarefa 4: Determinar os requisitos para escalonamento
    4. Tarefa 5: Determinar se será em cluster
    5. Tarefa 6: Determinar a localização.
  1. Desenhar a infraestrutura do Reporting Services.
    1. Tarefa 1: Determinar os requerimentos
      1. Discos de storage para as bases do SSRS
      1. Memoria: 2 – 4 GB por core.
    1. Tarefa 2: Determinar a localização das bases de dados do Reporting Services.
      1. As bases de dados podem ser colocadas ou no servidor de Reporting Services ou em servidor remoto.
    1. Determinar a abordagem de tolerância a falha e escalonamento.
      1. Load Balance tanto para escalonamento quanto tolerância a falha.
      1. Cluster para as bases de dados
  1. Desenhar a infraestrutura para o SQL Server Master Data Services.
    1. Tarefa 1: Determinar os recursos.
    1. Tarefa 2: Determinar a abordagem para tolerância a falha e escalonamento.
    1. Tarefa 3: Determinar a localização das bases de dados do Master Data Services.
    1. Tarefa 4: Determinar a localização do Web server do Master Data Services.

MCM – Pre Reading list

Ola Pessoal,

Para iniciarmos nosso ano bem, vou colocar a lista de pre-leitura do MCM. Façam bom proveito.

Atualizado a lista de leitura. Robert Davis (Twitter| Blog) passou a lista correta e que também possui muito mais recursos disponíveis.

http://www.microsoft.com/learning/en/us/certification/master-sql-path.aspx#mcm-microsoft-sql-server-2008-readiness

Att,
Marcos Freccia
[MCTS|MCITP|MCT SQL Server 2008]