A idéia do SQL Azure parte do mesmo princípio de outras soluções na nuvem: você paga pelo que usa, tem alta disponibilidade desde planos mais básicos e reduz (ao menos teoricamente) custos com gerenciamento… mas tudo isso já foi abordado no post anterior, portanto, aqui focaremos nas principais características do SQL Azure e suas diferenças comparadas à versão stand-alone que instalamos em nossos servidores.

Transparência

Em primeiro lugar, é preciso entender que como as demais soluções na nuvem, a administração do SQL Azure é muito transparente para o usuário. Se hoje, você DBA se preocupa com  as questões físicas da sua instância, como a localização dos seus datafiles, tamanho dos arquivos de log, rotinas de backup, recovery model, atualização de service packs, etc… esqueça. Tudo isso é abstraído no SQL Azure.

Comandos como xp_cmdshell, backup database, restore database não são suportados pelo SQL Azure.

Bases de dados diferentes

Uma mudança significante que pode afetar a forma como trabalhamos com o SQL Server é que no SQL Azure  não podemos realizar operações entre bases de dados diferentes; isso se aplica desde consultas, até cenários de replicação, database snapshot, mirroring e etc.

Bancos de sistemas

Outra coisa que você sentirá falta: o SQL Azure não expõe todas as bases de dados de sistema (model, tempdb, etc). A única exposta é a master, mas ela não tem exatamente o mesmo papel da master nas versões stand-alone e mesmo sendo o administrador da instância, não é possível criar objetos na master do SQL Azure.

Segurança

Na segurança, justamente por seu banco de dados estar na nuvem, não existe a opção de Windows Authentication; aqui você utilizará somente o SQL Server authentication.

Outras opções de segurança foram adicionadas para você administrar seu ambiente na nuvem. Você poderá, por exemplo, definir uma faixa de IPs que terão permissão para acessar sua instância.

Para o gerenciamento de logins utilizamos o Azure Management Portal. No Management Studio não temos mais interface para esta finalidade (mas ainda podemos mante-los via script).

Desenvolvimento

Para o desenvolvedor T-SQL não existem mudanças drásticas. Stored procedures, triggers, funções, transações, índices e etc são plenamente suportados.

Uma das principais mudanças é que nesta edição não é possível criar tabela temporária global. Consultas distribuídas, CLR, service broker também não são suportados.

Para ver uma lista completa do que não é suportado, consulte este link.

Armazenamento

Atualmente o SQL Azure em sua ediçao Web Edition permite armazenarmos até 5 GB; na ediçao Business o limite de armazenamento chega a 150 GB (percebemos aqui uma certa limitaçao que pode inviabilizar algumas soluçoes, mas certamente esta é uma limitaçao temporária).

Resumindo…

Pensar num SQL Server onde não temos sequer a opção de fazer backup parece assustador; mas é preciso compreender que este é o ponto focal do Azure: abstrair os pontos de administração!

Vimos aqui algumas das principais diferenças entre o SQL Azure e o SQL Server que instalamos em nossos servidores locais (stand-alone).

Nos próximos posts darei dicas de como começar a utilizar o SQL Azure e sobre como planejar a migraçao do seu banco de dados para a nuvem.

Por enquanto continuamos aqui, com a cabeça nas nuvens e os pés no chão ;)

Nesta epoca diversos “evangelistas” pregavam de forma veemente que dentro de poucos anos toda a estrutura de servidores das empresas seria descartada e tudo seria transportado para a nuvem: ERPs, CRMs, servidores de e-mail, bancos de dados… tudo estaria na nuvem. Isso levantou muita polêmica, mas a idéia tinha suas vantagens pois com isso as empresas teriam mais foco em seu próprio negócio e não teriam gastos diretos com manutenção de hardware, software, licenças, salas refrigeradas, consumo de energia e etc.

Participei desses círculos de forma bem neutra, pois algo que eu estranhava nesse cenário é que tudo dependia de um bom link com a internet e justamente, em Julho de 2008 presenciamos uma pane na Telefônica que deixou São Paulo desconectado; grandes empresas e inclusive o orgãos do governo ficaram sem link por horas e o prejuízo foi grande.

Num cenário desses, qual diretor de TI apostaria na hospedagem de seus serviços na nuvem, sendo que a depêndencia com um link é vital?!

