Microsoft SQL Server 2017 Cumulative Update 9 disponível


A Microsoft informou ontem dia 19/07 no blog SQL Server Release Services a disponibilidade da Atualização Cumulativa(Cumulative Update) 9 para o Microsoft SQL Server 2017.

Atualizações Cumulativas disponíveis para o Microsoft SQL Server 2017:

O artigo KB4341265 publicado no site de suporte da Microsoft, esta nova atualização do SQL Server 2017 traz todas as correções disponibilizadas desde o lançamento do novo SQL Server, incluindo também correções para problemas encontrados após o lançamento das atualizações cumulativas anteriores.

Hotfixes que estão incluídos neste pacote de atualização cumulativa:
Número do bug VSTS Número do artigo KB Descrição Área fixa Plataforma
12144190 4340069 CORREÇÃO: SQL Server 2017 no Linux é desligado inesperadamente durante a recuperação de um banco de dados OLTP de memória OLTP in-memory Linux
12041154 4340134 CORREÇÃO: Erro quando uma função é definida com uma coluna restrita é usada para executar uma consulta drill-through no SSAS Analysis Services Windows
12128861 4340747 CORRIGIR: SQLDUMPER. Despejos EXE iniciada podem levar muito tempo para concluir o processo de geração de despejo para 2017 do SQL Server no Linux Mecanismo SQL Linux
12168709 4010460 CORREÇÃO: Um erro do.NET Framework ocorreu quando você atualiza a tabela de referência de uma transformação Fuzzy Lookup no SSIS Integration Services Windows
12138685 4339613 CORREÇÃO: “Unclosed aspas após a sequência de caracteres” erro ocorre no explorer MDS quando você tentar adicionar um novo membro para uma entidade no SQL Server Data Quality Services (DQS) Windows
12107546 4338890 CORREÇÃO: Uma instância do SQL Server pode parecer não responder e em seguida, pode ocorrer um erro de “não respondendo no Agendador” no SQL Server 2016 Mecanismo SQL Windows
11922902 4316858 CORREÇÃO: “índice corrompido” mensagem e servidor desconexão quando uma consulta de estatísticas de atualização usa hash agregação no SQL Server Desempenho do SQL Todas
12149855 4341219 CORREÇÃO: Um cenário de cérebro divisão ocorre após um failover ao usar grupos de disponibilidade do AlwaysOn com a tecnologia de cluster externo no SQL Server 2017 Alta disponibilidade Todas
12111717 4340837 CORREÇÃO: Erro 3906 quando for aplicado um hotfix em um SQL Server que possui um banco de dados em um banco de dados de inscrição de recepção de instantâneo Mecanismo SQL Windows
11983925 4133164 CORREÇÃO: Erro quando um trabalho do SQL Server Agent executa um comando PowerShell enumere permissões do banco de dados Ferramentas de gerenciamento Windows
12121216 4339664 CORREÇÃO: O erro de exceção ocorre quando você tenta atualizar dados de uma tabela dinâmica no Excel no SSAS 2017 Analysis Services Windows
12123248 4340742 CORREÇÃO: Acesso ao SSAS usando HTTP falha no SQL Server Analysis Services Windows
12162067 4341264 Aperfeiçoamento: Permitir trabalhos do SQL Server Agent iniciar sem esperar que todos os bancos de dados obter recuperado no SQL Server 2017 no Linux Mecanismo SQL Linux
12186129 4101502 CORREÇÃO: Backup de banco de dados TDE habilitada com compactação causa corrupção de banco de dados no SQL Server Mecanismo SQL Todas
12129434 4134601 CORREÇÃO: “não foi possível carregar arquivo ou assembly ‘ Microsoft.AnalysisServices.AdomdClientUI” erro quando uma operação de “Processo total” é executada no SQL Server Analysis Services Windows
12162425 4341221 CORREÇÃO: Backup VSS Falha na réplica secundária de grupos básicos de disponibilidade no SQL Server 2016 e 2017 Mecanismo SQL Windows
12108225 4339858 CORREÇÃO: Redo paralelo não funciona após você desativar 3459 de sinalizador de rastreamento em uma instância do SQL Server Alta disponibilidade Todas
12061383 4341253 CORREÇÃO: Sys.dm_db_log_info e sys.dm_db_log_stats DMVs podem retornar valores incorretos para o último banco de dados da instância do SQL Server 2016 Mecanismo SQL Windows

