AWS – VPN Server

Categories: AWS, Uncategorized, Windows

Existem vários motivos para você querer rotear sua saída de internet por outro local ao invés do seu ISP de costume, privacidade? segurança? acesso a outros conteúdos de mídia?

O motivo em si é irrelevante, hoje contamos com diversos serviços de VPN pagos e gratuitos muito bons por aí, mas da pra confiar neles? uma VPN é basicamente um contrato de mão dupla, você confia em uma ponta enquanto a outra ponta confia em você, é estabelecido um canal de criptografia entre essas duas pontas e os dados podem ou não ser roteados através desse canal, em uma visão simplista uma análise de tráfego ou scan de rede pode partir de uma das pontas para “analisar” o que encontra-se do outro lado, por isso, mesmo uma VPN meia-boca costuma ter firewall restringindo quem e da onde pode vir o tráfego, mas em dispositivos de celular isso é quase impossível.

Claro que existem serviços honestos de VPN por aí, pagos ou gratuitos, mas por que ariscar se você pode montar um para você,,, e de graça,,,

Pra começar é simples, crie uma conta na AWS.

Depois vamos usar o serviço de Marketplace:

Procure por OpenVPN Access Server

Escolha a opção de Continue to Subscribe

Aceite os termos

Muitos termos

é só esperar para ele ativar o serviço na sua conta

Basicamente terminada a subscrição agora vamos iniciar uma máquina EC2 com o OpenVPN, escolha o local onde você vai hospedar a máquina EC2, basicamente qualquer lugar do mundo dentro da nuvem da AWS serve.

eu disse que era grátis? foi mesmo,,, você tem que alterar o tipo de máquina que vai ser usada para hospedar o OpenVPN para o modelo t2.micro

nessa parte onde você troca a máquina.

Aqui vem um detalhe, esse ambiente é grátis por 1 ano, se você já usou esse serviço de EC2 da AWS alguma vez e não aparecer a que vai ser grátis então chegou até aqui a toa, eles vão te cobrar, mas cabaçada sua de não prestar atenção nos termos de uso dos serviços deles…

VPC e Subnet a sua escolha, o que importa são as regras de firewall e o IP valido que vai ser criado para a máquina.

Como você está criado a máquina através de um template, ele já vem com um conjunto de regras pré definidas.

Essa parte é importante, salve a chave para que você tenha acesso a essa máquina através de SSH.

Basicamente após clicar em “Launch” a AWS vai criar a máquina, na região, com regras de firewall e o OpenVPN para você.

Mas não acabou por aqui, afinal, você vai querer acessar essa VPN.

Para acessar essa VPN antes você vai precisar configurar ela, nada tão complicado,,, apenas preste atenção nos detalhes, eles são a grande diferença

Após a máquina iniciar, você terá um endereço de IP válido e uma entrada de DNS. Se você não esqueceu de liberar o seu IP lá na regra de firewall você deve conseguir acessar esse servidor.

Antes de sair tentando acessar pelo Browser e configurar as coisas, você precisa logar no servidor e aceitar aqueles contratos, que como TODOS fazemos lemos até o fim um a um,,,, um a um,,,

Para acessar o servidor não precisa de nenhuma ferramenta especial (caso você esteja usando pelo menos o Windows 10), nos Linux e Mac’s da vida o ssh vem por padrão, no Windows 10 pra cima também, se você está usando alguma coisa mais antiga, procura algum cliente de SSH.

Para acessar esse novo servidor você vai abrir o prompt/terminal/posh o raio que quiser e basicamente digitar:

ssh -i "aquele_arquivo_de_chave" ec2user@IP_ou_FQDN
se não der certo tenta como root mesmo
ssh -i "aquele_arquivo_de_chave" root@IP_ou_FQDN

Se tudo deu certo, deve aparecer a licença, leia com cuidado, tudinho, tintim por tintim,,, e se achar que está tudo bem aceita a licença.

Na primeira vez que você faz login no Servidor de Acesso, um assistente de configuração é executado para permitir que você configure os parâmetros de inicialização antes de poder acessar a interface web administrativa. Neste assistente, você especifica alguns detalhes da rede e define um usuário administrador.

