Category Archives: SQL Server Basico

Novo contribuinte ao Blog

Boa tarde a todos os leitores!!!

Quero antes de mais nada agradecer ao Fabrizzio pelo convite de escrever aqui, é uma grande honra poder estar contribuindo com todos.

Espero que meus posts venham ajudar no dia a dia ou até mesmo em algum problema específico. Espero também receber comentários sendo positivos ou negativos de forma que eu possa acrescentar as minhas experiências e cada vez mais melhorar os temas que irei abordar.

Em breve iniciarei por aqui, espero que gostem!!!

Um grande abraço a todos!

Eric Malzone

SQL Server Basico 6 – Constraints

Enfim, depois de muito tempo sem conseguir postar nada, estou agora, voltando a minha rotina normal de posts, e tentar manter a media de ao menos 2 posts por semana.

Como primeiro post pós retorno, quero falar sobre um assunto bem simples, porem que ainda gera muitas duvidas, alem de que, muitas pessoas que estão iniciando no mundo de banco de dados não conhecem: CONSTRAINTS.

O que é uma constraint?
Constraint é uma regra que voce ira aplicar a seus dados

Para que serve?
Uma constraint possui como função principal garantir a qualidade de seus dados, evitando situações do tipo: A, eu tenho uma venda aqui para um cliente que não existe, entre outros….

Quais tipos existem?
– Primary Key: Todas as linhas da coluna devem ser não nulas, e não pode haver repetições
– Foreign Key: O valor a ser inserido deve, obrigatoriamente, existir em uma outra tabela
– Check: O valor inserido deve atender a uma condição como True, para que seja inserido com sucesso
– Nulavel/Não nulavel: Aceitar ou não valores nulos
– Default: Assumi um valor padrão, caso a coluna não seja especificada no insert

--CRIA TABELAS PARA TESTES
CREATE TABLE ConstraintsBlog01
(
	Id INT IDENTITY(1,1) PRIMARY KEY,
	Usuario VARCHAR(100),
	Data_Nascimento DATETIME
)

CREATE TABLE ConstraintsBlog02
(
	Id INT REFERENCES ConstraintsBlog01(Id),
)

CREATE TABLE TesteConstraint03
(
	Id INT IDENTITY(1,1) PRIMARY KEY,
	nm_Usuario VARCHAR(100) DEFAULT 'SEM NOME'
)
---------------------------------------------------PRIMARY KEY---------------------------------------------------------------
--> No caso, ja colocamos o campo Id da tabela ConstraintsBlog01 como PrimaryKey na criação da tabela, porem, para criarmos
--> um campo como PK, devemos executar o seguinte comando:
ALTER TABLE ConstraintsBlog02 ADD CONSTRAINT PK_Id PRIMARY KEY (Id)
--> Por que do erro: O campo Id da tabela ConstraintsBlog02 é nulavel, e como uma PK não pode ser nula ou repetida, devemos
--> executar:
---------------------------------------------------NULL/NOT NULL-------------------------------------------------------------
ALTER TABLE ConstraintsBlog02 ALTER COLUMN Id INT NOT NULL

----------------------------------------------VOLTANDO A PRIMARY KEY---------------------------------------------------------
ALTER TABLE ConstraintsBlog02 ADD CONSTRAINT PK_Id_ConstraintsBlog02 PRIMARY KEY (Id)

------------------------------------------------CONSTRAINT DE CHECK-----------------------------------------------------------
--INSERE O PRIMEIRO VALOR
INSERT INTO ConstraintsBlog01(Usuario, Data_Nascimento) VALUES ('Fabrizzio Antoniaci Caputo', '20100921')
-->Inserido com sucesso, pois não ha nehuma restrição para a data ou o nome