Dentre os erros e falhas corrigidas neste cumulative update, as informações apresentadas no KB4341265 destacam uma correção relacionada comportamento apresentado por uma instância do SQL Server 2017 que aparentemente encontra-se travada e exibindo o erro “Non-yielding Scheduler“. 

Outra correção destacada no artigo, se relaciona ao erro “Could not load file or assembly ‘Microsoft.AnalysisServices.AdomdClientUI”.

Vale ressaltar que além de correções relacionadas a erros apresentados por comportamentos apresentadas pelas instância SQL Server 2017, a CU9 também possui correções para os bugs relacionados as DMVs sys.dm_db_log_stats e sys.dm_db_log_info may retornem valores incorretos em determinados momentos de consulta de dados relacionados aos arquivos de log existentes em bancos de dados.

Vale ressaltar que após a atualização desta nova atualização cumulativa, o número do build utilizado pelo Microsoft SQL Server 2017 RTM será alterado para compilação: 14.0.3030.27.

Para realizar o download clique na imagem abaixo:

Fontes e Direitos Autorais: SQL Server Release Services – 19/07/2018.

Dica do Mês – Restrições de Integridade para Banco de Dados


Fala galera, bom dia.

Tudo bem?

Estou um pouco ausente neste mês devido as correrias da minha vida profissional e acadêmica, mas sempre que possível compartilhando com vocês um pouco do meu conhecimento e experiência.

O post de hoje poderia ser diferente dos outros, na sessão Dica do Mês vou apresentar um pouco mais sobre os conceitos básicos de banco de dados voltados para área de modelagem, estou me referindo as chamadas Restrições de Integridade (RI), algo bastante útil e importante quando estamos realizando as definições da estrutura lógica para armazenamento de dados em qualquer banco de dados. Então vamos começar a falar um pouco mais sobre este conceito também criado na década dos anos 70 por Edgar Frank Codd.


Falando um pouco sobre integridade…

A integridade de dados é uma das características essenciais da segurança da informação, e garante que as informações não sofreram alterações que não foram autorizadas ou que são impróprias. Utilizada para assegurar que um documento não é alterado depois de ter sido assinado.

Quando vamos projetar um banco de dados, imaginamos as possíveis formas para que nossa aplicação grave os dados corretamente no banco de dados, mas as vezes, esquecemos de definir, a nível de banco, quais as validações que devem ser feitas para evitar inconsistências nos dados e que, futuramente, se tornariam dores de cabeça.

No contexto de bancos de dados relacional é comum falar de integridade referencial, que tem como objetivo conservar as relações existentes entre tabelas quando algumas linhas são inseridas ou eliminadas.

Restrições de Integridade….

As chamadas RIs possuem o objetivo de garantir a exatidão e a consistência dos dados em uma Banco de dados relacional. Ou seja, garantir que dados representem assertivamente a realidade modelada. A integridade dos dados é tratada nas bases de dados através do conceito de integridade relacional e é garantida pelo próprio SGDB.

Existem vários tipos de restrições de integridade. Codd, inicialmente definiu 2 tipos de restrições, mas na sua segunda versão do modelo relacional ele definiu 5 tipos de restrições de integridade.

Mas antes de conhecer este tipos, vamos entender um pouco o conceito de domínio dos atributos: O domínio indica os possíveis valores de um atributo. A integridade de domínio verifica se os dados são do tipo permitido (alfanumerico, numerico,etc), tamanho do campo, se ele pode ser nulo ou não. Por exemplo, é possível definir que um atributo “idade” de um funcionário é sempre um valor inteiro positivo.

