Realizar diversas alterações no servidor de forma a incrementar o máximo de performance

Transcrição

1 Performance: Realizar diversas alterações no servidor de forma a incrementar o máximo de performance Porto, 18 de Fevereiro 2011

2 Índice Introdução...1 Estado da arte Aquisição de novos discos com consequente criação de novo volume Alteração do tamanho e distribuição do swap file entre os discos Desfragmentação dos discos Alteração de configuração do SQL Server ao nível dos seus ficheiros físicos Criação de DB nova Alteração de uma DB existente Criação de novo filegroup para manutenção de índices Criação de diversos ficheiros secundários (*.ndf) para divisão do ficheiro principal de dados (*.mdf) Shrink do log file...15 Conclusão...16

3 Introdução O tema da segurança e da performance sempre foi um dos mais importantes na área de tecnologias de informação. Evidentemente que a maior parte dos programadores não se preocupa muito com isto, o que desejam é criar aplicações que tenham acesso aos dados, ou seja, que funcionem. Quando se criam aplicações é necessário ter em atenção o conceito de rapidez, o utilizador necessita de velocidade. É necessário ter em atenção a criação de páginas html não utilizando lixo desnecessário, é necessário verificar e testar um pedido SQL, não utilizar campos SQL que não sejam necessários, especificar bem o tipo de campo (inteiro ou real?), colocar índices nas tabelas, etc. Por outro lado, num patamar mais ao nível do hardware, é necessário ter atenção aos aspectos físicos do servidor e à forma como os blocos de informação estão lá armazenados. Este paper foi criado com o intuito de alterar configurações ao nível físico dos dados. Estado da arte Foram efectuadas verificações no servidor e existem algumas mudanças necessárias para obtenção de melhor performance global: 1. Aquisição de novos discos com consequente criação de novo volume 2. Alteração do tamanho e distribuição do swap file entre os discos 3. Desfragmentação dos discos 4. Alteração de configuração do SQL Server ao nível dos seus ficheiros físicos Estas alterações serão graduais e faseadas. 1

4 1 - Aquisição de novos discos com consequente criação de novo volume O servidor tem actualmente 6 discos SCSI de 146 GB cada, formando um volume em RAID5 (Redundant Array of Independent Disks - strip set with parity). O RAID5 é uma boa opção para leitura de dados assegurando a segurança dos mesmos. Se um dos discos falhar, a paridade guardada em todos eles assegura que nada se perca até à substituição do disco em falha. Já na escrita, o RAID5 tem comportamento inferior, precisamente porque necessita de guardar além dos dados em todos os discos, também a informação de paridade o cálculo da paridade é realizado pelo processador da controladora SCSI, o que demonstra perfeitamente a vantagem do RAID por hardware em relação ao RAID por software (embora este fique mais barato). No RAID5, a informação de dados e de paridade é escrita em todos os discos. Desta forma, o espaço utilizável é de 730 GB. A paridade ocupa uma totalidade de 146 GB, ou seja GB em cada disco. VolumeLivre HD HDmenor HDmenor 1 Paridade HDmenor HD O volume de disco do servidor é constituído por duas drives lógicas: C e D. A Drive C:\ contém o sistema operativo e a drive D:\ os dados, nomeadamente as DBs do SQL. Por si só, esta já foi uma boa opção aquando da instalação do SQL Server. Com a aproximação à ocupação máxima da drive D:\ foi necessário adquirir mais discos. O servidor permite, ainda, a alocação de mais dois slots para colocação de discos. Com a aquisição de mais discos surgiram dúvidas se estes deveriam ser iguais, superiores, se seria para colocar no mesmo volume, se em volumes separados; se ficariam sem tolerância a falhas, ficando mais espaço livre, se... Por fim, já após alguma discussão, foram elaboradas duas hipóteses: 1 Uma hipótese seria colocar dois discos de igual capacidade e incorporar no RAID5 existente. No RAID5 todos os discos deverão ser da mesma capacidade, caso contrário o volume é baseado na unidade mais pequena. Desta forma, ficariam adicionados mais 292 GB de espaço total ao volume existente proporcionando um valor total para colocação de dados de 1022 GB na prática, seria como que não se perdesse espaço algum nos discos novos, mas não é verdade; a verdade é que o espaço ocupado agora pela informação de paridade em cada disco é menor, é de GB. 2 A outra hipótese seria a aquisição de discos de maior capacidade, de 300 GB cada um (indicado pela própria Fujitsu como sendo o maior para a máquina em questão), e colocar os mesmos num novo volume, independente do actual, mas sempre capacitado para tolerância a falhas. 2