Se você optar por usar o usuário openvpn padrão como usuário administrador, certifique-se de definir uma senha para ele antes de acessar a interface web de administração. Para definir uma senha, use o seguinte comando shell:

sudo senha openvpn

Para acessar a interface web, abra o endereço IP público que você atribuiu e faça login como o usuário administrador que você configurou. A URL da interface da web tem o seguinte formato: https://xxx.xxx.xxx.xxx/admin.

O login abre a página Visão geral do status, conforme mostrado na imagem a seguir. É aqui que você obtém a visão geral do status do dispositivo VPN. Você também pode usar este portal para ajustar a VPN, alterar as configurações de rede e gerenciar permissões e autenticação do usuário.

Por padrão, a VPN é configurada para funcionar no modo NAT (tradução de endereço de rede) da Camada 3. Nesse modo, os clientes VPN são atribuídos a uma sub-rede privada cujos IPs são atribuídos dinamicamente a partir do pool padrão 172.27.224.0/20 (CIDR), conforme mostrado na imagem a seguir.

Você pode alterar esse pool de IPs, mas esteja ciente de que o novo deve ser diferente das outras sub-redes utilizadas na sua rede. Você também pode configurar outra sub-rede privada usada para atribuir endereços IP estáticos a usuários específicos designados na página Permissões do usuário.

Para roteamento de rede, a opção padrão é Sim, usando NAT, conforme mostrado na imagem a seguir.

Para testar a VPN

Normalmente você precisa baixar um cliente VPN para os testes, a principal vantagem do OpenVPN é ele ter clientes para todos os SO’s e Mobiles do mercado.

baixe o cliente correto, ajuste a configuração de IP que você está usando como IP público e terá uma VPN saindo pelo lugar do mundo onde você fez deploy da maquina.

Babelfish

Categories: AWS, SQL, SQLServerPedia syndication, Uncategorized, Virtual PASS BR
AWS Bablefish

Conhecem aquela história da fadinha do dente? ou aquela outra que você ouviu que um amigo de uma amigo de um conhecido do irmão da tia do sobrinho já usou e é legal?

Então, prazer esse é o Babelfish, ele é feinho, tem uns problemas, parece um político (vende mais do que entrega), mas tá aqui pra te ajudar.

Mas pra que ele server?

Imagina o seguinte, por algum acaso do destino o pessoal descobriu que o licenciamento do SQL Server é caro, não da mais para ficar usando o SQL Enterprise para manter as bases da empresa, o Standard não é uma opção (porque afinal é o Std e ninguém gosta,,, brincadeira) por qualquer que seja o motivo, as vezes até birra de gerente novo que tem birra do SQL Server (não sabe usar e quer dar pitaco de DBA), corte de custos, escolhe o motivo, tanto faz, é só uma desculpa para o: ¨por que não?¨

Como DBA temos que ter a mente aberta para outras dores de cabeça, afinal nossa vida é tranquila d+ para não sofrer multi-plataforma ou multi-banco.

TEORICAMENTE esse cara deve ajudar você a conseguir ter uma transição mais suave entre o SQL Server e o Postgresql, como um intermediário para interpretar o T-SQL para o PLPGSQL em tempo de execução.

Para entender detalhadamente como o Babelfish da AWS funciona, é importante mergulhar nas camadas técnicas e de comunicação que facilitam a compatibilidade entre SQL Server e PostgreSQL. O Babelfish atua como uma ponte entre esses dois mundos, interpretando chamadas SQL Server para o formato PostgreSQL e vice-versa, permitindo que aplicativos escritos para SQL Server interajam com o Aurora PostgreSQL como se estivessem se comunicando com um banco de dados SQL Server nativo. Vamos detalhar essas camadas e o processo de comunicação.

Entendendo as Camadas do Babelfish