--CRIA CONDIÇÃO DE CHECK PARA DATA
ALTER TABLE ConstraintsBlog01 ADD CONSTRAINT ChecaData CHECK (Data_Nascimento < DATEADD(YEAR, -18, GETDATE()))
--> O que faz: Toda data inserida, deve brigatoriamente ser mais do que 18 anos, em relação ao dia da inserção
--> Por que do erro, ja existe um valor que não respeita essa regra, portanto, temos que executa-la assim:
ALTER TABLE ConstraintsBlog01 WITH NOCHECK ADD CONSTRAINT ChecaData CHECK (Data_Nascimento < DATEADD(YEAR, -18, GETDATE()))

--TENTATIVA DE INSERÇÃO INVALIDA
INSERT INTO ConstraintsBlog01(Usuario, Data_Nascimento) VALUES ('Fabrizzio Antoniaci Caputo', '20100921')
-->Erro por que novos valores inseridor, irão ter de respeitar a constraint

--TENTATIVA DE INSERÇÃO VALIDA
INSERT INTO ConstraintsBlog01(Usuario, Data_Nascimento) VALUES ('Fabrizzio Antoniaci Caputo', '19910921')

----------------------------------------------------FOREIGN KEY-------------------------------------------------------------
--> Uma foreign key, faz que um valor que va ser inserido em um campo de uma tabela, exista previamente em uma outra tabela
--> Se tentarmos inserir o valor
INSERT INTO ConstraintsBlog02 VALUES (5)
--> Teremos um erro de FK, pois o valor 5, não existe na tabela ConstraintsBlog01, cujo campo tem referencia
SELECT * FROM ConstraintsBlog01 --> Temos os valores 1 e 3, portanto, ao executar...
INSERT INTO ConstraintsBlog02 VALUES (3)
--> Temos uma inserção com sucesso

--------------------------------------------------DEFAULT------------------------------------------------------------------
--> Ao inserir valores em uma coluna com uma constraint default, sera inserido e valor espeficicado, porem, se o mesmo não for
--> sera inserido o valor default
--INSERÇÃO SEM VALOR DEFAULT
INSERT INTO TesteConstraint03(nm_Usuario) VALUES ('FABRIZZIO')
SELECT * FROM TesteConstraint03

--INSERT UTILIZANDO O VALOR DEFAULT
INSERT INTO TesteConstraint03 DEFAULT VALUES
SELECT * FROM TesteConstraint03

SQL Server Basico 5.2 – Triggers

Este é o segundo de uma seria de 3 posts sobre Trigger, o primeiro, que pode ser encontrado neste link, fala sobre triggers basicas de comandos DML, ou seja, insert, update e delete, este aqui, falarei sobre a possibilidade de trigger para comandos DDL, ou seja, criar uma trigger que seja disparada toda vez que um comando CREATE TABLE ou um comando ALTER PROCEDURE for executado.

Como primeira explicação, é necessario saber que triggers DDL são divididas em 2 sub-categorias:
– De base de dados (Ex: Criação de uma tabela)
– De instancia (Ex: Criação de uma base de dados)

Abaixo alguns exemplos das ações cujas quais podem ser alvos de triggers DDL:

Nivel de Base de dados:
– CREATE INDEX
– ALTER VIEW
– CREATE TABLE

Nivel de Instancia:
– DROP ENDPOINT
– CREATE DATABASE
– REVOKE SERVER

Enfim, a lista completa contem inumeras possibilidades e não seria inteligente colocar todas aqui, sendo que a lista completa se encontra aqui disponivel gratuitamente no Books Online.