5 Optou-se pela segunda hipótese, tendo sido criado um volume independente do actual em RAID1, Mirror, permitindo um espaço útil de gravação de dados de 300 GB; os outros 300 GB servem para efectuar o espelhamento. Em RAID1, existe sempre a mesma informação nos dois discos, logo, se algum dos dois falhar, não se perdem os dados. Com esta implementação, pretendia-se o incremento de espaço livre para guardar dados e, simultaneamente, a divisão de ficheiros físicos entre volumes diferentes. Desta forma, contribuímos para a performance geral do servidor, nomeadamente dos ficheiros do SQL Server separando os ficheiros de dados dos ficheiros de logs, por exemplo e do swap file do sistema operativo. Como configuração final, o servidor ficou com dois volumes de discos com a seguinte estrutura: RAID5 (Strip Set with Parity) RAID1 (Mirror) Número de Discos: 6 Capacidade por disco: 146 GB Capacidade de Armazenamento: 730 GB Número de Discos: 2 Capacidade por disco: 300 GB Capacidade de Armazenamento: 300 GB Drives lógicas: C:\, D:\ Drives Lógicas: H:\ RAID5 RAID1 3

6 2 - Alteração do tamanho e distribuição do swap file entre os discos Com a criação do novo volume cuja drive lógica é H:\, implementou-se a alteração da localização e tamanho do ficheiro de memória física (swap file) do sistema operativo. Colocou-se o swap file distribuído pelos dois volumes com cerca de metade do tamanho desejado para cada um. Na drive D:\ ficaram cerca de 20 GB e na drive H:\ outros 20 GB. Optou-se por manter o swap file de 2 GB na drive C:\.. Com isto, mantemos um swap de cerca de 1,5 vezes o valor total de memória RAM que é de 32 GB. 3 Desfragmentação dos discos A performance de qualquer computador passa por um óptimo desempenho no acesso aos discos. Este acesso é tanto mais rápido quanto menor for a fragmentação. A fragmentação desenvolve-se com a constante criação e eliminação de dados nos discos, sendo os ficheiros das DBs um problema diário uma vez que estas têm constantes updates, inserts e deletes. O próprio swap file do sistema operativo, se não tiver um comprimento constante vai criar muita fragmentação. Torna-se necessário instalar algum aplicativo de desfragmentação. Testei a versão trial do Diskeeper 2010 e foi absolutamente funcional. Durante algum tempo tive o acesso ao volume de discos com a melhor performance. Poderei citar o caso dos backups: com o disco fragmentado terminavam às 6:30 e após a desfragmentação começaram a terminar por volta das 5:00 entre 23 Setembro e 14 de Outubro. Após o término da licença do software, os backups começaram gradualmente a terminar cada vez mais tarde, culminando nas 8 da manhã. A isto agravou-se o incremento gradual de informação. 4

7 4 - Alteração de configuração do SQL Server ao nível dos seus ficheiros físicos O SQL Server foi inicialmente instalado na drive D:\, uma partição diferente da do sistema operativo. O SQL Server ficou, por default, a criar os ficheiros das novas DBs na drive D:\SQL\Data, de dados e de logs. Com a aquisição dos novos discos e criação de novo volume, optou-se por separar os ficheiros de dados dos logs. Desta forma, o acesso aos dados e logs pode ser feito em paralelo pois estão em volumes diferentes e, ainda mais importante, em discos diferentes, havendo, portanto, um incremento de performance. Há que ter em atenção alguns pormenores no manuseamento de ficheiros das DBs do SQL nas seguintes situações: 1 - criação de DB nova, a. onde é possível escolher a localização dos ficheiros da DB a criar 2 - alteração de uma DB existente, a. onde é necessário alguns procedimentos para conseguir alterar a localização dos ficheiros existentes 3 - criação de novo filegroup para manutenção de índices 4 - criação de diversos ficheiros secundários (*.ndf) para divisão do ficheiro principal de dados (*.mdf) 5 - Shrink do Log File 1 Criação de DB nova Na criação de nova DB é possível escolher a localização dos ficheiros que a constituem. Assim, podemos escolher o path D:\SQL\Data para o ficheiro de dados e o H:\SQL\Data para o ficheiro de log. Mais à frente, veremos como se cria um terceiro ficheiro para inclusão dos índices na DB, sendo também colocado na drive H:\SQL\Data. Pela figura seguinte, poderemos ver a nova DB DM_nova cujos ficheiros: de dados - chamar-se-á DM_nova.mdf e ficará em D:\SQL\Data de log - chamar-se-á DM_nova_log.ldf e ficará em H:\SQL\Data 5