O Babelfish implementa duas principais camadas de funcionalidade:

  1. Camada de Protocolo de Comunicação:
    • O SQL Server utiliza o protocolo TDS (Tabular Data Stream) para a comunicação entre cliente e servidor. O Babelfish é capaz de entender e interpretar o protocolo TDS, permitindo que clientes SQL Server se conectem ao Aurora PostgreSQL como se fosse um servidor SQL Server. Essa camada de comunicação traduz as requisições TDS em chamadas SQL compreensíveis pelo PostgreSQL.
  2. Camada de Tradução de SQL:
    • Após a comunicação ser estabelecida através do TDS, as instruções SQL, procedimentos armazenados, funções, e tipos de dados específicos do SQL Server são traduzidos para seus equivalentes no PostgreSQL. Esta camada lida com a conversão de sintaxes de consulta, tipos de dados, e semânticas de execução, assegurando que as operações executadas pelos aplicativos funcionem corretamente no Aurora PostgreSQL.

Como o Babelfish Funciona na Prática

O processo de interação entre um aplicativo SQL Server e o Aurora PostgreSQL através do Babelfish envolve várias etapas:

  1. Estabelecimento de Conexão:
    • O cliente SQL Server inicia uma conexão usando o protocolo TDS, direcionada ao endpoint do Babelfish na instância Aurora PostgreSQL.
    • O Babelfish aceita a conexão TDS, estabelecendo um canal de comunicação entre o cliente e o Aurora PostgreSQL.
  2. Execução de Consultas:
    • Quando uma consulta SQL Server é enviada pelo cliente, a camada de protocolo de comunicação do Babelfish recebe a requisição em formato TDS.
    • A camada de tradução de SQL então converte a consulta do formato SQL Server para uma consulta compatível com PostgreSQL, incluindo a tradução de tipos de dados e a sintaxe de procedimentos armazenados, se necessário.
  3. Processamento de Consultas:
    • A consulta traduzida é processada pelo Aurora PostgreSQL, e os resultados são gerados.
    • Os resultados são então encapsulados em um formato compreensível pelo protocolo TDS e enviados de volta ao cliente SQL Server através do Babelfish.
  4. Retorno dos Resultados:
    • O cliente SQL Server recebe os resultados como se estivesse interagindo com um banco de dados SQL Server nativo, completando a operação.

Considerações de Implementação

  • Compatibilidade: Enquanto o Babelfish oferece uma alta grau de compatibilidade, existem limitações e diferenças que devem ser consideradas. Nem todas as funcionalidades e comportamentos do SQL Server são suportados 1:1 no PostgreSQL através do Babelfish.
  • Otimização de Desempenho: A tradução entre os dialetos SQL pode introduzir overheads de desempenho. É importante monitorar o desempenho das aplicações e ajustar as consultas ou a configuração do Babelfish conforme necessário.
  • Gerenciamento de Transações: O Babelfish suporta transações, mas as diferenças na gestão de transações entre o SQL Server e o PostgreSQL podem requerer atenção especial para garantir a integridade dos dados.

Instalando e Configurando o Babelfish Localmente

Pré-Requisitos

Antes de iniciarmos, certifique-se de que você tem os seguintes pré-requisitos em seu sistema:

  • Sistema operacional compatível (Linux/Windows)
  • PostgreSQL instalado e funcionando
  • Acesso administrativo ao sistema
  • Conhecimento básico em linha de comando e administração de banco de dados

Passo 1: Baixar o Binário do Babelfish

Inicialmente, você precisa obter o binário do Babelfish para sua plataforma. A AWS disponibiliza esses binários através do seu site oficial ou repositório GitHub. Acesse o GitHub do Babelfish para encontrar a versão mais recente compatível com seu sistema.

Passo 2: Instalação do Babelfish

Após o download, siga os passos específicos para sua plataforma para descompactar e instalar o binário. Em sistemas baseados em Linux, geralmente envolve extrair o conteúdo do arquivo e executar um script de instalação. Por exemplo:

tar -zxvf babelfish-version-linux.tar.gz cd babelfish-version ./install.sh

Passo 3: Configurando o PostgreSQL para o Babelfish

Com o Babelfish instalado, o próximo passo é configurar seu PostgreSQL para trabalhar com o Babelfish. Isso geralmente envolve editar o arquivo de configuração postgresql.conf do PostgreSQL para incluir parâmetros específicos do Babelfish, como:

# Exemplo de parâmetros a serem adicionados ao postgresql.conf listen_addresses = '*' 
babelfishpg_tsql.database_name = 'NomeDoBancoSQLServer'

