Monthly Archives: March 2021

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

AWS – EC2 com SQL

Leave a comment

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.

Powershell, TI, Windows

Ocupação de disco fantasma

Leave a comment

Quem nunca foi acionado ou recebeu um alerta de falta de espaço em disco e não fazia ideia de onde estava a ocupação do disco?

Existem várias formas de ocupar espaço no disco e dar dor de cabeça para o administrador Windows, nesse post vou comentar da que, no meu ponto de vista, é a mais chata o diretório do “System Volume Information”.

Quem é esse tal de “System Volume Information”?

  • Esse diretório contém informações sobre a indexação do disco
  • Informação de Quota NTFS
  • Dados do sistema de ponto de restauração e backup usando Windows Server Backup
  • Dados para backup usando algumas ferramentas de backup
  • Se você usa “Shadow copy” cada nova versão de VSS snapshot salva dados nesse diretório
  • etc.

Você não deveria se preocupar com os dados desse diretório, onde a ferramenta que está gerando os dados e versionamentos de arquivos nesse diretório deveriam limpar os dados e tocar a vida, mas como trabalhamos com TI e não necessariamente as ferramentas fazem o que deveriam fazer, vamos fazer o trabalho de identificar e limpar essa estrutura.

De uma forma visual, para saber se você está com problemas com esse diretório, recomento usar uma ferramenta como o “TreeFile Size”, “WizTree”, “DiskUsage”, etc.

Pelo “Windows Explorer” originalmente esse diretório não é exibido, você precisa alterar as configurações de exibição para mostrar arquivo e diretórios ocultos do sistema.

Quando tentar acessar vai receber erro de acesso negado mesmo você sendo o administrador do sistema.

Agora que você já sabe quem é esse diretório, já sabe que ele existe, já viu onde ele está, para calcular o espaço ocupado por ele você vai abrir o prompt de comando em modo administrador e vai digitar:

vssadmin list shadowstorage

Se tiver alguma coisa configurada com o ” System Volume Information” ele deve apresentar um resultado parecido com:

Legal, agora temos informações de quanto o espaço máximo pode ser alocado para os recursos e o quanto está realmente alocado.

Se o valor estiver com configuração “UNBOUNDED” quer dizer que o céu é o limite, ou o espaço total do disco, o que acabar primeiro…

Para exemplificar, vamos colocar o limite para a letra C: em 2GB

vssadmin resize shadowstorage /on=c: /for=c: /maxsize=2GB

Ele vai escrever que redimensionou o espaço para o serviço de shadow copy.

Você pode trocar o /maxsize=XGB para porcentagem também, ai fica /maxsize=10%

Se você cria backups de “system state” o windows também cria essa estrutura na letra C:, para apagar eles você pode rodar:

wbadmin delete systemstatebackup -keepversions:0

Isso deve ser o suficiente para limpar esses diretórios das suas unidades, agora entender por que eles estão sendo alimentados para evitar que isso ocorra novamente? corre atrás do pessoal de backup…

AWS, Redshift, Scripts, SQL, SQLServerPedia syndication, TI

AWS – Redshift – Tráfego de dados

Leave a comment

Imagine o seguinte cenário:

  • Você usa o Redshift como DW ou DL para seus relatório e cargas de dados;
  • Vê uma possibilidade de facilitar sua vida e dar liberdade para o próprio cliente acessar esses dados e gerar relatórios da forma que ele achar mais legal com a ferramenta que ele quiser, etc.;
  • Mas lembra que a AWS cobra pela saída de dados;
  • Procura no portal da AWS e descobre que eles não tem uma monitoração específica de quem está saindo com dados, mas eles acertam a cobrança… incrível…
  • Mas você não quer abandonar a ideia e quer ganhar alguma grana com isso..

O que vou mostrar não é a solução perfeita, ela carece de algumas melhorias mas já é um norte para ajudar nessa ideia…

O Redshift é um PostgreSQL modificado, então muita query em tabelas de sistema do PG funciona direitinho no Redshift…

Para esse cenário, você pode criar um pacote de integration services e rodar a query abaixo contra o Redshift:

select
	TRIM(q.DATABASE) AS DB,
	TRIM(u.usename) as usename,
	sum(bytes)/1024 as kbytes,
	sum(packets) as packets,
	date(b.starttime) as data
from
	stl_bcast b
join stl_query q ON
	b.query = q.query
	AND b.userid = q.userid
join pg_user u
on u.usesysid = q.userid
where
	packets>0
	and b.starttime >= dateadd(day, -7, current_Date)
	and datediff(seconds, b.starttime, b.endtime)>0
	--and u.usename like 'usr%'
	--and querytxt not like 'fetch%'