Porem…Por que utilizar triggers DDL?
Existem muitas respostas para essa pergunta, inclusive uma dela pode ser encontrada aqui neste meu outro artigo , no caso este artigo, contem alguas outras informações que serão discutidas no proximo posts sobre triggers.
Uma das melhores respostas é que no SQL Server 2005 (Menor versão que suporta triggers DDL), é um meio de auditoria muito eficar, talvez cause um pouco de queda de performance, mas é provavelmente uma das melhores auditorias possivel do SQL Server 2005, no SQL Server 2008 ou SQL Server 2008R2 temos a possibilidade de auditoria nativa, que é muito melhor com certeza, porem, ainda no SQL Server 2008[R2] as triggers DDL são necessarias, por exemplo, um dos tunnings fisicos possivel é separar os indices criados em um outro filegroup e outro disco, com triggers DDL é possivel fazer com que tentativas de criação de indices fora do filegroup correto, não sejam criados, ou então, uma situação que passei semana passada em um cliente:
– Existe o usuario da aplicação, vamos chama-lo de app_user
– app_user, precisa ter permissão de execução em todas as procedure e function
– app_user necessita tambem permissão de select em todas as views
Lembrando que as functions, view e procedures, são criadas o tempo todo, e como os usuarios que criam esses objetos são os desenvolvedores, e não possuem permissão de conceder as execuções ou selects para o usuario, criei uma trigger para os eventos de CREATE_FUNCTION, CREATE_PROCEDURE e CREATE_VIEW, que ao final da trigger, da permissão ao usuario app_user para esse novo objeto criado.
Dessa forma, o permissionamento fica automatico, sem a necessidade de conceder security_admin aos desenvolvedores.

Até o momento esta tudo lindo, porem, uma duvida pode surgir para voces leitores, quando se esta criando uma procedure por exemplo, o nome da mesma é variavel, assim como o usuario que a criou, enfim, existem muitas variaveis nas execuções deste comando, portanto, fica a pergunta: Como é possivel visualisar de forma dinamica todas essas informações? A resposta é muito simples!, Existe uma função ja criada chamada EVENTDATA().

Essa função EVENTDATA() ira retornar um XML com todas as informações possivel de se capturar para cada evento.
Abaixo segue um exemplo da mesma.

CREATE_PROCEDURE
2011-11-28T12:26:50.787
54
LFERREIRA-PC\FABRIZZIO08ENT
sa
dbo
Teste2
dbo
Hora5
PROCEDURE

CREATE PROCEDURE dbo.Hora5
AS
BEGIN
SELECT GETDATE()
END

O que temos então de informação neste XML?

EVENT_TYPE: Tipo de evento, no caso, CREATE_PROCEDURE
POSTTIME: Hora do evento
SPID: Spid que gerou o evento
SERVERNAME: Nome do servidor cujo evento disparou a trigger
LOGINNAME: Login que realizou o evento
USERNAME: Usuario (Como fiz como SA, ele trouxe dbo)
DATABASENAME: Nome da base
SCHEMANAME: Schema que gerou o evento
OBJECTNAME: No caso, objeto criado
OBJECTTYPE: Tipo de objeto
TSQLCOMMAND: Comando TSQL que disparou o evento

Lembrando que esses são os campos para procedures, não necessariamente serão os mesmos para functions e views.

Como meu proximo post sobre triggers sera 100% focado no eventdata() e na leitura xml, aqui colocarei algo bem simples, apenas para que possamos ver uma trigger DDL ser disparada e ja dar liga para o proximo post…. Exemplo:

CRIAÇÃO DA TABELA

CREATE TABLE Teste_XML 
(
EVENTDATA_XML XML
)

CRIAÇÃO DA TRIGGER DLL

CREATE TRIGGER audit_Create_Proc
ON DATABASE
FOR CREATE_PROCEDURE
AS
DECLARE @Event XML
SET @Event = EVENTDATA()
INSERT INTO Teste_XML VALUES (@Event)

CRIAÇÃO DE UMA PROCEDURE DE TESTE

CREATE PROCEDURE dbo.Hora5
AS
BEGIN
SELECT GETDATE()
END

SELECT DE TESTE

SELECT * FROM Teste_XML

SQL Server Basico 5 – Triggers

Triggers, quando traduzidas, querem dizer gatilhos, gatilhos são disparados, no caso de uma trigger, por evento, uma trigger pode disparar por a exemplo:

Contexto de tabela
– A cada insersão
– A cada deleção
– A cada atualização

Contexto de instancia
– Cada logon
– Cada criação ou deleção de uma tabela

Portanto, tendo conhecimentos dessas 2 possiveis opções, neste post, irei falar apenas sobre Triggers de tabelas.

Trigger de tabela:
Ira disparar quando algo acontecer em relação a aqueles dados, seja um insert, update ou delete, algumas pessoas podem pensar que é possivel auditar o drop de uma tabela a partir da criação de uma trigger na mesma, mas não é, por que:
Uma tabela -> (Contem) -> Dados, portanto, audita-se apenas dados.
Triggers neste contexto existem para assegurar a validade de seus dados por todo o ambiente, uma vez que estamos falando de um ambiente normalizado automatizando algumas tarefas para evitar retarefa, por exemplo:

SITUAÇÃO
– Existe uma tabela chamada USUARIOS, que contem todos os usuarios da empresa.
– Uma outra tabela denominada EMPRESA, que contem o cargo de cada pessoa dentro da empresa.
– O que aconteceria quando um funcionario fosse demitido e seu nome removido da tabela usuarios?
Basicamente ele deveria ter de ser removido tambem da tabela empresa, uma vez que ele não pertence mais a organização. Talveza melhor opção seja a criação de uma procedure contendo a deleção deste usuario das duas tabelas, porem, mesmo todo o processo mascarado por traz de uma procedure, dentro da mesma, ainda serão executadas 2 deleções, portanto, alguem teve que programar as 2 deleções. Com a utilização de trigger, seria possivel realizar apenas uma, e deixar a trigger realizar essa deleção.
Quando estamos falando de procedure, temos 2 tabelas especiais criadas em tempo de execução das queries que podemos utilizar para capturar os dados sejam eles inseridos ou deletados, quando estamos falando de uma insersão de dados, podemos utilizar a tabela INSERTED, e ela contem exatamente os mesmos campos da tabela em questão, ja para deleção de dados, temos a DELETED, que tambem contem os mesmos campos, quando falamos de update, temos as 2, uma vez que um update é composto de uma deleção + uma insersão.

Representação do exemplo acima com insersão:

--CRIAÇÃO DAS TABELAS
CREATE TABLE Usuarios
(
	Usuario VARCHAR(100),
	Senha	VARCHAR(100)

)

CREATE TABLE Empresa
(
	Nome	VARCHAR(100),
	Cargo	VARCHAR(100)
)

--CARGA DE DADOS
INSERT INTO Usuarios VALUES
('Fabrizzio','Fabri'),
('Giovanni','gio'),
('Camila','Cam')

INSERT INTO Empresa VALUES
('Fabrizzio','Gerente'),
('Giovanni','Coordenador'),
('Caimla','Diretora')

--CRIAÇÃO DA TRIGGER DE INSERSÃO
CREATE TRIGGER T_Insert ON Usuarios
FOR INSERT
AS
DECLARE @Usuario VARCHAR(100)
SET @Usuario = (SELECT Usuario FROM INSERTED)
INSERT INTO Empresa VALUES (@Usuario, NULL)

--PRIMEIRO SELECT DE TESTE
SELECT * FROM Usuarios
/*
Fabrizzio	Fabri
Giovanni	gio
Camila	Cam
*/

SELECT * FROM Empresa
/*
Fabrizzio	Gerente
Giovanni	Coordenador
Caimla	Diretora
*/

--INSERSÃO DE TESTE
INSERT INTO Usuarios VALUES ('Marco','DBA')

--SEGUNDO SELECT DE TESTE
SELECT * FROM Usuarios
/*
Fabrizzio	Fabri
Giovanni	gio
Camila	Cam
Marco	DBA
*/

SELECT * FROM Empresa
/*
Fabrizzio	Gerente
Giovanni	Coordenador
Caimla	Diretora
Marco	NULL
*/

