David Barbarin » Linux

Dealing with SQL Server on Linux on WSL2

mikedavem — Mon, 27 Jul 2020 06:53:32 +0000

This is a blog post I intended to write sometime ago … about using SQL Server on Linux on WSL2. For whom already installed it on Windows 10, version 2004, you are already aware it doesn’t come with the support of systemd. Indeed, although it does exist in the file system, systemd is not running. If you intend to use directly SQL Server on WSL2, you need to read this carefully, because installation and management relies precisely on systemd!

First, let’s say if you want to run SQL Server on WSL2 in a supported way, docker containers remain probably the better fit. Podman may be also an alternative but it seems to remain an experimental stuff so far. The interesting point is that some people prefer to use Docker directly on WSL2 whereas other ones prefer to use Docker Desktop for Windows with the integration of WSL2 based engine. The option seems to be available for a few months as shown below:

But this is not the main topic of this blog post. Having interesting discussions with some of my colleagues, we wanted to know if we were able to install directly SQL Server on WSL2 and the good news is we finally managed to do it but at the cost of some (dirty) tricks required to make SQL Server starting / stopping correctly.

Before continuing, let’s precise we did it in a pure experimental and academic way and this is definitely not supported by Microsoft. But before starting my holidays in August, it was something very fun and a good reminder of some Linux concepts …

I did my test with the Ubuntu-18.04 distro in WSL v2.

First step consisted in installing SQL Server in an usual way as per the Microsoft BOL. The installation was done correctly but after running the setup, an error message raised quickly in the last step related to service initialization:

In fact, if you think about it, this message is expected because systemd is not running on WSL2 and the configuration process attempts to initialize the mssql-server service based on systemd. But let’s dig further on the installation process … Referring to how a deb package is made, there exist preinst, postinst, prerm, postrm scripts for mssqlserver deb package located in /var/lib/dpkg/info/:

$ sudo ls -l /var/lib/dpkg/info/mssql-server*
-rwxr-xr-x 1 root root 108 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.config
-rw-r--r-- 1 root root 8579 Jul 26 00:31 /var/lib/dpkg/info/mssql-server.list
-rw-r--r-- 1 root root 11543 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.md5sums
-rwxr-xr-x 1 root root 1436 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.postinst
-rwxr-xr-x 1 root root 289 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.postrm
-rwxr-xr-x 1 root root 1353 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.preinst
-rwxr-xr-x 1 root root 365 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.prerm
-rw-r--r-- 1 root root 72 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.shlibs
-rw-r--r-- 1 root root 305 Jun 16 20:00 /var/lib/dpkg/info/mssql-server.templates
-rw-r--r-- 1 root root 74 Jun 16 20:01 /var/lib/dpkg/info/mssql-server.triggers

My suspicion was those files content references of systemctl commands and yes, there were in preinst/prerm/postins/prerm files:

Well, we found a reasonable explanation of the previous error message at least. At this stage, I would say you can use your new fresh installed SQL Server instance, but it requires to manually start / stop it because there are no systemctl commands to handle it. But thinking about it … we are still using the famous init daemon (PID1) on WSL2 and it works for regular services.

A good alternative could be to rely on init scripts and start-stop-daemon wrapped into LSB-compliant init scripts with:

– At least start, stop, restart, force-reload, and status
– Return Proper exit code
– Document run-time dependencies

LSB provides default set of functions which is in /lib/lsb/init-functions and we can make use of those functions in our Init scripts. The script file is located to /etc/init.d and named mssql-server.

$ sudo ls -l /etc/init.d/mssql*
-rwxr-xr-x 1 root root 1606 Jul 26 22:13 /etc/init.d/mssql-server

Here the content of my mssql-server script file:

#! /bin/sh -e
#
### BEGIN INIT INFO
# Provides: sqlserver
# Required-Start: $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Manages SQL Server instance on Linux
### END INIT INFO

DAEMON="/opt/mssql/bin/sqlservr"
daemon_OPT=""
DAEMONUSER="mssql"
daemon_NAME="sqlservr"

export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/var/opt/mssql

# Check sqlserver is present
if [ ! -x $DAEMON ]; then
log_failure_msg "$DAEMON not present or not executable"
exit 1
fi

