Jen and Sean McCown, the most famous DBA couple, from Midnight SQL, created the ultimate indexing solution for professional DBAs called Minion Reindex.
They made a lot of documentation explaining the whole thing including tutorial videos.
And now the best: it's all FREE !
The installation process is super easy, just executing a single script on your server.
It creates all the Jobs for you, to run the reindexing procedures.
I just downloaded the solution and I am looking at the documentation.
I have to say, it's a very professional material.
It's also possible to change all the parameters desired, e.g. FillFactor, PadIndex, SortInTempDB.
Their credentials: Jen is a SQL Server MCM and Sean is SQL Server MCM and MVP.
Check it out at: http://www.midnightsql.com/Minion/
sexta-feira, 12 de dezembro de 2014
quarta-feira, 10 de dezembro de 2014
MVA - Academia Virtual Microsoft
A dica do dia é APRENDER !
Como aprender nunca é demais...
Se você tem tempo disponível, ou como eu, trabalha ouvindo as aulas da faculdade no fone de ouvido, pra maximizar o tempo, tenho uma excelente dica.
A Microsoft Virtual Academy - MVA:
http://www.microsoftvirtualacademy.com/
Neste portal da Microsoft é possível realizar cursos de todos os seus produtos.
No momento estou fazendo um curso de SQL Server 2012, em Português !
É simplesmente fantástico, e você acumula pontos ao longo dos cursos.
O resgate dos pontos acumulados garante a evolução nos níveis de associação:
Nível Bronze: de 0 a 99 pontos;
Nível Prata: 100 a 499 pontos;
Nível Ouro: 500 a 2999 pontos;
Nível Platina: 3000 pontos ou mais.
Bons estudos!
Como aprender nunca é demais...
Se você tem tempo disponível, ou como eu, trabalha ouvindo as aulas da faculdade no fone de ouvido, pra maximizar o tempo, tenho uma excelente dica.
A Microsoft Virtual Academy - MVA:
http://www.microsoftvirtualacademy.com/
Neste portal da Microsoft é possível realizar cursos de todos os seus produtos.
No momento estou fazendo um curso de SQL Server 2012, em Português !
É simplesmente fantástico, e você acumula pontos ao longo dos cursos.
O resgate dos pontos acumulados garante a evolução nos níveis de associação:
Nível Bronze: de 0 a 99 pontos;
Nível Prata: 100 a 499 pontos;
Nível Ouro: 500 a 2999 pontos;
Nível Platina: 3000 pontos ou mais.
Bons estudos!
sábado, 6 de dezembro de 2014
Chave Primária vs Indice Unico (PK x UQ)
Olá aos visitantes!
Concorda, discorda, alguma sugestão ?
Gostaria de dar uma dica super importante, aos que estão tendo dificuldades com índices em tabelas com muitos registros.
Todos aprendemos no processo de Normalização dos dados, a sempre criar uma chave primária (PK) em todas as tabelas do banco.
Pois bem, o que muitos não percebem, é que este é o momento mais importante na vida de uma tabela!
Tá, exagerei um pouco no transcendentalismo, mas é sério !
No momento em que estamos definindo a chave primária (PK) de uma tabela, talvez estejamos desperdiçando o índice mais importante para ela.
É de praxe criarmos uma chave primária (PK) na 1a. coluna da tabela, de Funcionários ou Clientes, por exemplo, sem nem ao menos pensar no que estamos fazendo.
Minha hipótese é que isto ainda ocorra, talvez por causa de um velho hábito que os programadores do sistema dBase (Clipper, Paradox, etc.) tinham na criação de tabelas, onde a chave primária garantiria a ordem física dos registros.
Como as tabelas do exemplo acima, teoricamente, contém poucos registros, isto não geraria muito impacto na performance.
Mas numa tabela gigante, por exemplo, com milhões de registros, a coisa fica séria.
Considere, por exemplo, uma tabela-header de Notas Fiscais de Venda fictícia, com os seguintes atributos:
Código, Data, CFOP, Cliente, Documento, Valor Total, Transportadora, Observações, etc.
Em 99% dos casos que já tive a oportunidade de visualizar a estrutura desta tabela, nos sistemas que costumo analisar em minhas consultorias, há uma chave primária (PK) definida na coluna Código.
Considero isto um erro grave, um desperdício de índice.
No SQL Server, há uma mudança de paradigma em relação ao sistema dBase, a chave primária (PK) cria automaticamente um Clustered Index, ou seja, um índice físico.
O índice físico é o mais utilizado e o mais rápido em qualquer busca de registros em uma tabela, pelo menos na maioria dos casos.
O índice físico é o mais utilizado e o mais rápido em qualquer busca de registros em uma tabela, pelo menos na maioria dos casos.
Desta forma, um índice físico em cima da coluna Código seria totalmente inútil, porque neste caso, acredito que a busca mais utilizada nos relatórios não seja nesta coluna em específico.
Se você simplesmente precisa garantir que não haja 2 registros com o mesmo código, sugiro que crie apenas um índice único nesta coluna, conforme abaixo:
CREATE UNIQUE INDEX iCodigo ON NotaFiscal (Codigo)
go
E para garantir a melhor performance nas suas buscas, considere por exemplo, as colunas Data e Cliente como as mais utilizadas nos relatórios do seu sistema.
Para elas então, crie um índice físico:
CREATE CLUSTERED INDEX iNotaFiscal ON NotaFiscal (Data, Cliente)
go
Os índices do tipo UNIQUE também permitem a criação de Chaves Estrangeiras (FOREIGN KEYS), ou seja, não perde-se assim, a 2a. principal função da chave primária.
Em um ambiente OLTP, onde ocorre muitas inclusões por minuto, ou até por segundo, sugiro uma análise mais cuidadosa, pois o tempo gasto na reorganização dos dados a cada Insert pode comprometer a estratégia, mas a dica ainda é válida.
Nos meus testes, em um ambiente controlado, a inclusão de 100 mil registros em uma tabela teste levou:
- 22 segundos: com um índice Clustered nas colunas Data e Cliente + índice Único na coluna Código;
- 27 segundos com uma Chave Primária na coluna Código.
Após a inclusão, foi realizado uma consulta básica com as colunas Data e Cliente na cláusula WHERE, e o Plano de Execução analisado:
- utilizando a estratégia sugerida, de índice Clustered nas colunas Data e Cliente, atingiu-se o objetivo esperado, ou seja, o Plano de Execução retornou a busca como Clustered Index Seek;
- utilizando o método antigo, de Chave Primária na coluna Código, o método da busca utilizado foi Clustered Index Scan, ou seja, o SQL precisou fazer um Scan em todas as linhas para obter o resultado.
Espero desta forma, ter demonstrado o melhor aproveitamento do índice Clustered de uma tabela, em colunas que realmente serão utilizadas nas buscas.
Nos meus testes, em um ambiente controlado, a inclusão de 100 mil registros em uma tabela teste levou:
- 22 segundos: com um índice Clustered nas colunas Data e Cliente + índice Único na coluna Código;
- 27 segundos com uma Chave Primária na coluna Código.
Após a inclusão, foi realizado uma consulta básica com as colunas Data e Cliente na cláusula WHERE, e o Plano de Execução analisado:
- utilizando a estratégia sugerida, de índice Clustered nas colunas Data e Cliente, atingiu-se o objetivo esperado, ou seja, o Plano de Execução retornou a busca como Clustered Index Seek;
- utilizando o método antigo, de Chave Primária na coluna Código, o método da busca utilizado foi Clustered Index Scan, ou seja, o SQL precisou fazer um Scan em todas as linhas para obter o resultado.
Espero desta forma, ter demonstrado o melhor aproveitamento do índice Clustered de uma tabela, em colunas que realmente serão utilizadas nas buscas.
Concorda, discorda, alguma sugestão ?
Entre em contato!
Abraços e até a próxima.
SQL Server Radio
Hello SQL community !
There is a new way to be updated with the latest news from SQL Server.
Guy Glantser (@guy_glantser) and Matan Yungman (@MatanYungman) from Madeira SQL Server Services (www.madeirasql.com), a company from Israel had just created a online radio/podcast covering several topics of the product.
The radio site is: www.sqlserverradio.com
I was aware of the radio just today, and I am still catching up the 11 episodes created so far.
The conversation style is very casual and if you listen carefully you'll get a lot of great tips.
Until next time !
There is a new way to be updated with the latest news from SQL Server.
Guy Glantser (@guy_glantser) and Matan Yungman (@MatanYungman) from Madeira SQL Server Services (www.madeirasql.com), a company from Israel had just created a online radio/podcast covering several topics of the product.
The radio site is: www.sqlserverradio.com
I was aware of the radio just today, and I am still catching up the 11 episodes created so far.
The conversation style is very casual and if you listen carefully you'll get a lot of great tips.
Until next time !
quarta-feira, 16 de julho de 2014
CRUD + Bootstrap + SQL Server
A dica de hoje é uma série de 19 vídeos feitos pela Glaucia Lemos, programadora WEB do Rio de Janeiro, onde ela explica passo-a-passo, os conceitos de CRUD em C#, utilizando o Bootstrap + banco de dados SQL Server.
Segue link dos vídeos:
https://www.youtube.com/watch?v=s5_83He6HmI&list=PLb2HQ45KP0WuY6bCj-kCSa2LvvnaThRQ_
Ela também escreveu alguns artigos para o portal Code4Coders:
http://code4coders.wordpress.com/author/glaucia86/
Twitter: @glaucia_lemos86
Abraços!
Segue link dos vídeos:
https://www.youtube.com/watch?v=s5_83He6HmI&list=PLb2HQ45KP0WuY6bCj-kCSa2LvvnaThRQ_
Ela também escreveu alguns artigos para o portal Code4Coders:
http://code4coders.wordpress.com/author/glaucia86/
Twitter: @glaucia_lemos86
Abraços!
Assinar:
Postagens (Atom)