Representação do exemplo acima com deleção:

--CRIAÇÃO DE TRIGGER DE DELEÇÃO
CREATE TRIGGER T_Delet ON Usuarios
FOR DELETE
AS
DECLARE @Usuario VARCHAR(100)
SET @Usuario = (SELECT Usuario FROM DELETED)
DELETE FROM Empresa WHERE Nome LIKE @Usuario

--PRIMEIRO SELECT DE TESTE
SELECT * FROM Usuarios
/*
Fabrizzio	Fabri
Giovanni	gio
Camila	Cam
Marco	DBA
*/

SELECT * FROM Empresa
/*
Fabrizzio	Gerente
Giovanni	Coordenador
Caimla	Diretora
Marco	NULL
*/

--DELEÇÃO DE UMA LINHA DA TABELA USUARIOS
DELETE FROM Usuarios WHERE Usuario LIKE 'Marco'

--SEGUNDO SELECT DE TESTE
SELECT * FROM Usuarios
/*
Fabrizzio	Fabri
Giovanni	gio
Camila	Cam
*/

SELECT * FROM Empresa
/*
Fabrizzio	Gerente
Giovanni	Coordenador
Caimla	Diretora
*/

Claro, que neste caso, a performance da trigger seria pior do que em uma procedure aonde o comando seria executado na propria tabela e não ao disparar de uma trigger, portanto, trigger nem sempre são recomendadas e podem sim serem evitadas, porem, existem muitos sistemas aonde grande parte de integridade dos dados é feita via trigger, outro, aonde o uso de trigger é mais consciente, pense em um software aonde é proibido mexer em seu banco de dados, hoje em dia isso é bem comum, e tudo deve ser feito atravez de telas de sistemas, vamos supor que essas telas chamem procedures, que são responsaveis pela integridade dos dados, a empresa que criou e vendeu o software, pode sim criar uma trigger e fazer com que a mesma não seja disparada caso a ação que a disparou seja a procedure, desta forma, alem de manter a segurança dos dados pela proibição de se mexer do usuario, caso ele altere alguma coisa, não havera falta de integridade dos dados.

SQL Server Basico 4 – Agendando um Job no SQL Server

Em um banco de dados podemos dividir basicamente todas as operações de uma forma macro em 2 tipos, as que são feitas pelo usuario, ou seja, On Demmand, e as que são agendadas para um certo periodo, com uma certa ocorrencia.
Para as operações On Demmand não ha muito o que se explicar, ja que normalmente isso esta na aplicação que faz a conexão com o banco, portanto, neste post focarei na criação de tarefas agendadas do SQL Server, ou seja, o famoso Criação de um job.
Antes de mais nada é preciso saber que toda tarefa dentro do SQL Server é agendada atravez de um serviço do windows chamado SQL Server Agent, maiores explicações sobre o mesmo estão neste post que fiz sobre Os serviços do SQL Server no ambiente Windows.
Saiba tambem que se estivermos falando de SQL Server versões 2005 ou 2008, a versão express de ambas não possuem SQL Server Agent, tornando impossivel o agendamento de tarefa de dentro do SQL Server, apenas como uma introdução do meu proximo post SQL Server Basico, nesses casos voce deve criar o arquivo .sql, manter em uma pasta e executa-lo atravez de um arquivo .bat, agora, se voce utiliza o SQL Server 2000 (Alem de precisar se atualizar…), a versão express do 2000 é chamada de MSDE e a mesma possui sim o SQL Server Agent.

Iniciando Todo o Processo

Abaixo segue um passo-a-passo de como se criar um job no SQL Server e as opções detalhadas:

Clique no “+” no SQL Server Agent

Clique com o botão direito em jobs e va em “New Job” como mostra a figura abaixo.

E uma tela conforme a seguinte deve-se abrir, veja que em Owner, ira aparecer o usuario com qual voce esteja realizando este passo-a-passo.

