niedziela, 30 października 2016

SQL Server 2014SP2 - Snapshoty baz danych

Snapshoty pozwalają na zapisanie stanu bazy danych w momencie jego tworzenia. Możemy wykonać snapshot na przykład przed wykonaniem zmian w bazie danych cechujących się ryzykiem - np. aktualizacją struktury bazy danych w związku z nową wersją produktu, który wykorzystuje bazę danych. 

Aby utworzyć snapshot bazy danych:
1. W SQL Server Managament Studio klikamy prawym przyciskiem na interesującą nas bazę danych i wybieramy Proporties, po czym przechodzimy na stronę FILES celem sprawdzenia nazwy pliku danych (w moim przypadku jest to M03).

  
 2.  Aby wykonać snapshot korzystamy z polecenia:

CREATE DATABASE nowy ON
( NAME = M03, FILENAME = 
'C:\Program Files\Microsoft SQL Server\MSSQL12.TESTOWA01\MSSQL\DATA\nowy-snapszot.ss'  )
AS SNAPSHOT OF M03;
GO
gdzie:
  • nowy  - oznacza nazwę snapshostu (wybieramy ją wg uznania, to może być np. data wykonania)
  • NAME = M03 oznacza nazwę pliku bazy danych - jest to wartość ustalona w punkcie 1
  • C:\Program Files\Microsoft SQL Server\MSSQL12.TESTOWA01\MSSQL\DATA\nowy-snapszot.ss - jest to ścieżka pliku, do którego ma zostać zapisany snapshot
  • AS SNAPSHOT OF M03 - M03 jest to nazwa bazy danych, której snapshost chcemy wykonać
 Aby sprawdzić dostępne snapshosty możemy skorzystać z dwóch możliwości:
1. W SQL Server Managament Studio rozwijamy gałąź  Database Snapshots


2.  Korzystamy z widoku sys.databases (tj. select * from sys.databases) w celu określenia database_id bazy danych, której snapshot wykonaliśmy i wykorzystania go w poniższym zapytaniu


select a.name, a.database_id, a.source_database_id, a.create_date
from sys.databases as a
where a.source_database_id is not null
and a.source_database_id='7'


Aby przywrócić bazę danych do stanu, w którym został utworzony snapshot, korzystamy z następującego polecenia:

use [master]
go
RESTORE DATABASE M03 FROM DATABASE_SNAPSHOT = 'nowy'
gdzie M03 to nazwa bazy danych, której snapshost chcemy przywrócić, a nowy to nazwa snapshotu, z którego chcemy skorzystać

Najczęściej zadawane pytania:
Q: Ile miejsca powinniśmy przeznaczyć na snapshot?
A: Snapshot ostatecznie nie powinien zająć więcej miejsca niż baza danych.

Q: Czy zamiast kopii bezpieczeństwa mogę wykonywać snapshot bazy danych?
A: Niezależnie od snapshotów powinniśmy mieć opracowaną i wdrożoną politykę tworzenia kopii bezpieczeństwa baz danych i ich testowania na wypadek awarii. Snapshoty mogą towarzyszyć kopiom, ale nie zastępować ich.

Q: Czy w każdej edycji SQL Server mogę wykonać snapshot bazy danych?
A: Jest to możliwe tylko w edycji Enterprise.

Q: Jak usunąć snapshost bazy danych?
A: Korzystamy z polecenia:

DROP DATABASE nowy ;
gdzie nowy oznacza nazwę snapshotu

SQL Server 2014 SP2 - Dedicated Admin Connection (DAC)

Microsoft SQL Server oferuje specjalny tryb połączeń o nazwie Dedicated Admin Connection (w skrócie DAC), który pozwala nawiązać połączenie do serwera SQL, gdy jest on obciążony. Metoda ta nie powinna być wykorzystywana w trakcie codziennej pracy administracyjnej, a jedynie w sytuacjach wyjątkowych celem bieżącej obsługi problemu z działaniem Microsoft SQL Server uniemożliwiającego jego administrację w tradycyjny sposób.  

Aby skorzystać z DAC z poziomu lokalnej maszyny, uruchamiamy SQL Server Managament Studio i wybieramy z paska narzędziowego u góry Database Engine Query (obok New query).