# Load init functions
. /lib/lsb/init-functions

d_start () {
log_daemon_msg "Starting system $daemon_NAME Daemon"
start-stop-daemon --background --name $daemon_NAME --start --quiet --chuid $DAEMONUSER --exec $DAEMON --umask 007 -- $DAEMON_OPTS --oknodo
log_end_msg $?
}

d_stop () {
log_daemon_msg "Stopping system $daemon_NAME Daemon"
start-stop-daemon --name $daemon_NAME --stop --retry 5 --quiet --name $daemon_NAME --oknodo
log_end_msg $?
}

case "$1" in

start|stop)
d_${1}
;;

restart|reload|force-reload)
d_stop
d_start
;;

force-stop)
d_stop
;;

status)
status_of_proc "$daemon_NAME" "$DAEMON" "system-wide $daemon_NAME" && exit 0 || exit $?
;;
*)
echo "Usage: /etc/init.d/$daemon_NAME {start|stop|force-stop|restart|reload|force-reload|status}"
exit 1
;;
esac
exit 0

Thus, I was now able to manage with status / start / stop / restart operations:

$ sudo service mssql-server status
/opt/mssql/bin/sqlservr is not running
$ sudo service mssql-server start
Starting system sqlservr Daemon [ OK ]

The SQL Server engine was started successfully, and I can double check with the top command …

… and with a quick connect to my SQL Server instance:

As starting my SQL Server instance, stopping it can be performed with the service command and stop:

$ sudo service mssql-server stop
Stopping system sqlservr Daemon [ OK ]

$ sudo service mssql-server status
/opt/mssql/bin/sqlservr is not running

Generally speaking, there is no concept of runlevel with WSL, so starting automatically the mssql-service with the WSL2 startup can be achieved in different ways with entries in .bashrc file or tricks from github projects (not tested from my side).

Finally, let’s talk about removing SQL Server from WSL2. As a reminder, during the installation / setup we faced an error message related to systemd. We also identified some dependencies to systemd in some dkpg files as shown below:

Similar to the installation step, you will experience the same kind of issue with prerm / postrm files when removing SQL Server. In my case, I had to comment concerned lines in those files to uninstall successfully my SQL Server instance.

Hope this blog post helps!

SQL Server on Linux and new FUA support for XFS filesystem

mikedavem — Mon, 13 Apr 2020 17:34:32 +0000

I wrote a (dbi services) blog post concerning Linux and SQL Server IO behavior changes before and after SQL Server 2017 CU6. Now, I was looking forward seeing some new improvements with Force Unit Access (FUA) that was implemented with Linux XFS enhancements since the Linux Kernel 4.18.

As reminder, SQL Server 2017 CU6 provides added a way to guarantee data durability by using « forced flush » mechanism explained here. To cut the story short, SQL Server has strict storage requirement such as Write Ordering, FUA and things go differently on Linux than Windows to achieve durability. What is FUA and why is it important for SQL Server? From Wikipedia: Force Unit Access (aka FUA) is an I/O write command option that forces written data all the way to stable storage. FUA appeared in the SCSI command set but good news, it was later adopted by other standards over the time. SQL Server relies on it to meet WAL and ACID capabilities.

On the Linux world and before the Kernel 4.18, FUA was handled and optimized only for the filesystem journaling. However, data storage always used the multi-step flush process that could introduce SQL Server IO storage slowness (Issue write to block device for the data + issue block device flush to ensure durability with O_DSYNC).

On the Windows world, installing and using a SQL Server instance assumes you are compliant with the Microsoft storage requirements and therefore the first RTM version shipped on Linux came only with O_DIRECT assuming you already ensure that SQL Server IO are able to be written directly into a non-volatile storage through the kernel, drivers and hardware before the acknowledgement. Forced flush mechanism – based on fdatasync() – was then introduced to address scenarios with no safe DIRECT_IO capabilities.

But referring to the Bob Dorr article, Linux Kernel 4.18 comes with XFS enhancements to handle FUA for data storage and it is obviously of benefit to SQL Server. FUA support is intended to improve write requests by shorten the path of write requests as shown below:

Picture from existing IO workflow on Bob Dorr’s article