8 Nesta nova DB poderíamos criar já um segundo Filegroup, tal como veremos mais à frente, para inclusão de outros objectos da DB contribuindo, assim, para uma melhor performance. 2 - Alteração de uma DB existente Nas DBs já existentes, e uma vez que a criação por default estava para colocação dos ficheiros de dados e de log no mesmo compartimento, a alteração de localização física dos ficheiros requer alguns procedimentos: Detach da DB em questão (ou colocar offline) Copiar o ficheiro de log para nova localização, neste caso para H:\SQL\Data. O ficheiro de log original (existente em D:\SQL\Data) deverá ser renomeado e não apagado, para o caso de... Attach de DB, alterando o caminho do ficheiro de log (path) para a nova localização (que, entretanto, estará a dar erro dizendo que não o encontra). Desta vez vou tomar por opção a DB Historico. Esta DB está com os ficheiros de dados (mdf e ndf) e de log (ldf) no mesmo local físico do disco, em D:\SQL\Data: Windows Explorer SQL Database Properties Na janela anterior da DB Properties, o botão que permitiria alterar a localização do ficheiro de log (path) não aparece, portanto, não é permissível esta operação. Detach da DB Uma das formas de poder trabalhar com os ficheiros de uma DB é colocar a mesma offline ou então efectuar o Detach. Nesta altura ninguém conseguirá aceder aos dados, muito cuidado! Façamos o Detach: Right-click na DB desejada, neste caso Historico Clicar Tasks, seguido de Detach... 6

9 Note-se que se existir algum utilizador no momento a aceder à DB aparece na coluna Message da mesma janela: Na janela do Detach Database, basta fazer OK. Com isto, poderemos copiar, renomear, apagar, qualquer ficheiro da DB uma vez ela estar offline. Muito cuidado, e sempre com a garantia da existência de backups funcionais! Copiar o ficheiro de log para nova localização Neste momento, poderemos copiar o ficheiro de log para outra localização. Vamos colocá-lo em H:\SQL\data. O ficheiro é o que tem a terminação LDF. O ficheiro original deverá ser mantido por algum tempo devendo ser apenas renomeado. Após confirmação de que tudo está bem pode-se eliminar. Assim, ficará a seguinte estrutura a ser acedida em volumes diferentes: Dados Log D:\SQL\Data\*.MDF e *.NDF H:\SQL\Data\*.LDF Attach de DB Por fim, basta fazer o Attach da DB Historico por forma a colocar a mesma online. 7

10 Na janela anterior, Attach Databases, é necessário: Clicar em Add Localizar em D:\SQL\Data\Historico.MDF e fazer OK Após isso, poderá verificar-se que nos Database Details existe um erro de localização do ficheiro de log que ainda está a apontar para a localização inicial. Na coluna do Current File Path deve-se alterar a localização deste ficheiro, indicando a nova localização (no caso H:\SQL\Data\Historico_log.LDF) Premir a tecla de OK para finalizar o processo de Attach Em conclusão, a DB Historico já está funcional e a utilizar ficheiros de dados e de logs em volumes de discos diferentes. 3 - Criação de novo filegroup para manutenção de índices Procedeu-se, também, à criação de um segundo FileGroup para cada DB de forma a colocar neste apenas os índices. Posteriormente, este filegroup poderia ser inserido num ficheiro numa localização diferente do ficheiro dos dados. A mudança de índices de um Filegroup para outro implica alguns procedimentos: 1. Criar segundo Filegroup em cada DB 2. Criar código para listar todas as tabelas que contêm índices, para cada DB 3. Abrir as propriedades de cada tabela listada anteriormente e alterar a localização dos índices para outro Filegroup (previamente criado na DB) 1 - Criar segundo Filegroup em cada DB No nosso servidor existe um DB que se chama Performance. Tomemos esta como exemplo para criar um segundo filegroup para os índices. No Management Studio do SQL, na DB Performance, Right-click em cima da DB Performance Seleccionar Properties Escolher o tema Filegroups Clicar em Add para adicionar um segundo Filegroup nesta DB e especificar o respectivo nome. Optei por chamar Ix. 8