De lá pra cá passaram-se 4 anos. O assunto “nuvem” ainda continua na crista da onda, mas já não de forma tão febril quanto antes. Mas o que tenho observado é que, sim, estamos aos poucos indo pra nuvem e a mudança está começando por nós, usuários.

Hoje a agenda e fotos do meu celular estão sincronizados com a nuvem. Quando trocar de aparelho bastará associar meu login para ter tudo de volta. Atualmente também hospedo meus principais arquivos no DropBox, aplicativo onde armazeno meus arquivos na nuvem e sincronizo uma cópia em todos os PCs que possuo, inclusive tablets e celulares. HDs não são confiáveis, de uma hora pra outra dão um problema e te deixam na mão, então porque não deixar tudo na nuvem?

Por U$ 50,00 anuais tenho 200 GB de espaço no Google para armazenar meus vídeos e fotos. Isso mitiga todos os riscos? Não. É claro que o Google e o DropBox podem perder meus arquivos, mas o risco não é comparado ao ter meus arquivos num único HD. Essas empresas armazenam nossos arquivos em datacenters espalhados pelo mundo, com profissionais dedicados 24×7 na manutenção destes ambientes.

Mas quais as vantagens da nuvem para nós usuarios, além da alta disponibilidade e a possibilidade de acessar seus arquivos de qualquer parte do mundo? Uma vantagem interessante é que você paga pelo que usa; se hoje 200 GB é muito para armazenar todas as suas fotos, então contrate 20 GB iniciais e pague somente U$ 5,00 anuais. Agora pense o quanto isto pode ser interessante pra sua empresa. Imagine aqueles períodos sazonais onde sua empresa tem grande demanda comercial e a necessidade de consumo de recursos computacionais é maior?!

Enfim; para essa coisa virar ainda é necessário muito investimento em infraestrutura no Brasil e quando isso se concretizar, eu acredito sim, que nós (empresas e usuários) estaremos nas nuvens!

Fecho o ano formado em Banco de Dados pelo IBTA; o TCC foi um trabalho puxado, mas junto com meus camaradas Flavio Trigolo e Altair Alexandre conseguimos uma nota 10 de tirar o folego :) Sem dúvidas, o resultado foi fruto da dedicação e vontade em fazermos um trabalho de qualidade. Agradeço a esses dois caras pela super força!

Logo no início do ano atualizei o MCITP para o SQL Server 2008 e adquiri o MCT; agora sou um instrutor oficial Microsoft :) Agora acreditem, o melhor do MCT eu descobri depois: a biblioteca disponível para os MCTs é sensacional, uma excelente fonte de estudos.

O OCP não rolou; e a desculpa é fajuta (mas verdadeira): faltou tempo.

O projeto atual está a todo vapor e estou trabalhando como nunca… mas é um projeto sensacional; pra resumir o cenário imagine: a construção de um ERP (do zero) para um grande varejista do mercado… é este o lugar que estou trabalhando.

Aqui no blog foram 5500 visitas em média por mês… infelizmente em contrapartida eu falhei com a meta dos 2 posts por mês; essa meta ficou aquém do que eu havia planejado, mas pretendo compensar esse desfalque em 2012.

Na vida pessoal, graças a Deus, a vida com a família tem ido muito bem. A filhota completa em Janeiro 1 ano de idade e tem crescido com muita saúde. Não há felicidade maior que isso para um pai fresco, risos…

Enfim, que venha 2012!

A você, meu amigo, meus sinceros votos de um ano rico em saúde e conhecimento. Continuaremos juntos por aqui.

Forte abraço,

Silas Mendes

Assisti 8 trilhas e acho interessante tecer minhas considerações:

General Session

Essa foi a trilha de abertura do evento e abordou em resumo todas as novidades do mundo Microsoft para os próximos meses. Gostei. Teve um toque de show com direito a discurso do presidente da Microsoft Brasil, algumas demos apresentando o System Center 2012, Windows Phone 7, SQL Server Denali, Office 365, Cloud, Cloud, Cloud, Cloud (isso mesmo; acho que ouvi essa palavra umas 100 vezes, risos) e etc.

Em especial gostei:

• da notícia da fabricação do XBOX no Brasil;
• da apresentação do Windows Phone e suas aplicações;
• do System Center interagindo com dispositivos Android e iOS;
• dos novos relatórios (super dinâmicos) do Reporting Services sendo exibidos/editados no browser (via SharePoint).