Os cinco tipos de restrições…

Restrição de Chave: Impede que uma chave primária se repita. Um campo chave primária diferencia de forma única os registros (linhas) de uma relação (tabela).

Restrição de Domínio: Impede que uma chave primária receba como valor NULL (nulo).

Integridade de vazio: Verifica se um campo pode ou não receber valor NULL. Sub-item da integridade de domínio.

Integridade referencial: Uma chave estrangeira de uma relação tem que coincidir com uma chave primária da sua tabela “pai” a que a chave estrangeira se refere. Ou seja, não só deve existir o atributo (campo), como também, o valor referenciado.

Integridade definida pelo usuário: Permite definir regras comerciais que não se encaixam em outras categorias de integridade.

Elementos que formam as Restrições de Integridade…

Integridade Semântica: Garante que o dado inserido em uma linha da tabela seja um valor válido. Para esse valor ser válido deve ser do mesmo tipo de dados definido na especificação da coluna na tabela.

Imagine o atributo de uma determinada entidade definido como DATA, por padrão este atributo deverá conter somente dados relativos a DATA. É justamente esta definição que nos permite ter a certeza que no campo DATA_CONTRATACAO só terá datas válidas.

Caso um SGDB permita a inserção de um outro tipo de dado diferente do definido, a integridade semântica será violada. A integridade semântica em um SGDB é aplicada com a utilização de constraints.

Constraints: Pode ser definido resumidamente como uma regra que limita o valor que pode ser inserido, modificado ou eliminado em uma tabela. Na linguagem SQL temos os seguintes tipos de constraints:

  • Constraint de dados;
  • Constraint NOT NULL (não nulo);
  • Constraint única; e
  • Constraint de validação (check constraint).

Constraints de Dados: Esse tipo de constraint pode ser considerado o mais simples e por muitas vezes ignorado como um constraint. Ele é o que delimita o tipo de dado de cada coluna em uma tabela.

Os tipos de informações disponíveis na maioria dos SGDBs existentes pode ser dividia em:

  • Numérico;
  • Alfanumérico ou caracteres;
  • Data e tempo; e
  • Grandes objetos.

Constraints Not Null: O conceito de nulo é utilizado quando uma determinada coluna ou atributo de uma linha na tabela não possui valor ou este valor é desconhecido. Por outro lado, existem colunas / atributo que obrigatoriamente precisam de valor informado.

Por exemplo, em uma tabela chamada FUNCIONARIO, onde estão dados de funcionários, o atributo NUMERO_FUNCIONARIO é obrigatório. Nesse caso é possível utilizar a constraint NOT NULL para garantir que haverá informação nessa coluna.

Importante frisar que NULO é diferente de brancos e zeros. Temos que lembrar também que tanto branco quanto zero são valores válidos e que são levados em conta em funções de coluna, tais como média, somatório, máximo, mínimo. Sendo que o NULO é desconsiderado nessas funções.

Constraints Única (Unique): Reconhecida e tratata como uma regra única que garante e não permite a existência de valores duplicados da mesma coluna ou em um conjunto de colunas na mesma tabela.

Usando o mesmo exemplo da tabela FUNCIONARIO, podemos utilizar uma constraint única na coluna NUMERO_FUNCIONARIO para garantir que dois ou mais funcionários possuam o mesmo número de identificação.

Podemos considerar que a chave primaria (primary key), que será explicada mais adiante, é um tipo de constraint única. Lembrando que uma tabela pode ter apenas uma chave primária, porém diversas constraint únicas.

Constraints de Validação (Check): Esta constraint determina um conjunto de valores permitidos para uma determinada coluna na tabela. Através deste tipo de constraints podemos definir de forma explícita através da linguagem DDL (Data Definition Language) de uma tabela com expressões Booleanas similares a clausula WHERE da linguagem Transact-SQL.