This is an interesting improvement for write intensive workload and it seems to be confirmed from the tests performed by Microsoft and Bob Dorr in his article.

Let’s the experiment begins with my lab environment based on a Centos 7 on Hyper-V with an upgraded kernel version: 5.6.3-1.e17.elrepo.x86_64.

$uname -r
5.6.3-1.el7.elrepo.x86_64

$cat /etc/os-release | grep VERSION
VERSION="7 (Core)"
VERSION_ID="7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

Let’s precise that my tests are purely experimental and instead of upgrading the Kernel to a newer version you may directly rely on RHEL 8 based distros which comes with kernel version 4.18 for example.

My lab environment includes 2 separate SSD disks to host the DATA + TLOG database files as follows:

I:\ drive : SQL Data volume (sdb – XFS filesystem)
T:\ drive : SQL TLog volume (sda – XFS filesystem)

The general performance is not so bad

Initially I just dedicated on disk for both SQL DATA and TLOG but I quickly noticed some IO waits (iostats output) leading to make me lunconfident with my test results

Spreading IO on physically separate volumes helped to reduce drastically these phenomena afterwards:

First, I enabled FUA capabilities on Hyper-V side as follows:

Set-VMHardDiskDrive -VMName CENTOS7 -ControllerType SCSI -OverrideCacheAttributes WriteCacheAndFUAEnabled