11 Seguidamente, é necessário criar o ficheiro no disco para incluir apenas objectos colocados no segundo filegroup, neste caso apenas os índices. Clicar no tema Files Clicar em Add para adicionar novo ficheiro na Drive H:\SQL\Data para os índices. Este novo ficheiro será associado ao filegroup Ix. Para finalizar, é necessário listar as tabelas que contêm índices e alterar para cada uma delas o respectivo filegroup a utilizar que implicará nova localização do ficheiro, separado do ficheiro de dados. 2 - Criar código para listar todas as tabelas que contêm índices, para cada DB Foi criado um código SQL que permite visualizar os índices de cada tabela e em que filegroup se encontram. Mais uma vez, tendo por base a DB Performance: use performance quais os indíces de cada tabela e onde estão SELECT o.[name], o.[type], i.[name], i.[index_id], f.[name] FROM sys.indexes i INNER JOIN sys.filegroups f ON i.data_space_id = f.data_space_id INNER JOIN sys.all_objects o ON i.[object_id] = o.[object_id] WHERE i.data_space_id = f.data_space_id AND o.type = 'U' -- User Created Tabl order by o.name,f.name O resultado deste query é o seguinte: 9

12 Verifica-se que na DB Performance existem dois índices, em duas tabelas distintas. O filegroup associado é o mesmo, isto é, o Primary. A ideia é alterar este filegroup para o segundo filegroup criado anteriormente, o Ix. 3 - Abrir as propriedades de cada tabela listada anteriormente e alterar a localização dos índices para outro Filegroup (previamente criado na DB) A alteração do filegroup na DB só é possível se os índices criados não forem do tipo Cluster. Vamos, então, tentar alterar a localização dos índices. No Management Studio do SQL, nas DB Performance, Expandir a DB Performance Expandir as Tables Expandir a tabela em questão, onde existe o índice Right-click em cima do índice respectivo e escolher Properties Verifica-se que este índice é do tipo Nonclustered, logo pode ser alterado. Clicar em storage Alterar o Filegroup para o Ix criado. Fazer OK 10

13 Agora, se for executado o código SQL anterior, verifica-se que o índice já se encontra noutro filegroup, noutra localização do disco: Vamos tentar agora para a segunda tabela, a que continha outro índice. Seguindo os mesmos passos anteriores, obtemos a seguinte figura: Verifica-se, portanto, que este índice é do tipo Cluster não podendo ser alterado: Podemos tentar fazer alguma alteração no código SQL anterior de forma a listar apenas as tabelas que têm índices NonClustered... 11

14 4 Criação de diversos ficheiros secundários (*.ndf) para divisão do ficheiro principal de dados (*.mdf) O SQL, ao criar novas DB cria dois ficheiros, um de dados (mdf) e outro de logs (ldf). Quando as DB são pequenas não existe problema, agora quando chegam à grandeza dos gigabytes tudo se complica. Trabalhar apenas com um ficheiro muito grande pode originar diversos problemas, como o timing de acesso, o problema dos backups, sendo que um ficheiro muito grande será mais difícil de armazenar do que diversos ficheiros mais pequenos até se podem colocar em diversos DVDs. O SQL Server permite separar um ficheiro principal de dados (mdf) em diversos mais pequenos (ndf), sendo repartido o seu conteúdo por todos os outros ficheiros, desde que estes estejam dentro do mesmo grupo do ficheiro de dados, isto é, pertencendo ao mesmo filegroup. Tomemos como exemplo a DB SIG_Historico. Esta DB tinha no momento cerca de 35 GB de tamanho. A ideia é criar quatro ficheiros secundários (ver nota abaixo) de forma a migrar os dados do ficheiro original para estes, repartindo o espaço para cerca de 9 GB cada um. Vamos então criar os ficheiros: Righ-click na DB SIG_Historico Seleccionar Properties Escolher o tema Files Clicar em Add, para adicionar nova linha com novo ficheiro Especificar o nome optei por dar o mesmo nome do ficheiro inicial com terminação numérica sequencial No filegroup, assegurar que indica o mesmo tipo do ficheiro inicial, neste caso Primary No path podemos escolher uma localização física diferente. Optei por manter. Nota: A Microsoft refere que o número ideal de ficheiros é o mesmo que o somatório de cores de todos os CPUs. Assim, se o servidor tiver 4 CPU, cada um com 4 cores, o número de ficheiros ideal será 16. N º Files Cores 12