Następnie w oknie Connect to Database Engine podajemy dane na potrzeby połączenia z instancją SQL Server z tą różnicą, że w polu Server name poprzedzamy nazwę naszego serwera i instancji przedrostkiem ADMIN: (np. ADMIN:SERWER\INSTANCJA01 zamiast SERWER\INSTANCJA01). 


Prawidłowe zalogowanie się w trybie DAC skutkować będzie wywołaniem okna zatytułowanego analogicznie do: SQLQuery1.sql - ADMIN:SLAB01\TESTOWA01.master (FIRMA\Administrator (51)), gdzie słowo ADMIN: wskazuje, iż jest to połączenie do instancji z zastosowaniem DAC


Aby sprawdzić czy jest aktywna obsługa zdalnych połączeń typu DAC, możemy skorzystać z następującego polecenia:

USE [master]
GO
EXEC sp_configure 'remote admin connections'
  
Gdzie w wynikach zwracamy uwagę na wartości config_value i run_value (wartość 1 oznacza włączone)

 
Aby móc nawiązać połączenie typu DAC zdalnie, należy uaktywnić opcję remote admin connections na interesującej nas instancji. Możemy to zrobić korzystając z następującego polecenia:

USE [master]
GO
EXEC sp_configure 'remote admin connections', 1;
GO
RECONFIGURE
GO

Oprócz tego należy wiedzieć, że:
  • SQL Server w celu obsługi DAC wykorzystuje port TCP 1434, o ile jest on dostępny bądź przypisuje dynamicznie port TCP w trakcie uruchamiania silnika bazodanowego
  • Aby możliwe było nawiązanie połączenia DAC powinna być włączona usługa SQL Server Browser

sobota, 22 października 2016

SQL Server 2014 SP2 - eksport danych z użyciem BCP lub import z użyciem BULK INSERT z zachowaniem polskich znaczków

Aby podczas eksportu danych z użyciem BCP do pliku zostały zachowane polskie znaczki (ą, ę, ź, ć) należy zastosować BCP z parametrem -C ACP



W przypadku BULK INSERT należy skorzystać z parametru WITH (CODEPAGE='ACP')




Jeżeli powyższe nie działa, należy wówczas zweryfikować parametr Collation - w moim przypadku jest to Polish_CI_AS.

poniedziałek, 3 października 2016

SQL Server 2014 SP2 - Konwersja bazy danych do bazy contained

SQL Server 2014 SP2 obsługuje bazy danych typu contained. Są one uniezależnione od instancji, dzięki czemu nazywane są bazami przenośnymi (portable), w związku z czym umożliwiają bezproblemowe przenoszenie między instancjami serwera SQL z zachowaniem użytkowników i posiadanych przez nich uprawnień.

W niniejszym w wpisie przedstawiam w jaki sposób utworzyć bazę danych, a następnie dokonać jej migracji do bazy danych typu contained. Na potrzeby tego artykułu korzystam z SQL Server 2014 Enterprise z Service Pack 2 na 64-bitowym systemie Windows Server 2012 R2 w edycji Standard.  Jeżeli chcielibyśmy sprawdzić posiadaną wersję serwera SQL, w tym celu możemy skorzystać z polecenia:

SELECT @@VERSION
którego wynik w moim środowisku wygląda następująco:
Microsoft SQL Server 2014 (SP2) (KB3171021) - 12.0.5000.0 (X64) 
Jun 17 2016 19:14:09 
Copyright (c) Microsoft Corporation
Enterprise Evaluation Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: ) (Hypervisor)
Zaczynamy od utworzenia szkoleniowej bazy danych o roboczej nazwie TEST2OCTOBER2016. Możemy to uczynić za pomocą SQL Server Managament Studio w sposób graficzny bądź używając T-SQL:

CREATE DATABASE [TEST2OCTOBER2016]
 CONTAINMENT = NONE
 ON  PRIMARY 