Uma constraint de validação é forçada em qualquer inserção ou atualização da coluna. Caso a inserção ou atualização da coluna não esteja de acordo com a definição da constraint, a mesma não será executada.

Por exemplo, vamos supor que a tabela FUNCIONARIO possua uma coluna SALARIO e que o valor do salário de cada funcionário não possa ser maior que 50.000,00, é possível criar uma constraint para erra regra:

CREATE TABLE FUNCIONARIO

(NUMERO_FUNCIONARIO SMALLINT NOT NULL,

SALARIO DECIMAL (9,2) NOT NULL CHECK SALARIO >= 50.000);

Observações: Uma constraint de validação pode ser muito útil para garantir regras de negócio, pois ela não pode ser sobreposta. Uma vez definida é dada a garantia que a regra será respeitada.

Utilizar esse tipo de integridade torna as suas aplicações mais robustas, consistentes e simples, pois não é necessário controlar as regras dentro do próprio código de programação ou utilizando uma subrotina. Dessa maneira é isolada em apenas um lugar a regra de negócio; e

Havendo a necessidade de mudar alguma regra de negócio, basta apenas alterar a constraint de validação na tabela ao invés de sair alterando códigos e mais códigos de programação uma vez que a mesma regra pode estar replicada em diversos pontos da sua aplicação.

Realizando uma prática…

Após conhecermos um pouco sobre o conceito e elementos que formam as restrições de integridade, vamos então colocar “a mão na massa” ou melhor como eu sempre digo no teclado e construir um simples exemplo de como podemos fazer uso de forma mais coerente e organizada do uso da restrição de integridade em nossas tabelas. Para tal utilizaremos o Bloco de Código 1 apresentado abaixo:

— Bloco de Código 1 — Aplicando o conceito de restrições de integridade —

— Criando o Banco de Dados —
Create Database RI
Go
— Acessando o Banco de Dados —
Use RI
Go
— Criando a Tabela Funcionarios utilizando Constrainst – Not Null, Null, Check, Default e Unique —
Create Table Funcionarios
(Codigo Int Primary Key Identity(1,1),
Nome Varchar(80) Not Null,
Sexo Char(1) Check (Sexo = ‘F’ or Sexo = ‘M’),
RG Int Not Null Unique NonClustered,
CPF Int Not Null Unique NonClustered,
DataNascimento Date Check (DataNascimento >= ‘1950-01-01’),
DataCadastro DateTime Default GetDate(),
Email Varchar(100) Null)
Go
— Criando a Tabela Clientes utilizando Constrainst – Not Null, Null, Check, Default e Unique —
Create Table Clientes
(Codigo Int Identity(1,1),
Nome Varchar(80) Not Null,
Sexo Char(1),
RG Int Not Null,
CPF Int Not Null,
DataNascimento Date,
 DataCadastro DateTime Constraint DF_Clientes_DataCadastro Default GetDate(),
Email Varchar(100) Null
  Constraint PK_Clientes_Codigo Primary Key (Codigo),
  Constraint CK_Clientes_Sexo Check (Sexo = ‘F’ or Sexo = ‘M’),
  Constraint UQ_Clientes_RG Unique NonClustered (RG),
  Constraint UQ_Clientes_CPF Unique NonClustered (CPF),
  Constraint CK_Clientes_DataNascimento Check (DataNascimento >= ‘1950-01-01’))
Go
— Adicionando uma nova Constraint —
Alter Table Clientes
Add Constraint DF_Clientes_Sexo Default ‘M’ for Sexo
Go
— Removendo uma Constraint já existente —
Alter Table Clientes
Drop Constraint CK_Clientes_DataNascimento
Go
— Adicionando uma nova Constraint do tipo Check —
Alter Table Clientes
Add Constraint CK_Clientes_DataNascimento
Check(DataNascimento >=’1900-01-01′)
Go

Perfeito, após executarmos este bloco de código temos nosso ambiente totalmente criado seguindo as definições de restrições de integridade que aplicamos no script.