Get-VMHardDiskDrive -VMName CENTOS7 | `
ft VMName, ControllerType, ControllerLocation, Path, WriteHardeningMethod -AutoSize

Then I checked if FUA is enabled and supported from an OS perspective including sda (TLOG) and sdb (SQL DATA) disks:

$ lsblk -f
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb
└─sdb1 xfs 06910f69-27a3-4711-9093-f8bf80d15d72 /sqldata
sr0
sda
├─sda2 xfs f5a9bded-130f-4642-bd6f-9f27563a4e16 /boot
├─sda3 LVM2_member QsbKEt-28yT-lpfZ-VCbj-v5W5-vnVr-2l7nih
│ ├─centos-swap swap 7eebbb32-cef5-42e9-87c3-7df1a0b79f11 [SWAP]
│ └─centos-root xfs 90f6eb2f-dd39-4bef-a7da-67aa75d1843d /
└─sda1 vfat 7529-979E /boot/efi

$ dmesg | grep sda
[ 1.665478] sd 0:0:0:0: [sda] 83886080 512-byte logical blocks: (42.9 GB/40.0 GiB)
[ 1.665479] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 1.665774] sd 0:0:0:0: [sda] Write Protect is off
[ 1.665775] sd 0:0:0:0: [sda] Mode Sense: 0f 00 10 00
[ 1.670321] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[ 1.683833] sda: sda1 sda2 sda3
[ 1.708938] sd 0:0:0:0: [sda] Attached SCSI disk
[ 5.607914] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)

Finally according to the documentation, I configured the trace flag 3979 and control.alternatewritethrough=0 parameters at startup parameters for my SQL Server instance.

$ /opt/mssql/bin/mssql-conf traceflag 3979 on

$ /opt/mssql/bin/mssql-conf set control.alternatewritethrough 0

$ systemctl restart mssql-server

The first I performed was pretty similar to those in my previous (dbi services) blog post.

CREATE TABLE dummy_test (
id INT IDENTITY,
col1 VARCHAR(2000) DEFAULT REPLICATE('T', 2000)
);

INSERT INTO dummy_test DEFAULT VALUES;
GO 67

For a sake of curiosity, I looked at the corresponding strace output:

$ cat sql_strace_fua.txt
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
78.13 360.618066 61739 5841 2219 futex
6.88 31.731833 1511040 21 15 restart_syscall
3.81 17.592176 130312 135 io_getevents
2.95 13.607314 98604 138 epoll_wait
2.88 13.313667 633984 21 21 rt_sigtimedwait
2.60 11.997925 1333103 9 nanosleep
1.79 8.279781 242 34256 gettid
0.84 3.876021 226 17124 getcpu
0.03 0.138836 347 400 sched_yield
0.01 0.062348 254 245 getrusage
0.01 0.056065 406 138 69 readv
0.01 0.038107 343 111 read
0.01 0.037883 743 51 mmap
0.01 0.037498 180 208 epoll_ctl
0.01 0.035654 517 69 writev
0.01 0.025542 370 69 io_submit
0.00 0.019760 282 70 write
0.00 0.019555 477 41 open
0.00 0.016285 1629 10 rt_sigaction
0.00 0.012359 301 41 close
0.00 0.010069 205 49 munmap
0.00 0.006977 303 23 rt_sigprocmask
0.00 0.006256 153 41 fstat
0.00 0.004646 465 10 10 stat
0.00 0.000860 215 4 madvise
0.00 0.000321 161 2 sched_setaffinity
0.00 0.000295 148 2 set_robust_list
0.00 0.000281 141 2 clone
0.00 0.000236 118 2 sigaltstack
0.00 0.000093 47 2 arch_prctl
0.00 0.000046 23 2 sched_getaffinity
------ ----------- ----------- --------- --------- ----------------
100.00 461.546755 59137 2334 total

… And as I expected, with FUA enabled no fsync() / fdatasync() called anymore and writing to a stable storage is achieved directly by FUA commands. Now iomap_dio_rw() is determining if REQ_FUA can be used and issuing generic_write_sync() is still necessary. To dig further to the IO layer we need to rely to another tool blktrace (mentioned to the Bob Dorr’s article as well).

In my case I got to different pictures of blktrace output between forced flushed mechanism (the default) and FUA oriented IO:

-> With forced flush

34.694734500 14225 18425192 8,16 0 17164 A WS 2048 sqlservr
34.694735000 14225 18425192 8,16 0 17165 Q WS 2048 sqlservr
34.694737000 14225 18425192 8,16 0 17166 X WS 1024 sqlservr
34.694738100 14225 18425192 8,16 0 17167 G WS 1024 sqlservr
34.694739800 14225 18426216 8,16 0 17169 G WS 1024 sqlservr
34.694740900 14225 18425192 8,16 0 17171 D WS 1024 sqlservr
34.694747200 14225 18426216 8,16 0 17174 D WS 1024 sqlservr
34.713665000 14225 0 8,16 0 17175 Q FWS 0 sqlservr
34.713668100 14225 0 8,16 0 17176 G FWS 0 sqlservr

WS (Write Synchronous) is performed but SQL Server still needs to go through the multi-step flush process with the additional FWS (PERFLUSH|WRITE|SYNC).

-> FUA

0.000000000 16305 55106536 8,0 0 1 A WFS 8 sqlservr
0.000000400 16305 57615336 8,0 0 2 A WFS 8 sqlservr
0.000001100 16305 57615336 8,0 0 3 Q WFS 8 sqlservr
0.000005200 16305 57615336 8,0 0 4 G WFS 8 sqlservr
0.001377800 16305 55106544 8,0 0 6 A WFS 16 sqlservr

FWS has disappeared with only WFS commands which are basically REQ_WRITE with the REQ_FUA request

I spent some times to read some interesting discussions in addition to the Bob Dorr’s wonderful article. Here an interesting pointer to a a discussion about REQ_FUA for instance.

But what about performance gain?

I had 2 simple scenarios to play with in order to bring out FUA helpfulness including the harden the dirty pages in the BP with checkpoint process and harden the log buffer to disk during the commit phase. When forced flush method is used, each component relies on additional FlushFileBuffers() function to achieve durability. This event can be easily tracked from an XE session including flush_file_buffers and make_writes_durable events.

First scenario (10K inserts within a transaction and checkpoint)

In this scenario my intention was to stress the checkpoint process with a bunch of buffers and dirty pages to flush to disk when it kicks in.

USE dummy;

SET NOCOUNT ON;
-- Disable checkpoint to control when it will kick in
DBCC TRACEON(3505);
-- Check traceflag
DBCC TRACESTATUS;

DECLARE @i INT = 0;
DECLARE @iteration INT = 0;
DECLARE @start_upd DATETIME;
DECLARE @start_chkpt DATETIME;
DECLARE @end_upd DATETIME;
DECLARE @end_chkpt DATETIME;

TRUNCATE TABLE dummy_test;

WHILE @iteration < 251
BEGIN

SET @start_upd = GETDATE();

BEGIN TRAN;

WHILE @i <= 10000
BEGIN
INSERT INTO dummy_test DEFAULT VALUES;
SET @i += 1;
END

COMMIT TRAN;

SET @end_upd = GETDATE();

SET @i = 0;

SET @start_chkpt = GETDATE();
CHECKPOINT;
SET @end_chkpt = GETDATE();
PRINT 'INS: ' + CAST(DATEDIFF(ms, @start_upd, @end_upd) AS VARCHAR(50)) + ' - CHKPT: ' + CAST(DATEDIFF(ms, @start_chkpt, @end_chkpt) AS VARCHAR(50));

SET @iteration += 1;
END

The result is as follows:

In my case, I noticed ~ 17% of improvement for the checkpoint process and ~7% for the insert transaction including the commit phase with flushing data to the TLog. In parallel, looking at the extended event aggregated output confirms that FUA avoids a lot of additional operations to persist data on disk illustrated by flush_file_buffers and make_writes_durable events.

Second scenario (100x 1 insert within a transaction and checkpoint)

In this scenario, I wanted to stress the log writer by forcing a lot of small transactions to commit. I updated the TSQL code as shown below:

USE dummy;

SET NOCOUNT ON;
-- Disable checkpoint to control when it will kick in
DBCC TRACEON(3505);
-- Check traceflag
DBCC TRACESTATUS;

DECLARE @i INT = 0;
DECLARE @iteration INT = 0;
DECLARE @start_upd DATETIME;
DECLARE @start_chkpt DATETIME;
DECLARE @end_upd DATETIME;
DECLARE @end_chkpt DATETIME;

TRUNCATE TABLE dummy_test;

WHILE @iteration < 251
BEGIN

SET @start_upd = GETDATE();

WHILE @i <= 100
BEGIN
INSERT INTO dummy_test DEFAULT VALUES;
SET @i += 1;
END

SET @end_upd = GETDATE();

SET @i = 0;

SET @start_chkpt = GETDATE();
CHECKPOINT;
SET @end_chkpt = GETDATE();
PRINT 'INS: ' + CAST(DATEDIFF(ms, @start_upd, @end_upd) AS VARCHAR(50)) + ' - CHKPT: ' + CAST(DATEDIFF(ms, @start_chkpt, @end_chkpt) AS VARCHAR(50));

SET @iteration += 1;
END

The new picture is the following:

This time the improvement is definitely more impressive with a decrease of ~80% of the execution time about the INSERT + COMMIT and ~77% concerning the checkpoint phase!!!

Looking at the extended event session confirms the shorten IO path has something to do with it

Well, shortening the IO path and relying directing on initial FUA instructions was definitely a good idea both to join performance and to meet WAL and ACID capabilities. Anyway, I’m glad to see Microsoft to contribute improving to the Linux Kernel!!!

SQL Server sur Docker et réseau bridge

mikedavem — Tue, 20 Feb 2018 12:12:50 +0000

Continuous sur la série des billets à propos de SQL Server sur Docker. Il y a quelques jours, j’étais chez un client qui avait déjà implémenté SQL Server 2017 sur Linux dans des containers. Ce fût évidemment une journée très enrichissante avec beaucoup de retour d’expérience et de feedbacks de sa part. Nous avons beaucoup discuté de scénarii d’architectures.

Le point intéressant ici est que j’ai pu comparer le scénario en place avec celui d’un autre client qui avait implémenté depuis un moment mais d’une façon toute à fait différente.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server sur Docker Swarm

mikedavem — Mon, 12 Feb 2018 17:51:48 +0000

SQL Server 2017 est disponible sur de multiples plateformes: Windows, Linux et Docker. La dernière plateforme fournit des fonctionnalités de containerisation avec setup rapide et sans prérequis spécifiques avant d’exécuter des bases de données SQL Server qui sont probablement la clé du succès pour les développeurs.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Server sur Linux et journalisation

mikedavem — Thu, 25 Jan 2018 07:11:49 +0000

Dans un monde Windows, SQL Server journalise les informations dans le journal des erreurs SQL et dans le journal d’application Windows. Les deux systèmes horodatent automatiquement les événements. Contrairement au journal des erreurs SQL Server, le journal d’événements Windows fournit une image plus globale des événements passés sur le système d’exploitation. Ainsi en fonction des erreurs rencontrées, l’analyse d’un tel journal – que ce soit depuis l’observateur d’éléments Windows ou via le cmdlet PowerShell Get-EventLog – peut être bénéfique pour comprendre si celles-ci sont uniquement liées à SQL Server ou s’il existe une corrélation avec des erreurs provenant du système d’exploitation.

Mais qu’en est-il de SQL Server sur Linux? Evidemment, nous pouvons bénéficier des mêmes technologies de journalisation. Comme sur Windows, SQL Server journalise l’information dans le journal des erreurs SQL Server localisé dans le répertoire /var/opt/mssql/log and dans les différents journaux Linux prévus à cet effet.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

SQL Saturday Toulouse 2017: SQL Server sur Linux – les slides

mikedavem — Tue, 02 Jan 2018 19:10:38 +0000

#SQLSatToulouse a été un bon cru. Premierèment, je voudrais remercier chaleureusement l’équipe organisatrice (@Guss et @Fredg_31) ainsi que les sponsors et participants (sans qui ce qui ce genre d’événement ne serait pas possible).

Comme promis, vous trouverez les slides de ma session « Introduction to SQL Server on Linux for DBAs« . Définitivement un bon moment de partage.

Merci à tous!

David Barbarin
MVP & MCM SQL Server

SQL Server sur Linux: Introduction à DBFS

mikedavem — Tue, 02 Jan 2018 19:03:51 +0000

Il y a quelques mois, Microsoft annonçait 2 outils en lignes de commandes supplémentaires pour SQL Server avec notamment mssql-scripter et DBFS. Le dernier a tout particulièrement attiré mon attention car il expose les données en temps réels depuis les fameuses DMVs sur un pseudo système de fichiers virtuel à la façon Linux procfs.

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server

24 HOP French edition 2017 – Les vidéos de session sont disponibles

mikedavem — Tue, 02 Jan 2018 18:57:43 +0000

La seconde édition française des 24HOP est terminée et il y a eu de très bonnes sessions avec des sujets variées (SQL Server 2017 nouvelles fonctionnalitées, Azure, PowerBI, Haute disponibilité, Linux, Hyper-convergence, Modélisation …).

Si vous n’avez pas pu participé à cet événement, vous avez encore la possibilité de regarder les vidéos des sessions. De mon côté c’était l’occasion de partager avec vous les dernières nouveautés SQL Server haute disponibilité sur Linux.

David Barbarin
MVP & MCM SQL Server

Prochaine édition des 24 HOP 2017 francophone

mikedavem — Tue, 02 Jan 2018 17:36:07 +0000

La prochaine édition du 24 Hours of PASS 2017 edition francophone se déroulera les 29-30 juin prochain.

Pour rappel le format est simple: 24 webinars gratuits répartis sur 2 jours de 07:00 à 18h00 GMT et en Français. La seule obligation: s’inscrire aux sessions auxquelles vous assisterez. Cela vous permettra également de récupérer l’enregistrement vidéo si vous voulez la visionner à nouveau par la suite.

Cette année il y en aura encore pour tous les goûts. Du monitoring, de la performance, de l’Azure, de la BI, du BigData et machine learning, de la modélisation, de la haute disponibilité, de l’open source et des nouveautés concernant la prochaine version de SQL Server!

Pour ma part j’aurai le privilège de présenter une session concernant les nouvelles possibilités en terme de haute disponibilité avec SQL Server dans un monde mixte (Windows et Linux) et un monde “full Linux”.

Au plaisir de vous y retrouver!

David Barbarin
MVP & MCM SQL Server

SQL Server 2017 – Linux et scénarios log shipping

mikedavem — Tue, 02 Jan 2018 17:30:24 +0000

Dans ce billet, nous aborderons la fonctionnalité logshipping disponible depuis SQL Server CTP 2.0. Précisons d’abord que c’est une fonctionnalité HA OS-agnostic et qu’il est possible de créer sa propre solution custom même sous Linux (via des jobs cron par exemple). Mais il s’agit ici de parler de la solution out-of-the-box disponible maintenant sous Linux …

> Lire la suite (en anglais)

David Barbarin
MVP & MCM SQL Server