( NAME = N'TEST2OCTOBER2016', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\TEST2OCTOBER2016.mdf' , SIZE = 5120KB , FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'TEST2OCTOBER2016_log', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA\TEST2OCTOBER2016_log.ldf' , SIZE = 1024KB , FILEGROWTH = 10%)
GO
ALTER DATABASE [TEST2OCTOBER2016] SET COMPATIBILITY_LEVEL = 120
GO
ALTER DATABASE [TEST2OCTOBER2016] SET ANSI_NULL_DEFAULT OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET ANSI_NULLS OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET ANSI_PADDING OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET ANSI_WARNINGS OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET ARITHABORT OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET AUTO_CLOSE OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET AUTO_SHRINK OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET AUTO_CREATE_STATISTICS ON(INCREMENTAL = OFF)
GO
ALTER DATABASE [TEST2OCTOBER2016] SET AUTO_UPDATE_STATISTICS ON 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET CURSOR_CLOSE_ON_COMMIT OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET CURSOR_DEFAULT  GLOBAL 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET CONCAT_NULL_YIELDS_NULL OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET NUMERIC_ROUNDABORT OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET QUOTED_IDENTIFIER OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET RECURSIVE_TRIGGERS OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET  DISABLE_BROKER 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET AUTO_UPDATE_STATISTICS_ASYNC OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET DATE_CORRELATION_OPTIMIZATION OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET PARAMETERIZATION SIMPLE 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET READ_COMMITTED_SNAPSHOT OFF 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET  READ_WRITE 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET RECOVERY FULL 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET  MULTI_USER 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET PAGE_VERIFY CHECKSUM  
GO
ALTER DATABASE [TEST2OCTOBER2016] SET TARGET_RECOVERY_TIME = 0 SECONDS 
GO
ALTER DATABASE [TEST2OCTOBER2016] SET DELAYED_DURABILITY = DISABLED 
GO
USE [TEST2OCTOBER2016]
GO
IF NOT EXISTS (SELECT name FROM sys.filegroups WHERE is_default=1 AND name = N'PRIMARY') ALTER DATABASE [TEST2OCTOBER2016] MODIFY FILEGROUP [PRIMARY] DEFAULT
GO
Tworzymy nowy login typu SQL Server authentication o nazwie october01 z hasłem Pa$$word1. Użytkownikowi october01 przydzielamy członkostwo w rolach public i db_owner na poziomie bazy danych TEST2OCTOBER2016.
USE [master]
GO
CREATE LOGIN [october01] WITH PASSWORD=N'Pa$$word1', DEFAULT_DATABASE=[TEST2OCTOBER2016], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [TEST2OCTOBER2016]
GO
CREATE USER [october01] FOR LOGIN [october01]
GO
USE [TEST2OCTOBER2016]
GO
ALTER ROLE [db_owner] ADD MEMBER [october01]
GO
Tworzymy nowy login typu SQL Server authentication o nazwie october02 z hasłem Pa$$word1. Użytkownikowi october02 przydzielamy członkostwo w roli public na poziomie bazy danych TEST2OCTOBER2016.
USE [master]
GO
CREATE LOGIN [october02] WITH PASSWORD=N'Pa$$word1', DEFAULT_DATABASE=[TEST2OCTOBER2016], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [TEST2OCTOBER2016]
GO
CREATE USER [october02] FOR LOGIN [october02]
GO
W bazie danych TEST2OCTOBER2016 tworzymy dwie tabele: EXAMPLE01 i EXAMPLE02, po czym wypełniamy je danymi.
USE [TEST2OCTOBER2016]
GO
CREATE TABLE EXAMPLE01
(
ID int,
PRODUCT varchar(255)
); 
GO  

USE [TEST2OCTOBER2016]
GO
CREATE TABLE EXAMPLE02
(
ID int,
PRODUCT varchar(255)
); 
GO  

USE [TEST2OCTOBER2016]
GO
INSERT INTO EXAMPLE01 (ID,PRODUCT) VALUES ('1','PIZZA');
INSERT INTO EXAMPLE01 (ID,PRODUCT) VALUES ('2','ROUTERS');
INSERT INTO EXAMPLE01 (ID,PRODUCT) VALUES ('3','BOOKS');
GO