Você pode estar se perguntando mas o que existe de diferença entre criar uma tabela sem definir o nome dados constraints em comparação com uma tabela que possui o nome das constraints definidas. A resposta para esta sua dúvida será respondida através da Figura 1 apresentada abaixo:

constraints
Figura 1 – Restrições de integridade criadas em cada tabela.

Analisando a Figura 1 podemos notar claramente a diferença, quando definimos um nome para nossas constrainst o Microsoft SQL Server atribui exatamente o nome de definimos no momento da crição da tabela, com isso, teremos mais facilidade para realizar uma manutenção nestes objetos, bem como, toda documentação e apresentação da estrutura do nosso banco de dados será mais limpa e organizada.


 

Sendo assim chegamos ao final de mais uma dica do mês.

O conhecimento técnico é muito importante para qualquer profissional, mas não podemos deixar de lado o conhecimento acadêmico adquirido ao longo dos anos dentro das instituições de ensino.

Este é um ponto fundamental, valorizar e conhecer a diferença entre um bom profissional e o profissional reconhecido e respeitado no mercado de trabalho, está justamente ligado na capacidade do mesmo em saber aliar o conhecimento teórico com o conhecimento prático, como muitos costumam dizer aliar a téoria a prática, sendo este o objetivo deste post.

Espero que você tenha gostado, que as informações e exemplos publicadas possam de alguma maneira ajudar e colaborar com suas atividades diárias, profissionais e ou acadêmicas.

Desejo um forte abraço, agradeço mais uma vez a sua visita.

Até mais.

Utilizando Backup de Filegroup no SQL Server 2008 – Parte IV


Bom dia comunidade,

Estou de volta com mais uma parte da minha série de artigos relacionados a Backup de Filegroup. Neste nossa parte, vou começar a demonstrar como podemos aplicar os backups de filegroup em nosso ambiente. Agradeço a sua visita, tenha uma boa leitura.

Aplicando o Backup de Filegroup

A partir de agora vamos começar a demonstrar como podemos trabalhar com Backup de Filegroups, com base em nosso Banco de Dados SQL. O primeiro passo será a realização de um Backup Database, conforme apresenta a Listagem 7, e ilustrado
através da Figura 8. Este backup full será a base para que nosso ambiente possa ser recuperado em caso de falha e consiste no recurso principal necessário para os processos de restauração de dados, através de um restore de  database, log ou filegroup.

Figura 8. Backup Database SQLMagazine.

Com o backup full realizado, estamos seguros e protegidos contra qualquer eventualidade de falha ou erro em nosso ambiente. Sendo assim, o próximo passo será a realização do tão esperado Backup de Filegroup, onde iremos executar este procedimento para ambos os filegroups, conforme apresenta a Listagem 8.  

Listagem 8. Backup Filegroup – Primary e Secondary

— Bloco 1 —

Backup Database SQL

File = ‘SQL_Dados’,

Filegroup = ‘Primary’

To Disk = ‘C:\SQL\Backup-Primary-SQL.bak’

With Init, NoFormat, Description =’Backup Filegroup Primary’

Go

— Bloco 2 —

Backup Database SQL

File = ‘SQL_Secondary_Dados’,

Filegroup = ‘Secondary’

To Disk = ‘C:\SQL\Backup-Secondary-SQL.bak’

With Init, NoFormat,

Description =’Backup Filegroup Secundário’

Go

Como podemos observar utilizamos o comando Backup Database para realizar o backup do nosso banco de dados e seus respectivos filegroups, para ajudar na entendimento do comando Backup, vou descrever brevemente as opções utilizadas neste
procedimento:
Database: Especifica um backup completo do banco de dados;

File: Especifica o nome do arquivo de dados utilizado no processo de backup;

Filegroup: Especifica o nome do filegroup utilizado no processo de backup;

To Disk: Especifica o caminho fisico em disco rígido, pra o qual o arquivo de backup será armazenado;