Achei esta sessão um pouco longa; durou cerca de 3 horas… mas vamos falar um pouco das outras palestras:

O que há de novo no Microsoft SQL Server Code-Named “Denali”

Foi a segunda palestra que assisti e sinceramente, foi decepcionante. Não posso avaliar o conhecimento dos palestrantes, mas o conteúdo e a apresentação estavam muito aquém do que se espera de um evento desse porte. Sai dessa trilha na esperança de que o nível melhorasse nas próximas… e melhorou.

Como montar um ambiente de alta disponibilidade com o Hyper-V

O palestrante Rodrigo Immaginario mandou muito bem nessa sessão, abordando as vantagens e desvantagens das diferentes formas de implementação de um cluster + Hyper-V. O cara acessou o ambiente de produção dele no Espírito Santo e fez um live migration “no quente”. Gostei.

Microsoft SQL Server Code-Named “Denali” AlwaysOn: Introduzindo a nova geração de soluções para alta disponibilidade

Uma das melhores trilhas que assisti… Nilton Pinheiro fez uma  apresentação impecável da nova feature de alta disponibilidade do Denali: AlwaysOn. Foi nesta trilha que descobri algo muito interessante no Denali: agora poderemos instalar o SQL Server num Windows Server Core! Bacana!

No 2º dia assisti as seguintes trilhas:

T-SQL: o que você deve saber do Microsoft SQL Server 2008 R2 e as novidades do SQL Server Code-Named “Denali”

Excelente trilha com o Gustavo Maia. O cara apresentou com muita propriedade as novidades da linguagem T-SQL no SQL Server 2008 R2 e Denali, fazendo comparativos entre SGBDs, apresentando dados históricos, e etc. Enfim, essa palestra foi muito bacana porque eu ainda não tinha parado pra olhar as novidades do T-SQL no Denali; somou muito!

Boas práticas para o SQL Server em ambientes virtualizados

O palestrante Airton Leal mandou muito bem; era nítido o domínio do cara nas tecnologias de virtualização e ele deu dicas preciosíssimas para quem quer trabalhar com ambiente virtualizado. Uma informação muito interessante que ele disponibilizou: se você tem um sistema rodando numa maquina física e deseja transporta-lo para uma maquina virtual, esteja ciente que o overhead mínimo no desempenho será de 12%. Essa informação foi bem bacana, porque muita gente defende que não tem custo nenhum; afirmação que para mim sempre pareceu bem absurda. O único ponto que achei muito estranho nessa palestra: o título! Tudo era focado em boas práticas para ambientes virtualizados, porém, nada focado em SQL Server. Mesmo assim, somou!

Cenários de otimização com o SQL Server “Denali” e 2008

Trilha de alto nível técnico com o Luti e Fabiano Amorim… os caras deram dicas preciosas de otimização, todas muito bem argumentadas e demonstradas. Se eu não tivesse feito o curso de internals e de índices (com o Luti), diria que essa teria sido, para mim, a melhor trilha do evento, pois em 1 hora, os caras deram informações que você não encontra na maioria dos livros de tunning. Muito bom mesmo!

Raio-X do SQL Server: Arquitetura interna do gerenciador de banco de dados

Outra trilha fantástica! Inicialmente não tinha me programado para assistir essa palestra, porque fiz o curso de internals recentemente; mas mudei os planos mais na curiosidade e fui surpreendido pela apresentação do Catae e do Felipe Pimenta… em 1 hora os caras conseguiram resumir e discorrer sobre os principais pilares da arquitetura do SQL Server. Muita gente saiu dessa trilha com o cérebro fritando, mas os palestrantes foram ótimos e se esforçaram em serem o mais didático possível. Fechei o Teched com 2 trilhas nível 400 de verdade :)

Conclusão

O evento foi muito bom, com excelente organização e pontualidade. A maioria dos palestrantes eram “feras” e isso enriqueceu muito a experiência. Agora a pergunta que muita gente me faz: “voltaria ao evento em 2012?”. E eu respondo: o evento é muito bom, porém ainda acho que não vale o preço (principalmente quando o profissional paga do próprio bolso, risos). Enfim, poderiam dar uma melhorada no valor; ou quem sabe, no próximo ano, meu cliente resolve pagar essa conta; afinal ele é um dos principais beneficiados com esse investimento :D