Aqui temos alguns campos:
Name: O Nome do job, este ira aparecer na lista de todos os jobs, portanto o nome do mesmo deve ser algo que diga bastante sobre o mesmo, que de apenas ler o nome, ja saiba pelo que ele é responsavel.
Owner: Este campo se diz respeito a qual usuario é o dono do job.
Categoria: Aqui voce pode escolher entre varias opções qual é a deste job, veja que isso não ira influenciar em sua execução, este campo serve simplismente para sua organização.

Descrição: Caso o campo nome não seja sulficiente para o proposito dito acima, voce pode colocar aqui o motivo da existencia do job.
CheckBox Enable: Se checado o job esta habilitado, se não, desabilitado.

Criando Os Steps

No menu a esquerda clicando em Steps, iremos para a tela abaixo:

Aqui em step, traduzindo literalmente, quer dizer passos, ou seja, aqui iremos colocar todos os passos, querys, scripts de PoSh (Power Shell) entre muitas outras opções que nosso job ira executar.
Ao clicar em New a tela abaixo ira aparecer:

Aqui temos as opções:
Step Name: Esse campo se diz respeito ao nome deste Step dentro deste job.
Type: Aqui segue abaixo uma lista, contendo tudo que pode ser agendado no job, o padrão é TSQL, que é um script simples.

Run as: Aqui voce só tera opções a selecionar caso possua algumas outras opções configuradas na instancia, deixarei esse assunto para outro topico.
Database: Aqui voce selecionar em qual database de sua instancia os comandos postados serão executados.
Command:Aqui sim voce deve colocar o seu comando, a chamada de sua procedure ou qualquer outra comando que voce queira executar, seja ele DDL, DML entre outros….

Clicando no menu a esquerda em Advanced iremos para a tela abaixo:

Aqui temos as opções:
On success action: A opção escolhida aqui determina o que o SQL Server Agent fara após o termino deste step caso o mesmo ocorra com sucesso.
Retry Attempts: O numero nesta opção diz quantas vezes o SQL Server agent tentara re-executar o step em caso de erro.
Retry Interval: Ja neste campo, em caso de erro, qual o intervalo entre as tenativas.
On Failure Action: Aqui vode pode determinar o que o SQL Server Agent fara caso ocorra algum erro neste step.
OutPut File: Caso voce queira ver passo a passo do que foi feito e eventualmente aonde ocorreu um erro, colocar toda a execução em um arquivo externo é a melhor opção (e para mim foi uma das questões de certificação), então neste campo, basta colocar o caminho completo adicionado do nome e a extensão do arquivo.
Append output to existing file: Esta só estara disponivel caso a opção anterior seja preenchida, com este checkbox marcado, voce esta dizendo que caso o arquivo em questao ja exista, ele ira apenas acrescentar e escrever novas informações no mesmo, caso esteja não marcado, o novo arquivo sera colocado em cima do antigo.
Log To Table: Quase a mesma opção das anteriores, porem ao invez de jogar o resultado em um arquivo externo, esta colocando o mesmo em uma tabela dentro do SQL Server.
Append output to existing entry in table: Bem parecida com a opção anterior, aqui marcado ira criar uma nova linha, nao marcado, ira concatenar com dados ja existentes (Ultima linha da tabela)
Run As User: Aqui voce pode especificar um usuario para que seja executado o job.

Agendando o JOB

Voltando a primeira tela do job, depois dos steps criado, vamos em Schedules no menu a esquerda e teremos a seguinte visão:

Ao clicar em New, voce tera a tela com todas as opções de agendamento disponivel.

Aqui podemos dividir em 6 quadros, segue abaixo explicação das mesmas:

Quadro 01