Init: Especifica que todos os conjuntos de backup devem ser substituídos, mas preserva o cabeçalho de mídia. Se INIT estiver especificado, qualquer conjunto de backup existente naquele dispositivo será substituído, se as condições permitirem;

NoFormat: Especifica que a operação de backup preserva o cabeçalho da mídia e os conjuntos de backup existentes nos
volumes de mídia usados para esta operação de backup. Esse é o comportamento padrão;

Description: Especifica uma breve descrição para o arquivo de backup, com no máximo 255 caracteres.

O processo de Backup Filegroup é muito simples e prático, ainda mais dependendo do tamanho banco de dados realizado em questão de segundos, como foi o nosso caso. Agora vamos simular uma manipulação desastrosa de objetos, onde nossa principal tabela Produtos, será excluída do nosso ambiente, e através do restauração do Filegroup Primary, iremos recuperar este objeto e todos os seus respectivos dados, conforme apresenta a Listagem 9.

Listagem 9. Recuperando a tabela Produtos através da restauração de Filegroup

— Bloco 1 —

Use Master

Go

Backup Log SQL

To Disk = ‘C:\SQL\Backup-Log-SQL.bak’

With Init, Stats=10,

Description=’Backup Log Database SQL’

Go

Como estamos utilizando o Modelo de Recuperação Completo (Recovery Model Full), torna-se necessário realizar um Backup Log. Este backup tem como finalidade informar ao SQL Server o ponto de liberação para acesso e gravação de dados contidos nos filegroups que compõem nosso banco de dados. Caso este backup não seja restaurado nossos filegroups serão definidos como somente leitura.

— Bloco 2 –

Drop Table Produtos

Agora nossa tabela Produtos foi excluída de nosso ambiente, conforme apresenta a Figura 9. 

Figura 9. Tabela Produtos excluída.

Mas poderemos realizar sua recuperação através do comando Restore, recuperando inicialmente o filegroup Primary e posteriormente liberando os demais filegroups para gravação através do comando Restore Log.

 — Bloco 3 —

Use Master

Go

Restore Database SQL Filegroup = ‘Primary’ From Disk = ‘C:\SQL\Backup-Primary-SQL.bak’

With Partial,  NoRecovery,  Replace

Go

Como iremos realizar a restauração do filegroup Primary e nosso banco de dados possui dois filegroups, será
necessário utilizar a opção Partial, para informar ao SQL Server que a restauração será realizada de forma partial, com base no primeiro filegroup.

A opção NoRecovery, será utilizada para impedir a liberação do banco de dados após seu processo de Restauração. Já a opção Replace, tem como finalidade substituir o conteúdo existem atualmente no banco de dados, pelo conteúdo que esta sendo
restaurado através do Restore.

— Bloco 4 —

Use Mmaster

Go

Restore Log SQL From Disk = ‘C:\SQL\Backup-Log-SQLMagazine.bak’

With Recovery, Replace

Go

Neste outro Restore realizado, informamos o SQL Server para liberar o banco de dados para uso através da opção Recovery, realizando a substituição do conteúdo através da opção Replace.

Pronto nosso filegroup Primary, foi restaurado e nossa tabela Produtos também esta novamente disponível em nosso banco de dados, conforme apresenta a Figura 10.

Figura 10. Tabela Produtos restaurada após restauração do filegroup Primary.

Para verificar se tudo esta certo, podemos realizar uma consulta aos dados armazenados em nossa tabela Produtos, conforme
apresenta a Figura 11.

Figura 11. Consulta aos dados armazenados na tabela Produtos.

Bom mas nem tudo pode ser considerado fácil, aparentemente nosso ambiente esta integro e funcional, mas não é bem assim. Se tentarmos inserir ou consultar dados em uma das tabelas armazenada no filegroup Secondary, recebemos uma mensagem de erro informando que este filegroup encontra-se em offline, conforme apresenta a Figura 12.

Galera, vou encerrar mais esta parte, estamos finalizando este arquivo, nos encontramos nas próximas séries.

Mais uma vez agradeço a sua visita.

Até mais.