Não se esqueça de reiniciar o serviço do PostgreSQL após realizar essas alterações.

Passo 4: Criando um Banco de Dados Compatível com SQL Server

Você precisará criar um banco de dados no PostgreSQL que será utilizado pelo Babelfish para emular o comportamento do SQL Server. Isso pode ser feito utilizando o psql, o terminal interativo do PostgreSQL, com comandos como:

CREATE DATABASE NomeDoBancoSQLServer;

Passo 5: Testando a Conexão

Após a configuração, é crucial testar a conexão para assegurar que tudo está funcionando como esperado. Utilize suas ferramentas SQL Server habituais para conectar-se ao banco de dados PostgreSQL configurado, usando o endereço de IP e porta onde o PostgreSQL está rodando.

Se tudo der certo, você estará dentro do SSMS rodando query T-SQL contra um banco no Postgres.

Instalando e Configurando o Babelfish na AWS

A instalação do Babelfish é realizada através da criação de uma instância do Amazon Aurora PostgreSQL que inclui a camada de compatibilidade do Babelfish. Veja os passos:

  1. Crie uma instância do Amazon Aurora PostgreSQL:
    • Acesse o console da AWS e selecione o serviço Amazon RDS.
    • Clique em “Criar banco de dados” e selecione “Amazon Aurora”.
    • Escolha a edição compatível com PostgreSQL e a versão que inclui Babelfish.
    • Configure as especificações da instância conforme necessário e proceda com a criação.
  2. Habilitar Babelfish na Instância:
    • Após a criação da instância, navegue até a seção de parâmetros e habilite o Babelfish adicionando a configuração apropriada. Isso pode exigir a criação de um novo grupo de parâmetros se você desejar customizações específicas.

Configuração do Babelfish

Após a instalação, é necessário configurar o Babelfish para aceitar conexões do SQL Server:

  1. Configurar o Endpoint do SQL Server:
    • Localize o endpoint do Babelfish na seção de conectividade da instância Aurora PostgreSQL.
    • Este endpoint é usado para conectar aplicativos SQL Server ao Babelfish.
  2. Ajuste de Parâmetros:
    • Acesse o grupo de parâmetros da instância e ajuste as configurações para otimizar a performance e compatibilidade com seus aplicativos SQL Server.

Pontos de Atenção

Ele pode parecer a solução infalível para todos os seus problemas, mas como não existe almoço de graça ele tem limitações:

  1. Versão do Postgres oficialmente suportado, na instalação local a versão até o mento é a 14.6
  2. Limitações das “traduções”, ainda que ele faça alguns milagres naquele seu código grotesco, ele tem certas limitações, da uma lida no site do Bablefish para ver o que ele consegue fazer.
  3. Consumidor de recursos, já é de se esperar que como ele vai fazer uma tradução simultânea de comandos diretamente no canal, quanto maior o poder computacional mais rápido ele vai traduzir os comandos, então vejo esse como um dos principais gargalos de adoção na tecnologia, já que hardware é dinheiro e isso pode ficar caro.

AWS – EC2 com SQL

Categories: AWS, SQL, SQLPASS, SQLServerPedia syndication, Uncategorized, Virtual PASS BR

Caso você contrate uma AMI com SQL e precise da mídia de instalação do SQL para qualquer atividade, na unidade C:\ existe um diretório chamado “SQLServerSetup” com os binários para a instalação do SQL Server.

Isso ajuda caso precise trocar o Collation da instância, adicionar feature, reinstalar usando uma instância, adicionar uma instância, etc..

A instalação padrão vem na instância default, collation SQL_Latin1_General_CP1_CI_AS, tempdb nas configurações NNF, sem IFI, basicamente uma instalação NNF.

Aí vem outra pergunta, por que pegar uma imagem da AWS com SQL? por que não usar um RDS?

Bom, a resposta disso é mais com você do que comigo, porque tudo vai depender da necessidade.