Mas enfim, falando um pouco sobre profissão e bancos de dados, posso dizer que 2010 foi um ano memorável. Adquiri muito conhecimento, tanto em SQL Server como em Oracle. O SQL Server continua a minha principal plataforma de banco de dados, mas foi interessante estender o olhar para outro gerenciador e notar as diferenças, pontos fortes e fracos de ambos… percebi que é muito importante ter referências; afinal quando temos um único ponto de vista, não podemos falar com propriedade de outros…

Além disso entrei num projeto onde estou rodeado de uma dezena de DBAs. Além de excelentes contatos (risos), conquistei muitos amigos. Um ambiente assim é um sonho pra qualquer pessoa que deseja se desenvolver ainda mais. Implantamos a primeira parte de um sistema em produção, o processo exigiu muito esforço mas entrou no ar e foi gratificante.

Aqui no blog foram aproximadamente 3000 visitas por mês, pode parecer pouco, mas pra quem começou sem qualquer pretensão é um belo número!

Mas 2011 promete muito mais…

Pretendo escrever um pouco mais por aqui, tentando manter uma freqüência de pelo menos 2 posts por mês… aqui no projeto teremos o desafio de implantar a segunda parte do sistema em produção… último semestre da faculdade, junto com apresentação do TCC… quero adquirir mais uns MCITPs (e quem sabe um OCA) e enfim…

Se parar pra pensar é muita coisa pra fazer em 300 e poucos dias… mas vamos lá! Saúde e entusiasmo pra todos nós!

BEGIN TRANSACTION 2011

Demais :)

Até +

USE BOAS_FESTAS
GO
PRINT 'FELIZ NATAL!!!!!!!'
GO

:))))

Nosso cenário: Os arquivos de dados e log da base de dados MoveArquivo estão no mesmo disco. Para otimizar a performance decidimos movimentar o arquivo de log para outro disco.

Existem diversos meios de realizar esta tarefa, a seguir iremos analisar uma delas (e a que particularmente acho mais prática):

“Mão na massa”

Primeiro, precisamos ter algumas informações em mãos; por exemplo, o nome lógico do arquivo que será alterado e o local atual do arquivo de log de nossa base de dados:

Para isso podemos utilizar o comando sp_helpdb:

Ok; já sabemos onde está nosso arquivo de log. Agora precisamos alterar este endereço e para isto utilizamos o seguinte comando:

USE MASTER
GO
ALTER DATABASE MoveArquivo
MODIFY FILE (NAME = 'MoveArquivo_log', FILENAME = 'E:\SQLDbs\Log\MoveArquivo_log.ldf')
GO

Após execução do comando temos a seguinte mensagem:

The file “MoveArquivo_log” has been modified in the system catalog. The new path will be used the next time the database is started.

Temos então, numa tradução livre, o alerta: “O novo caminho só será utilizado após reinicialização da base”. Então fique atento! Este comando não alterou efetivamente o endereço físico do arquivo; para concluir a operação precisamos reiniciar a base.

Para não afetarmos a operação dos outros bancos da instância e para reduzirmos o tempo de parada, não vamos mexer com o serviço do SQL Server; vamos apenas alterar o estado da base de dados, deixando-a offline:

ALTER DATABASE MoveArquivo
SET offline
GO

Após execução deste comando a base fica indisponível para qualquer usuário e agora podemos copiar fisicamente o arquivo de log para seu novo endereço. Neste momento, através de um CTRL + C, CTRL+ V (ou qualquer outro meio de copiar um arquivo no Windows) copiamos o arquivo para seu novo endereço.

Atenção: tenha certeza de copiar o arquivo para o mesmo endereço informado no primeiro comando ALTER DATABASE.

Finalizada a cópia, podemos reiniciar nossa base de dados com o seguinte comando:

ALTER DATABASE MoveArquivo
SET online
GO

Pronto! Arquivo de log movimentado para novo endereço.

O mesmo procedimento pode ser utilizado para outros tipos de arquivos (como arquivos de dados). Para as bases de sistema (MASTER, TEMPDB, etc) não será possível utilizar a opção SET ONLINE/OFFLINE; neste caso teremos que reiniciar o serviço do SQL Server, afetando a disponibilidade de toda instância.

Até +