Aqui temos 2 campos:
Name: Aqui voce deve colocar o nome do agendamento, como é possivel ter mais de um agendamento, o nome deve ja resumir o que esta programado.
Schedule Type: Aqui voce pode escolher qual o tipo de agendamento, existem as opções:
Iniciar automaticamente quando o SQL Server Agent Iniciar
Iniciar quando a CPU se tornar estavel (Sem utilização)
Recorrente
Uma vez

Observação: Caso a opção Iniciar junto com o SQL Server Agent ou quando a CPU estiver estavel, nenhum outro quadro estara disponivel.

Quandro 02

Este quadro só estara disponivel quando a opção de apenas uma vez for setada no quadro 01, aqui voce deve especificar o dia e a hroa em que o job deve iniciar.

Quadro 03

Aqui voce deve indicar a frequencia com que seu job sera executado e em quais dias.

Quadro 04

Frequencia diaria, aqui voce ira configurar ou uma hroa do dia para iniciar, ou de quantas em quantas horas, iniciando em qual e terminando em qual hora voce quiser.

Quadro 05

Aqui voce pode colocar um dia limite para que seu job seja executado, caso seu job teoricamente não tera um dia final, basta colocar a opção No End Date conforme a foto.

Quadro 06

Summary, resumo, aqui voce pode ler por extenso quando seu job sera executado.

Para finalizar o agendamento de seu job, basta clicar nos OK possiveis.

SQL Server Basico 3 – Os serviços do SQL Server no ambiente Windows

Tendo em vista recentes duvidas em relação aos serviços do windows que são do SQL Server e sobre qual usuario utilizar, resolvi criar este post que explicara sobre cada serviço, e qual conta é de melhor utilização para se inicia-lo.
Os serviços do SQL Server padrão, apenas do DBEngine, ou seja, não estou considerando SSIS, SSAS ou SSRS estão listados e explicados abaixo:

SQL Server(AlgumTexto)
O que é: O Serviço principal do SQL Server, cujo qual é responsavel pelo DBEngine entre outros.
Caracteristica: O “AlgumTexto” é o nome da sua instancia caso a mesma seja nomeada, se não, estara: “MSSQLSERVER”
Importancia: Por mais que os outros serviços estejam startados, sem este ativo seu banco de dados não estara funcionando e disponivel, portanto é o serviço principal.

SQL Server Agent(AlgumTexto)
O que é: Serviço responsavel pelo agent do SQL Server, o agent é responsavel principalmente pela execução de trabalhos agendados e envio de alertas.
Caracteristica: Mais uma vez o “AlgumTexto” é o nome da sua instancia caso a mesma seja nomeada, se não, estara: “MSSQLSERVER”, vale lembrar tambem que instancia Express não possuem SQL Server Agent.
Importancia: Teoricamente sua instancia estara ativa porem nenhum trabalho automatico sera iniciado.

SQL Server Browser
O que é: Este serviço quando ativo, indice que sua instancia sera enxergada pela rede, ou seja, caso o usuario que for se conectar via SSMS, no campo de texto para se colocar o Servidor\Instancia clicar em , essa instancia ira aparecer.

Quanto a questão de qual usuario executar os serviços, saiba que no minimo é necessario um usuario que tenha poderes de execução de serviços, uma das perguntas em minha prova de certificação foi qual o melhor cenario para os 3 serviços, a resposta correta é:
Um Usuario local para cada serviço com a permissão minima de execução de serviços.
Porem, isso pode te gerar um pouco mais de trabalho, principalmente para questões administrativas automatizadas que utilizam uma instancia SQL Server e rede, portanto, em meus ambientes costumo deixar como um usuario Adm. de dominio para todos os serviços, e tomar mais cuidado com o permissionamento interno ao SQL Server.

SQL Server Basico 2 – Niveis de compatibilidade