group by TRIM(q.DATABASE)
,u.usename
,date(b.starttime)

Essa query vai trazer a informação do volume em kb trafegado pela query executada.

Com isso, você consegue montar um report incremental e ratear o custo da saída de dados da AWS.

É 100%?, não,,, mas pelo menos já é alguma coisa já que a AWS não provê dados granularizados de quem consome a saída de dados.

novos códigos serão criados também em outro repositório:

https://github.com/bigleka

AWS, Redshift, Scripts, SQLServerPedia syndication, Virtual PASS BR

AWS – Redshift – Usuário para leituras

Leave a comment

O Redshift tem umas vantagens bem interessantes, baixo custo, RDS, baixa necessidade de manutenção.

No fundo ele é um PostgreSQL modificado para prover volume de dados e não ficar trabalhando como OLTP, ele é ótimo como estrutura para DW.

Imagine o seguinte cenário, você vende uma solução mas precisa prover um acesso do seu cliente para que ele consiga acessar uma parte dos dados diretamente na sua estrutura de banco, para ele “ter a liberdade” de cruzar esses dados, montar estruturas de relatórios, etc. da forma que ele achar mais interessante, ou até mesmo exportar esses dados para uma estrutura dele e usar da forma que achar melhor.

Certo, temos várias formas de fazer isso, todas tem seus prós e contras, mas nesse caso vou usar como exemplo justamente o título do post, vamos colocar os dados no Redshift.

Então, você tem alguma forma de extração de dados incrementais (SSIS, Pentaho, Informática, estagiário, etc.) que leva os dados do seu OLTP para o Redshift e isso funciona bem.

Agora você precisa criar a estrutura de permissões para liberar o acesso do seu cliente para essa estrutura de dados.

Uma coisa muito importante : Todos os usuários do Redshift são exclusivos do banco de dados e não da instância, Então caso o cliente tenha mais de um banco ou você queira dar permissão para mais de um banco, siga o processo quantas vezes for necessário.

— Normalmente quando os objetos são criados no Redshift ele ficam armazenados no schema public.
— Isso não é um problema, o problema começa quando é criado um schema para armazenar um outro conjunto de objetos
— para um setor da empresa, ou um outro departamento…
— Quando isso acontece, o usuário owner da carga dos objetos tem acesso a essa estrutura de dados sem problema, mas novos usuários,
— ou usuários permissonalizados não tem a permissão para os objetos ou para novos objetos nesse schema.
— O script abaixo tente a sanar um cenário em que você quer liberar o acesso de select para os objetos e novo objetos em um schema pulic
— ou personalizado sem ter que ficar dando grant toda a vez que novos objetos são criados.
— Outra opção de uso é caso você tenha um Redshift na sua empresa e venda como serviço ele como datalake para algum cliente.
— dessa forma você consegue liberar um usuário para que o cliente acesse a estrutura de dados e consiga baixar os dados.

-- Normalmente quando os objetos são criados no Redshift ele ficam armazenados no schema public.
-- Isso não é um problema, o problema começa quando é criado um schema para armazenar um outro conjunto de objetos
-- para um setor da empresa, ou um outro departamento...
-- Quando isso acontece, o usuário owner da carga dos objetos tem acesso a essa estrutura de dados sem problema, mas novos usuários,
-- ou usuários permissonalizados não tem a permissão para os objetos ou para novos objetos nesse schema.
-- O script abaixo tente a sanar um cenário em que você quer liberar o acesso de select para os objetos e novo objetos em um schema pulic
-- ou personalizado sem ter que ficar dando grant toda a vez que novos objetos são criados.
-- Outra opção de uso é caso você tenha um Redshift na sua empresa e venda como serviço ele como datalake para algum cliente.
-- dessa forma você consegue liberar um usuário para que o cliente acesse a estrutura de dados e consiga baixar os dados.

-- criar um usuário
create user <username> with password ‘<password>’;

-- cria um grupo para receber as permissões
create group data_viewers;

-- adiciona o usuário ao grupo
alter group data_viewers add user <username>;

-- nesse caso remove a opção de criar objetos para os usuários do grupo
revoke create on schema public from group data_viewers;

-- atribui acesso no schema public ao grupo
grant usage on schema public to group data_viewers;

-- atribui select em todas as tabelas do schema public para o grupo
grant select on all tables in schema public to group data_viewers;

-- atribui acesso a futuros objetos do schema public para o grupo
alter default privileges in schema public grant select on tables to group data_viewers

novos códigos serão criados também em outro repositório:

https://github.com/bigleka