USE [TEST2OCTOBER2016]
GO
INSERT INTO EXAMPLE02 (ID,PRODUCT) VALUES ('1','Wireless led light');
INSERT INTO EXAMPLE02 (ID,PRODUCT) VALUES ('2','Pencil');
INSERT INTO EXAMPLE02 (ID,PRODUCT) VALUES ('3','Markers');
GO
Sprawdzamy, że powyżej opisana operacja odniosła oczekiwany efekt i faktycznie w tabelach EXAMPLE01 i EXAMPLE02 w bazie TEST2OCTOBER2016 znajdują się przykładowe dane.
USE [TEST2OCTOBER2016]
GO
SELECT * FROM EXAMPLE01 

USE [TEST2OCTOBER2016]
GO
SELECT * FROM EXAMPLE02 
Przydzielmy użytkownikowi october02 w bazie danych TEST2OCTOBER2016 prawo do wykonywania polecenia SELECT na tabeli EXAMPLE02.
use [TEST2OCTOBER2016]
GO
GRANT SELECT ON [dbo].[EXAMPLE02] TO [october02]
GO
Podsumowując, aktualnie użytkownik october02 posiada uprawnienie do polecenia SELECT na tabeli EXAMPLE02 i nie posiada takiego prawa w odniesieniu do tabeli EXAMPLE01.

 





Kolejnym krokiem jest włącznie obsługi logowania baz danych typu contained w stosunku do instancji SQL Server. Możemy to uczynić zmieniając wartość parametru "Enable Contained Databases" z False na True na stronie "Advanced" we właściwościach instancji bądź poprzez T-SQL:
EXEC sys.sp_configure N'contained database authentication', N'1'
GO
RECONFIGURE WITH OVERRIDE
GO
Komunikat o treści "Configuration option 'contained database authentication' changed from 0 to 1. Run the RECONFIGURE statement to install." oznacza, że operacja została wykonana pomyślnie.



Kolejną wymaganą czynnością jest zmiana trybu pracy bazy danych na CONTAINMENT (partial) we właściwościach bazy danych na stronie "Options" bądź korzystając z następującego polecenia:
USE [master]
GO
ALTER DATABASE [TEST2OCTOBER2016] SET CONTAINMENT = PARTIAL WITH NO_WAIT
GO



Ostatnim elementem jest dokonanie migracji użytkowników. Służy do tego procedura sp_migrate_user_to_contained. W celu zmigrowania użytkowników october01 i october02 oraz wyłączenia ich na poziomie serwera zastosujemy zastosujemy ją w poniżej przedstawiony sposób.
use [TEST2OCTOBER2016]
GO

sp_migrate_user_to_contained   
@username = N'october01',  
@rename = N'keep_name',  
@disablelogin = N'disable_login' ;  

use [TEST2OCTOBER2016]
GO

sp_migrate_user_to_contained   
@username = N'october02',  
@rename = N'keep_name',  
@disablelogin = N'disable_login' ;  

W chwili obecnej możemy:
  • wykonać backup bazy danych TEST2OCTOBER2016
  • na nowym serwerze / instancji włączyć obsługę uwierzytelniania contained
  • EXEC sys.sp_configure N'contained database authentication', N'1'
    GO
    RECONFIGURE WITH OVERRIDE
    GO
    
  •  odtworzyć bazę danych z kopii na nowej instancji i nawiązać do niej połączenie określając nazwę bazy danych w polu "connect to database" na zakładce "Connection Proporties" w oknie "Connect to server" w SQL Server Managament Studio




Uwagi:
  • procedura  sp_migrate_user_to_contained nie umożliwia migracji loginów bazujących na kontach w Windows, a jedynie loginów wewnętrznego mechanizmu uwierzytelniania SQL Server
  • zastosowana składnia procedury sp_migrate_user_to_contained  powoduje wyłączenie użytkownika w bazie master - zatem użytkownik w celu skorzystania z bazy danych musi podczas połączenia sprecyzować bazę danych, do której chce nawiązać połączenie
  •  pełną składnię procedury sp_migrate_user_to_contained znajdziemy na stronie Microsoft: https://msdn.microsoft.com/en-us/library/ff929275.aspx