Com o anúncio de que grandes portais da internet como o Yahoo e o Google irão realizar testes com o novo protocolo IPv6 uma grande dúvida pairou no ar: O que é IPv6?

Como todos sabem a internet é uma rede que interliga milhares de computadores no mundo inteiro. E para que um computador se conecte nessa rede é necessário que ele tenha um endereço único que o identifique, e esse endereço é chamado de IP.

Atualmente utilizamos o IPv4 para identificar os computadores na internet. O problema é que, com o crescimento da rede e, consequentemente, o aumento do número de dispositivos conectados, o IPv4 não está dando conta do recado e em breve não haverão mais endereços disponíveis na rede.

Para evitar que isso ocorra foi desenvolvido o IPv6, que será implantado gradativamente na internet e deve funcionar paralelamente com o IPv4 até a substituição total.

Essa mudança não deve demorar muito para acontecer, pois a saturação do IPv4 é só uma questão de tempo. Está marcado para o dia 8 de junho um grande teste do protocolo IPv6, chamado de “World IPv6 Day”. Durante 24 horas, os maiores portais da internet converterão seus servidores para o novo protocolo a fim de avaliar possíveis problemas e corrigí-los antes da implementação definitiva.

Além de expandir a capacidade de endereçamento da internet, pois o IPv6 é um protocolo de 128 bits (a versão anterior trabalha em 32 bits), o IPv6 também trás inovações nas áreas de segurança, mobilidade e desempenho.

Um dos principais mecanismos de segurança do IPv6 é o IPSec, que oferece criptografia de pacote de dados para garantir a integridade, confidencialidade e autenticidade das informações.

A grande quantidade de endereços possíveis com o IPv6, por si só, já é um item de segurança, pois isso torna inviável a varredura de IP em redes para encontrar computadores vulneráveis.

O endereçamento com o IPv6 é de 128 bits e inclui prefixo de rede e sufixo de host que podem ser inseridos em qualquer posição do endereço.

Um endereço padrão IPv6 deve ser formado por um campo provider ID, um subscribe ID, um subnet ID e um node ID. O node ID (identificador de interface) pode ser formado a partir do endereço físico no formato EUI64.

Os endereços IPv6 são escritos como 8 grupos de 4 dígitos hexadecimais.
Por exemplo: 2011:0DC8:8573:A8C2:1113:8A2A:3070:7311

Há ainda no IPv6, tipos especiais de endereços:

O IPv6 veio para revolucionar a internet, eliminando as limitações do padrão IPv4 e construindo um mundo ainda mais conectado.

Deixem suas opiniões ou complementos ao post no espaço para comentários abaixo!

Fonte: 72DPI

Fala pessoal,

Algum tempo atrás, compartilhei uma experiência que tive no Blog do Fabrício Catae (Blog | Twitter), mas também resolvi deixar registrado por aqui.

Muitos de vocês já utilizaram a dmv sys.dm_db_index_usage_stats presente a partir do SQL Server 2005 para verificar a utilização e atualização dos índices de uma tabela. Também sabemos que essa dmv tem seus dados reiniciados quando o serviço do SQL Server é reiniciado. Assim, como os servidores do meu ambiente de banco de dados possuem uma atualização mensal de segurança, os servidores são reiniciados mensalmente e os dados dessa dmv seriam sempre perdidos. Ou seja, eu só teria essas valiosas informações sobre os índices durante o período de um mês.

Para resolver esse problema, criei uma tabela que armazena diariamente a utilização dos índices. Com isso, posso analisar durante um período muito grande a utilização dos meus índices antes de excluí-los. Eu já possuo mais de 1 ano de baseline, já que o espaço ocupado por essas informações é pequeno.

Para quem quiser possuir um histórico dessas informações, o script abaixo cria uma tabela de histórico e insere as informações de utilização dos índices nessa tabela.

——–

CREATE TABLE [dbo].[Historico_Utilizacao_Indices](
[Id_Historico_Utilizacao_Indices] [int] IDENTITY(1,1) NOT NULL,
[Dt_Historico] [datetime] NULL,
[Nm_Servidor] [varchar](30) NULL,
[Nm_Database] [varchar](30) NULL,
[Nm_Tabela] [varchar](50) NULL,
[Nm_Indice] [varchar](50) NULL,
[User_Seeks] [int] NULL,
[User_Scans] [int] NULL,
[User_Lookups] [int] NULL,
[User_Updates] [int] NULL,
[Ultimo_Acesso] [datetime] NULL )

INSERT INTO Historico_Utilizacao_Indices(Dt_Historico, Nm_Servidor, Nm_Database, Nm_Tabela, Nm_Indice,  User_Seeks, User_Scans,User_Lookups, User_Updates, Ultimo_acesso)
SELECT getdate(), @@SERVERNAME, db_name(db_Id()), o.Name, i.name, s.user_seeks,s.user_scans,s.user_lookups, s.user_Updates,  isnull(s.last_user_seek,isnull(s.last_user_scan,s.last_User_Lookup)) Ultimo_acesso
FROM sys.dm_db_index_usage_stats s
join sys.indexes i on i.object_id = s.object_id and i.index_id = s.index_id
join sys.sysobjects o on i.object_id = o.id
WHERE s.database_id = db_id()
ORDER BY o.Name, i.name, s.index_id

——–

Para armazenar as informações, criei um job que roda essa query de INSERT para cada database que eu defini guardar os históricos.

Assim, eu utilizo essa tabela de histórico para analisar uma possível exclusão dos índices que são pouco utilizados ou que não são utilizados. Agora, compartilhando a experiência que tive, eu possuo uma tabela com muitas consultas e alterações que armazena 50 milhões de registros. Nessa tabela, tenho um índice em um campo chamado Fl_Situacao que pode possuir os valores 0, 1, 2, 3 ou 4.

Sempre acompanhei esse índice e verifiquei que tinha algumas utilizações somente no inicio do mês. Um certo dia, resolvi excluir esse índice seguindo o raciocínio de que o índice era pouco seletivo, a tabela é muito grande e o índice era pouco utilizado, não valendo a pena o custo de manutenção do mesmo. Após excluir o índice, acompanhando meu trace com as querys que demoram mais de 3 segundos, verifiquei que nenhuma query apresentou problema de lentidão.

Show de bola, diminuí uma operação de manutenção de um índice em uma tabela muito utilizada.

Entretanto, no inicio do mês, existia uma query com uma condição “where Fl_Situacao = 2? dentre outras restrições. Quando essa query rodou sem o índice que eu excluí, a mesma fez um clustered index scan nessa tabela, me causando um grande problema de lentidão no banco de dados. Isso aconteceu, pois, dos 50 milhões de registros existentes na tabela, apenas 1.000 registros possuíam o campo Fl_Situacao = 2, o que tornava o índice existente nessa coluna extremamente eficiente para essa query.

Resultado, como não dava para alterar a consulta, tive que recriar o índice na mesma noite.

Mais uma vez eu digo, vivendo e aprendendo!!! Meu maior aprendizado está no meu dia a dia de trabalho.

Abraços,

Fabrício França Lima
MCITP – Database Administrator
Twitter: @fabriciodba
http://fabriciodba.wordpress.com/