AMI – EC2 com SQL Instalado

  • As imagens da AWS com SQL instalado vem em diversos sabores, você escolhe o tamanho da máquina e o tipo de licenciamento STD ou ENT, eles tem developer mas se optar por esse developer você vai pagar um custo pela licença de uma aplicação que pode ser baixada gratuitamente, e ai o preço desse licenciamento do STD ou ENT vai depender do tamanho da máquina que você escolher, a vantagem fica justamente na questão de licenciamento, quem recolhe e paga para a Microsoft é a AWS, você é apenas uma empresa que está usando uma imagem já pré-instalada, então sem stress quando a licenciamento;
  • Toda a administração do ambiente e com você, eles só deixam o SQL instalado e o resto é o trabalho de casa, desde restaurar o banco até todas as rotinas de manutenção.

RDS

  • Basicamente o SQL como serviço
  • você não loga na máquina, não tem nenhum acesso a estrutura onde o SQL está instalado
  • você não é SA nem faz parte da role de Sysadmin
  • você é owner dos seus bancos
  • todas as rotinas de manutenção do SO e algumas do SQL são geridas pela AWS.
  • é uma administração meio a meio

Vou tratar da comparação entre uma AMI e um RDS em outro post.

VMWare Workstation no Win10 com CG DG Error

Categories: Powershell, TI, Uncategorized, Vmware, Windows

Tenho no meu note o Windows 10 (Version 200514-1410 Build 19631.1) e uso como virtualizador o VMWare Workstation 15 (15.5.2 build-15785246)

Esse Windows 10 faz parte do programa insider, então toda a semana tem uma atualização.

Por que não usar o Hyper-V ? A resposta é simples: Não quero e pronto. A maquina é minha e gosto mais do vmware.

Alinhados quanto a isso, depois que o Windows atualizou para o Build 19000+ o VMWare resolveu parar de funcionar e não iniciava nenhuma máquina. Ele começou a apresentar a mensagem abaixo para qualquer máquina virtual:

Ele indica um link para mais detalhes que acaba direcionando para um outro link: https://kb.vmware.com/s/article/2146361

Basicamente, se seguir o que o site diz não faz diferença nenhuma e não resolve nada, você vai ser direcionado para o site da Microsoft (https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard-manage) e de lá se fizer todos os procedimentos também vai terminar não resolvendo.

O processo para resolver o problema é bem mais simples que os procedimentos que eles passam.

Abra o Powershell em modo administrativo e execute o seguinte comando:

bcdedit /set hypervisorlaunchtype off

Após isso ele informa que:

The operation completed successfully.

E aí é só reiniciar o PC e tudo volta ao normal.

Qual query está acessando qual arquivo do File Group?

Categories: Scripts, SQL, SQLServerPedia syndication, Uncategorized, Virtual PASS BR

As vezes temos operações de disco que chegam a gerar mensagens como a seguinte:

SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [X:\Banco\Disk99\DataFiles\Arquivo_do_banco_X_FG_Y_Arquivo_75.ndf] in database [Banco_X] (254). The OS file handle is 0x0000000000009A18. The offset of the latest long I/O is: 0x00000030038000

Muitas vezes isso indica que o sistema de discos não está operando de forma satisfatória e está impactando alguma operação.

A query abaixo tenta ajudar a identificar qual operação DDL ou DML que estava acessando o arquivo naquele momento:

SELECT DB_NAME(mf.database_id) AS [Database]
,mf.physical_name
,r.io_pending
,r.io_pending_ms_ticks
,r.io_type
,fs.num_of_reads
,fs.num_of_writes
,ER.session_id
,ST.TEXT
FROM sys.dm_io_pending_io_requests AS r
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.file_id = mf.file_id
INNER JOIN sys.dm_os_schedulers os ON r.scheduler_address = os.scheduler_address
INNER JOIN sys.dm_exec_requests AS ER ON os.scheduler_id = ER.Scheduler_id
CROSS APPLY sys.dm_exec_sql_text(ER.sql_handle) AS ST
ORDER BY r.io_pending_ms_ticks DESC;
go

PowerShell e o Metrô

Categories: Powershell, Uncategorized

Trabalhando no centro você acaba tendo que usar muito o transporte público, o que na maioria dos casos é muito chato,,,

Devido a chuva a operação da CPTM e do Metrô estavam com algumas lentidões, mas nada comparado ao sites deles,,,