Como dito no topico 1 do assunto “SQL Server Basico” publicado anteriormente, cada base de dados possui um recovery model, mas essa não é a unica configuração, existem muitas outras, este texto sera dedicado aos niveis de compatibilidade.
Antes de tudo é necessario saber que o nivel de compatibilidade varia entre as versões, por exemplo, se voce estiver criando uma base em uma instancia SQL Server 2005, voce tera disponivel os niveis:
– 70
– 80
– 90
Ja se for em uma instancia 2008[R2]:
– 80
– 90
– 100

Veja que tenta-se seguir uma tendencia de 3 opções distintas.

Cada nivel representa uma versão do SQL Server, portanto, dependendo do nivel da base, ela aceitara ou não certos comandos.

– 70: SQL 7.0
– 80: SQL 2000
– 90: SQL 2005
– 100: SQL 2008
– 110: SQL 2011

Caso voce esteja utilizando SQL Server 2008, e necessite executar um comando existente apenas no SQL Server 2000, voce devera alterar esse nivel para 80, saiba que uma base ira aceitar os comandos da propria versão na qual a base foi criada e os da versão referente ao nivel de compatibilidade, em nosso exemplo, essa base aceitaria comandos do SQL Server 2000 e SQL Server 2008

Para se verificar o nivel de compatibilidade de suas bases:

SELECT name, compatibility_level FROM sys.databases

SQL Server Basico 1 – Recovery Models

Cada base de dados de uma instancia SQL Server possui o seu recovery model, para se verificar essa instancia, execute a query:

SELECT [Name], [Recovery_Model_Desc]
FROM sys.databases
WHERE [Name] = 'SuaBase'

Sabe-se que toda transação realizada em uma base de dados é gravada no arquivo de log (.ldf) da reespectiva base, o recovery model indica o que acontecera com esse log.

Existem 3 opções para o recovery model de uma base de dados:

Simple: Neste modo, os seguintes steps são executado:
1. Usuario inicia transação
2. É gerado log
3. Transação do usuario é finalizada via Commit ou Rollback
4. Log dessa transação é apagada do arquivo
Veja que neste modo, não é gravado permanentemente nada em seu arquivo de log.
Ventagens: Ocupa pouco espaço em disco.
Não existe a preocupação de tratar arquivos de log ou realizar backup do mesmo
Desvantagens: Dependendo da sua estrategia de backup, manter o recovery model em simple e consequentemente não realizar backup de log, pode haver perda maiores perda de dados devido ao tempo do ultimo backup diferencial ou full.

Full:Esta opção de recovery model guarda todas as transações realizadas no arquivo de log, diferentemente da opção simple, nenhum dado é deletado do arquivo .ldf, os step executados são:
1. Usuario inicia transação
2. É gerado log
3. Transação do usuario é finalizada
4. Na proxima transação do outro usuario, simplismente sera colocado em seguida no log, mantendo os logs das transações anteriores.
Ventagens: Backup de log, portanto, restore com a opção STOP AT TIME, utilizada para voltar a base em determinado horario.
Devido as (normalmente) muitas execuções do backup de log (que só é possivel no recovery model full) tem-se normalmente uma menor perda de dados em relação ao tempo em caso de falha.
Desvantagem: Para seu log não crescer para sempre, é necessario a realização de backup de log, ter os arquivos de backup é uma coisa boa, mas o gerenciamento dos mesmos quando existem muitos, acaba ficando um pouco mais complexo.

Bulk-Logged:Essa opção é muito semelhante a opção Full, com apenas uma diferença: Quando é realizado alguma inserção bulk (Via arquivo texto por exemplo…) e o recovery model esta em Full, vamos dizer que é gerado um log do tipo:
INSERIDO TabelaA Coluna1 Fabrizzio Coluna2 Antoniaci Coluna3 Caputo
E assim para cada linha….
Porem, se a sua base estiver em recovery model bulk-logged, vamos dizer que o log gerado seria:
INSERIDO TabelaA Arquivo ‘C:\File.txt’ RowTerminator’;’ FieldTerminator’,’
Sua vantagem em relação ao recovery model full é:
Melhor performance para operações Bulk