15 Neste momento existem 5 ficheiros de dados, o original SIG_Historico.mdf e mais 4 SIG_HistoricoN.ndf. O passo a seguir é esvaziar o conteúdo do ficheiro principal e passar para os outros 4 ficheiros. Para tal: Righ-click na DB SIG_Historico Seleccionar Tasks Seleccionar Shrink Escolher o tema Files Assegurar que a DB file name e Location são as desejadas, conforme figura abaixo, e na acção do Shrink escolher a terceira opção, isto é, Após premir OK, a janela no Shrink file SIG_Historico fica com o seguinte aspecto, em estado de execução: 13

16 Dependendo do tamanho da DB inicial, esta operação pode demorar horas. Neste exemplo esteve praticamente 20 horas, e a DB tinha somente 34 GB. O procedimento pode ser efectuado mesmo existindo acessos à DB claro que demorará mais. O resultado da operação foi o seguinte: No final do shrink o SQL deu um pequeno erro, que provavelmente fez com que se mantivessem os 34 GB no ficheiro inicial, caso contrário estaria quase a zero. Não consegui reproduzir o erro... Mas isso não é problema. Basta ir à janela do Shrink SIG_Historico novamente e desta vez escolher a primeira acção para libertar o espaço não utilizado: Assim, após este procedimento, o espaço ocupado pelo ficheiro inicial é de 3 MB: Pelo que dizia a terceira acção (empty file by migrating...), é suposto o ficheiro SIG_Historico.mdf ficar vazio significando que se poderia apagar...deixo isso para outra ocasião, talvez o faça com uma DB de testes! 14

17 5 - Shrink do log file O ficheiro de log (ldf) pode crescer para valores muito altos (baixa após ser efectuado um backup à DB), dependendo do número de transações efectuadas ao longo do dia - no exemplo anterior vemos que ocupa cerca de 8 GB; mas pode salvar muitos dados (e o nosso trabalho!) pois em caso de desastre serve para colocar a DB funcional até à hora em que este aconteceu (juntamente com o backup integral da DB do dia anterior). Portanto, o ficheiro de log deve ser sempre mantido!.....a não ser que o espaço ocupado pelo log seja necessário para algo mais importante (deixem o vosso chefe decidir assegurando que ele fica a saber da possível perda de dados). Nesse caso, podem executar o seguinte código SQL tentando esvaziar o ficheiro de log. Pode verificar-se, então, que o ficheiro diminui bastante, ficou praticamente a zero: Já temos espaço livre para as necessidades extras, mas só mesmo se for necessário, caso contrário deve ser efectuado um backup à DB, possivelmente durante a noite, e nessa altura o log diminui automaticamente. 15

18 Conclusão Este paper não pretende ser um manual sobre performance mas sim uma ajuda prática para qualquer DBA. Outros procedimentos poderiam ser especificados mas fica para outra altura. Todo este trabalho foi demorado e faseado e continuará a ser na medida em que não termina aqui. Será sempre necessário estar atento à evolução do espaço ocupado pelos ficheiros e criar mais réplicas se for o caso para balancear os dados. Algumas destas alterações notam-se mais em ambientes de 64 bits onde o multiprocessamento é algo natural, nomeadamente na leitura de diversos ficheiros da mesma DB, bem como no carregamento em paralelo a partir de outro disco. Continua em estudo e teste um ambiente com desfragmentador para verificar qual é o mais desejável. O Diskeeper 2010 foi o primeiro e perece-me o melhor. Estou a testar o Perfectdisk11 mas demora demasiado a desfragmentar. Tenho outro software para testar posteriormente, o O&O Defrag. Todas as alterações, todos os programas a utilizar, têm de ser devidamente testados, sob o risco de não funcionarem correctamente no nosso ambiente. Tal procedimento deverá ser idêntico nos testes com as DBs do SQL Server. Urge um ambiente de testes, diferente de um de desenvolvimento e muito menos de um de produção. Desta forma, mesmo que algo não corra como planeado não deverá haver grande problema. Só após as alterações estarem devidamente consolidadas se deverá actuar no ambiente de produção. No nosso caso, foram efectuadas alterações ao fim do dia, em horas pós laborais por forma a não impedir os utilizadores de acederem correctamente aos dados. Como resultado final, temos um servidor que consegue responder mais rapidamente aos utilizadores, não cria tantos bloqueios no SQL, permitindo mais operações simultâneas. Além disso, ficamos com a consciência de que foram seguidas algumas boas práticas. Pelo menos até nos lembrarmos de algo melhor! 16