O site do Metrô (www.metro.sp.gov.br) estava muito lento, um tempo de resposta de uns 10/15 segundos.

O da CPTM (www.cptm.sp.gov.br) não estava muito longe disso também,,,

Aí fiquei pensando se algum deles tinha uma API para trazer a informação do status da linha e descobri que, claro, nenhum deles tem isso…

Mas, a Viaquatro, que opera a linha 4 do metrô tem uma API, que apenas trás as informações do metrô e por curiosidade não trás informações sobre a própria linha 4,,, mas já está valendo….

O site com as informações das linhas de metrô é o: http://www.viaquatro.com.br/generic/Main/LineStatus

Legal, não precisa de chave de API, não tem necessidade de autenticação, é bem simples e direto…

metro

 

Agora com isso já é possível trabalhar um pouco com o poweshell…


$metro = Invoke-RestMethod -Uri "http://www.viaquatro.com.br/generic/Main/LineStatus" | select * -ExpandProperty StatusMetro
$linha = $metro.ListLineStatus

$linha | select Line,StatusMetro

E agora tenho uma pesquisa direta do status das linhas na hora que eu quiser e sem ter que abrir o site do metrô,,,

Quando eu descobrir se a CPTM tem o mesmo tipo de serviço tento incorporar no código,,,

 

Os números de 2014

Categories: Uncategorized

Os duendes de estatísticas do WordPress.com prepararam um relatório para o ano de 2014 deste blog.

Aqui está um resumo:

A sala de concertos em Sydney, Opera House tem lugar para 2.700 pessoas. Este blog foi visto por cerca de 11.000 vezes em Se fosse um show na Opera House, levaria cerca de 4 shows lotados para que muitas pessoas pudessem vê-lo.

Clique aqui para ver o relatório completo

Testar Porta

Categories: Uncategorized

Vocês sabem que se quiser testar uma porta TCP um dos métodos mais simples é basicamente um telnet Nome/IP porta.
Se o prompt sumir e o cursor ficar piscando a porta está respondendo (claro,, tirando todas as implicações de liberação de firewall e blá blá blá)
Eu precisava ficar fazendo um teste mais dinâmico, já que o telnet estabelece a conexão e espera uma intervenção para continuar eu queria apenas saber se a porta esta aberta ou não, estávamos tentando identificar uma falha se era no serviço ou na rede.open door
o script abaixo fica estabelecendo uma comunicação em um intervalo definido usando o socket TCP/IP estão podemos testar TCP e UDP bem no nível da camada e não da aplicação.
ele é bem simples, em qualquer momento que a porta não responda ele coloca a cor de fundo como vermelho.

function TestPort
{
    Param(
        [parameter(ParameterSetName='ComputerName', Position=0)]
        [string]
        $ComputerName,

        [parameter(ParameterSetName='IP', Position=0)]
        [System.Net.IPAddress]
        $IPAddress,

        [parameter(Mandatory=$true , Position=1)]
        [int]
        $Port,

        [parameter(Mandatory=$true, Position=2)]
        [ValidateSet("TCP", "UDP")]
        [string]
        $Protocol
        )

    $RemoteServer = If ([string]::IsNullOrEmpty($ComputerName)) {$IPAddress} Else {$ComputerName};

    If ($Protocol -eq 'TCP')
    {
        $test = New-Object System.Net.Sockets.TcpClient;
        Try
        {
            Write-Host "Connecting to "$RemoteServer":"$Port" (TCP)..";
            $test.Connect($RemoteServer, $Port);
            Write-Host "Connection successful" -BackgroundColor Green;
        }
        Catch
        {
            Write-Host "Connection failed" -BackgroundColor Red;
        }
        Final
        {
            $test.Dispose();
        }
    }

    If ($Protocol -eq 'UDP')
    {
        $test = New-Object System.Net.Sockets.UdpClient;
        Try
        {
            Write-Host "Connecting to "$RemoteServer":"$Port" (UDP)..";
            $test.Connect($RemoteServer, $Port);
            Write-Host "Connection successful" -BackgroundColor Green;
        }
        Catch
        {
            Write-Host "Connection failed" -BackgroundColor Red;
        }
        Final
        {
            $test.Dispose();
        }
    }
}