Em versões anteriores do SQL Server, poderíamos utilizar triggers DML para suprir necessidades similares, e para isso tínhamos que programar a trigger que seria disparada e que gravaria a alteração em outra tabela; no entanto, este processo demandava esforço e exigia um controle na manutenção das triggers e tabelas de apoio. Com o CDC, a partir do momento que o DBA habilita-o em determinada tabela, o SQL Server se responsabiliza por toda a estrutura necessária para capturar e registrar as mudanças.

Como funciona?

O CDC captura e registra alterações baseado no log do SQL Server; basicamente ele utiliza o mesmo mecanismo da replicação transacional: o CDC lê o log do SQL Server e registra as alterações em suas tabelas. Note que este processo é assíncrono, ou seja, um dado é alterado e a alteração fica registrada no log; periodicamente é feita uma leitura no log e as alterações são registradas nas tabelas do CDC (criadas pelo SQL Server no schema CDC).

“Mão na massa”

Agora vamos exemplificar um cenário simples utilizando o CDC, monitorando uma única tabela.

No primeiro passo iremos criar a tabela que será utilizada em nossos testes:

-- Cria tabelas para teste

CREATE TABLE Funcionario (
codigoFuncionario INT NOT NULL,
nome VARCHAR(60),
idade INT,
numeroCPF CHAR(11)
);
GO
ALTER TABLE Funcionario
ADD CONSTRAINT PK_CodFunc
PRIMARY KEY (codigoFuncionario);

Agora ativamos o CDC na base de dados e na tabela Funcionario:

-- Habilita CDC banco

EXEC sys.sp_cdc_enable_db;
GO
-- Habilita CDC na tabela Funcionario

EXECUTE sys.sp_cdc_enable_table
@source_schema = 'dbo',
@source_name = 'Funcionario',
@role_name = 'roleCDC';

Ao habilitar o CDC, o SQL Server cria jobs que serão executados pelo SQL Server Agent. Estes jobs serão os responsáveis pelo registro das alterações nas tabelas do CDC; logo, para o CDC funcionar corretamente, lembre-se que o SQL Server Agent deve estar em execução.

Com o CDC habilitado, vamos popular a tabela Funcionario:

-- Carga de dados

INSERT INTO Funcionario (codigoFuncionario, nome, idade, numeroCPF)
VALUES
(1, 'Silas Mendes', 29, '08643238736'),
(2, 'Antonio Robberto', 36, '04686398765'),
(3, 'Joana Maxado', 45, '52341369844'),
(4, 'Roberto',null, null),
(5, 'Armando Filo', null, '41397601223');

Agora já podemos consultar a tabela do CDC que armazena as alterações na tabela Funcionario:

Observe que a tabela do CDC está no esquema CDC.

Lembre-se que este é um processo assíncrono, portanto ao executar o comando abaixo, pode ser que a tabela ainda não tenha sido atualizada; neste caso, repita a execução do comando.

SELECT * FROM cdc.dbo_Funcionario_CT;

No resultado são retornadas 9 colunas. Neste momento atente-se à coluna __$operation. Note que ela está com o valor: 2. O valor 2 significa que estes registros foram resultado de inserções.

Vamos continuar manipulando os dados para verificar os reflexos das alterações nas tabelas do CDC:

-- UPDATEs na tabela Funcionario

UPDATE Funcionario
SET Nome = 'Antonio Roberto'
WHERE codigoFuncionario = 2;

UPDATE Funcionario
SET Nome = 'Joana Machado'
WHERE codigoFuncionario = 3 ;

UPDATE Funcionario
SET Nome = 'Roberto Nespolitano',
Idade = 18, NumeroCPF = '08468354173'
WHERE codigoFuncionario = 3;

Observe o registro das alterações na tabela do CDC:

SELECT * FROM cdc.dbo_Funcionario_CT;

Agora observe que aumentou a quantidade de registros da tabela do CDC. Além das inserções (__$operation = 2) temos também o ANTES e DEPOIS nas operações de UPDATE. Observe agora que, onde o campo __$operation é igual a 3 o registro contém o estado antes do UPDATE, e onde o campo __$operation = 4 temos o estado do registro após o UPDATE.

Para finalizar nosso exemplo, vamos realizar uma exclusão e verificar como essa alteração é registrada:

DELETE FROM Funcionario
WHERE codigoFuncionario IN (2,3);

Execute novamente a consulta na tabela do CDC:

SELECT * FROM cdc.dbo_Funcionario_CT;

Agora notamos: onde o campo __$operation = 1 temos os registros que foram excluídos da tabela Funcionario.

CONCLUSÃO

Como observamos, basicamente são necessários 4 passos para utilizar o CDC:

• Utilizar a versão Enterprise (ou superior) do SQL Server 2008;
• O serviço SQL Server Agent deve estar ativo;
• Ativar o CDC no banco de dados utilizando a procedure sp_cdc_enable_db;
• Ativar o CDC nas tabelas que serão monitoradas utilizando a procedure sp_cdc_enable_table.

Vimos também que na tabela de registro do CDC temos diversos valores para o campo __$operation, sendo:

Hoje abordamos somente os processos básicos do CDC. Irei estender este assunto em outros  posts, onde pretendo abordar alguns detalhes interessantes desta nova feature do SQL Server 2008.

Até +

A linguagem SQL é composta por inúmeros comandos, os quais são agrupados da seguinte maneira:

• Comandos que definem dados;
• Comandos que manipulam dados;
• Comandos de controle de dados.

Algumas literaturas adicionam outras subdivisões, mas neste post vamos nos ater somente as citadas acima.

• DDL

Quando você cria um banco de dados, ele inicialmente está “vazio”; antes de começar a consultar e alterar dados é preciso definir onde e como as informações serão gravadas dentro do novo banco; então você cria diversas tabelas explicitando o tipo de dados de cada campo, as chaves estrangeiras, os índices, as regras e etc. Estes comandos de criação e alteração de estrutura são os comandos de DEFINIÇÃO dos dados, pois definem como os dados serão armazenados; em inglês são chamados de: Data Definition Language (DDL). Logo, quando falamos em comandos do tipo DDL estamos falando de comandos do tipo: CREATE, ALTER ou DROP; comandos que criam, alteram ou excluem objetos como tabelas, procedures, índices, relacionamentos e etc.

Exemplos de comandos DDL:

-- Cria uma tabela

CREATE TABLE Pessoa(
codigoPessoa char(11),
nomePessoa varchar(50));

-- Altera tabela

ALTER TABLE Pessoa
ADD numeroTelefone varchar(11);

-- Exclui tabela

DROP TABLE Pessoa;

• DML

Depois que você criou suas tabelas, definiu relacionamentos, índices e etc., é hora de  manipular seus dados; os comandos SQL que MANIPULAM dados são os populares SELECT, INSERT, UPDATE e DELETE. Em inglês esses comandos são chamados de Data Manipulation Language o que explica a abreviação DML.

Em algumas literaturas o comando SELECT não é considerado um comando de manipulação de dados, sendo enquadrado numa outra categoria: DQL, Data Query Language, em português: Linguagem de consulta.

Exemplos de comandos DML:

-- Seleciona dados

SELECT nome+' '+sobrenome
FROM Pessoa;

-- Altera dados

UPDATE Pessoa
SET codigoPessoa = '35649869711';

-- Exclui dados

DELETE Pessoa;

• DCL

Com o banco de dados pronto e rodando é importante definir quem poderá acessá-lo, enfim, precisamos definir a segurança do seu banco. Em inglês, os comandos responsáveis pelo controle dos dados são chamados de Data Control Language (DCL). Os comandos GRANT e REVOKE fazem parte deste grupo.

-- Permissão de seleção na tabela Pessoa para a usuária Maria

GRANT SELECT ON Pessoa TO Maria;

-- Permissão de seleção e inserção na tabela Pessoa para o usuário Alberto

GRANT SELECT, INSERT ON Pessoa TO Alberto;

-- Negando alterações na tabela Pessoa para usuários do grupo GRP_RH

DENY INSERT, UPDATE, DELETE ON Pessoa TO GRP_RH;

• CONCLUSÃO

A linguagem SQL é constituída de diferentes tipos de comandos e estes comandos são agrupados em três categorias principais, sendo: comandos DDL as instruções que definem estruturas de armazenamento dos dados; DML os comandos que manipulam os dados e DCL os comandos que controlam o acesso aos dados.

Durante as atividades do dia-a-dia você utilizará com mais freqüência os comandos do tipo DDL e DML.

Até +