A forma de testar ele é bem simples:

TestPort -ComputerName Nome/IP -Port 1433 -Protocol TCP 

Legal né? só que eu precisava ficar fazendo testes direto e reto e da forma acima ele não é um looping…
logo, para fazer da forma mais simples que conheço ficou assim:

$servidor = "Nome/IP"
while (1) {
    get-date #só pra saber quando executou
    TestPort -ComputerName $servidor -Port 1433 -Protocol TCP 
    sleep -seconds 1 #tempo de espera entre as execuções
} 

Os números de 2012

Categories: Uncategorized

Os duendes de estatísticas do WordPress.com prepararam um relatório para o ano de 2012 deste blog.

Aqui está um resumo:

600 pessoas chegaram ao topo do Monte Everest em 2012. Este blog tem cerca de 10.000 visualizações em 2012. Se cada pessoa que chegou ao topo do Monte Everest visitasse este blog, levaria 17 anos para ter este tanto de visitação.

Clique aqui para ver o relatório completo

TOP 5 – Ferramentas grátis

Categories: SQL, Uncategorized, Virtual PASS BR

ATUALIZAÇÃO !!! – 20/09/2012

Esse post é para falar de ferramentas gratuitas,,, é com muito pesar que estou retirando o SSMS Tools Pack do primeiro lugar, a partir da versão 2.5.0.0 ele deixou de ser de graça, logo, vai contra o intuito do post…

Estou substituindo pela ferramenta SSMSBoost

Tem gente que gosta de fazer as coisas na marra,,, sem ajuda de nada,,, script de baixo de script,,, Isso é muito legal, tem muita coisa que só se resolve assim,,,

O importante é conhecer o que o mercado oferece quando você quer “uma ajuda” ou pra realmente facilitar o dia a dia,,,

O meu TOP 5 de ferramentas gratuitas são:

  1. Pra quem gosta de trabalhar com o SSMS, um add-on bem legal é o SSMS Tools Pack desenvolvido por Mladen Prajdić. Ele adiciona algumas funções bem legais como: histórico, snippets, gerador de código… Acho uma ferramenta pequena e legal… Uma ferramenta muito interessante para adicionar funcionalidades ao SSMS é o SSMSBoost ele adicionar recursos muito bons como snippets, localizador de objetos, alterador de barra de titulo e uma coisa bem legal que é o cadastro de conexão onde você pode colocar alerta de ambiente de produção,,, ai ele avisa, dependendo do comando que você precisa prestar atenção antes de dar um truncate table por exemplo…. Ele é de graça, mas naquelas, você precisa reinstalar ele a cada 45 dias (não é trial, é só uma coisa chata que o desenvolvedor colocou),,,
  2. Quem nunca passou raiva com o gerador de plano de execução do SSMS que drop um banco?,,, Se você usar o SQL Sentry Plan Explorer pelo menos uma vez, não vai querer deixar de usar,,, ele mostra de uma forma fácil de entender qual parte do plano estásendo mais custoso para a operação… fora outras coisas legais…
  3. Não pode faltar de jeito nenhum o Who is Active desenvolvido por Adam Machanic e por falar nele, existe um add-on da Schema Solutionsque adiciona uma interface gráfica para a execução de procedure.
  4. Na primeira vez que vi essa ferramenta não achei que seria tão útil, mas o SQL Trace Analyzeré bem interessante. Ele analisa o Profiler capturado em arquivo ou banco e gera um relatório consolidado mostrando o impacto, tempo, processamento, IO, etc.. E de brinde ele instala um monitorador de Locks/Blocks. O problema dessa ferramenta é a parafernália que ele instala, mas você pode remover o resto das coisas e ficar só com o programa principal.
  5. E não podia faltar alguma forma de monitorar o que acontece com o banco,,, para isso achei o IgniteFree, uma ferramenta muito simples de configurar e com muita informação relevante. Claro que a versão Trial/Full tem mais opções, mas mesmo na versão free é uma ótima ferramenta. Ela é leve, não ocupa muito espaço, não gera pressão na máquina que está sendo monitorada e de quebra ainda consegue monitorar uns Oracles que você tenha perdido no ambiente…