Kategorie: "Sonstiges"

Cumulative update 3 (CU3) for SQL Server 2017

Hi,

https://support.microsoft.com/en-us/help/4052987

4052987 Cumulative update 3 (CU3) for SQL Server 2017

Seit 4.1.2018 gibt es das Update CU3, das in Zusammenhang mit dem "großen" CPU Patch steht...

Cumulative Update 3 (CU3) for Microsoft SQL Server 2017 was also released in the January 3, 2018, SQL Server Security Bulletin ADV180002. See KB 4058562 for more information. Because of this, you may already have CU3 installed as part of that security release. If you do try to install CU3 after ADV180002, you may receive the following message:

There are no SQL Server instances or shared features that can be updated on this computer

This indicates that CU3 is already installed and that no further action is required.

Siehe auch http://www.insidesql.org/blogs/cmu/sql_server/sql-server-leitfaden 

mfg Klaus

 

SQL Server 2016 / 2017 und SSMS 2017 - Vermischtes

english version at the end of the German part - as usual

Bei meinem derzeitigen Hauptkunden stelle ich gerade Access gebunden auf SQL Server 2017 Express ungebunden (Formulare) um und werde wohl manches direkt mit ADO machen…. Dabei habe ich folgendes (unsortiert) getestet, ich dachte, das interessiert vielleicht…

Voraussetzung: SQL Server 2016 oder besser 2017 (EXPRESS ist OK) sowie das neueste SQL Server Management Studio (derzeit 17.4) Sowie Visual Studio 2015 oder 17 (Community edition ist OK) mit installierten SSDT (SQL Server Data Tools)

Meine Vorgehensweise war: Mit dem SQL Server Migration Assistant 7.6 für Access (Siehe separater Blog-Eintrag hier) die Originaldaten des Kunden in eine eigene (temporäre) xx_IMPORT Datenbank kopiert. Dann mit Visual Studio (2015 oder besser 2017 - Community edition ist OK) und den darauf installierten SQL Server Dtata Tools in einer leeren Kopie dieser Import-Datenbank alle Felder und Tabellen den neuen Anforderungen angepasst (incl. Rowveresion <aka Timestamp> für alle Tabellen) und diese als Grundversion deklariert und gesichert. Danach die Datenbanken verglichen und per Change-Script des SSDT die Daten rüberkopiert. Dieser FÜll-Vorgang ist mit neueren Daten beliebig oft wiederholbar...

--------------------------------------------

Zum Testen der Performance verwende ich den neuen SQL Server 2017 Query Store. Der Query Store ist sehr einfach in der Installation und Bedienung.
Beim Query Store finde ich interessant, dass man den kostenfreien SentryOne Explorer auch dort direkt vom SSMS (17.4) aufrufen und damit verknüpfen kann.
Aber auch die Möglichkeiten, zwei ExcutionPlans direkt visuell zu vergleichen finde ich gut.

Soweit ich das verstanden habe, werden jetzt die Extended Events und das ganze Debug-Geraffel (das mir immer sehr suspekt war und ich nie so richtig genutzt habe) wohl nicht mehr so dringend <wenn überhaupt> benötigt. Was mir fehlt, ist ein Tipp, wie und wann man die Default-Einstellungen des Query Store am besten setzt, da ich keine aktuellen Produktionsdaten (im Zeitverlauf) besitze … Ich denke, dass für kleinere Datenbanken eher ein kürzeres Intervall, aber dafür auch „nur“ eine Woche an Verlaufsdaten zu speichern sinnvoll ist.
Eine sehr gute englischsprachige Einführung in den Query Store findet man hier (https://www.youtube.com/watch?v=HZIkOGDpq3E)

---------------------------------------

Aber auch die neuen Temporal Tables werde ich an zwei Stellen wohl verwenden, da der Kunde schon lange meinte, bei den Artikeln und Kunden hätte er gerne eine Änderungs-Historie… (Zumal die Temporal Tables, wenn man die Einschränkungen beachtet, wirklich sehr einfach zu implementieren und zu benutzen sind)
https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-table-usage-scenarios
Achtung - Drawback für SSMS: im SSMS 2017 ändert sich die rechte Maustaste, wenn eine Tabelle von einer "normalen" in eine "temporal" Tabelle geändert wird.
Deutschsprachiger Deep-Dive Vortag von Uwe (Ricken) dazu - in der üblichen Super-Ricken Qualität:
https://channel9.msdn.com/Events/microsoft-techncial-summit/Technical-Summit-2016/SQL-Server-2016-Temporal-Tables

-----------------------------------------

Zum SQL Server Management Studio (SSMS):
<Ich benutze hier immer die neueste Version, da man mit dem SSMS alle gängigen, früheren SQL Server Versionen bearbeiten kann.>

Beim SSMS nutze ich folgende vom Standard abweichenden Einstellungen:

Tools
  Options
    Designers
    Prevent saving changes that require table re-creation (unchecked)

Tools
  Options
    SQL Server Object Explorer
      All output values increased, output 10,000 instead of 1,000 ... Edit 2,000 instead of 200

Ausgabe in einem seperaten Tab-Fenster :

Tools
  Options
    Query Results
      SQL Server
        Results to Grid
          Display Results in a Separate Tab (checked)
          Switch to Results tab after the query executes (ticked)
        Results to text
          Display Results in a Separate Tab (checked)
          Switch to Results tab after the query executes (ticked)

-------------

SSMS Zusatztools - alle kostenfrei:
SentryOne
Plan Explorer (Aufrufbar direkt aus SSMS - auch zusammen mit dem Query Store)

Redgate
SQL Search

ApexSQL Refaktor
Daraus zwei Funktionen: Formatieren von unformatiertem SQL Code
und
Convert to Code

Convert to Code generiert einen Wrapper um den SQL Code - extrem praktisch für VBA Stored-Procedure Aufrufe

Für den Convert to Code habe ich mir die "Custom language" VBA generiert
Language VBA
Escape Charachter "
Copy code with less than 60 chars as a single line
Code before
Dim sql As String
sql = "

Code after
"

Line terminator
" _
& "

-----------------

Zwei Dinge, die in der Express Edition noch immer fehlen, sind das automatisache Komprimieren von Backups und ein eigener Task-Manager. Der Task-manager von Windows ist ja ein Graus. Es gibt jedoch Powershell Scripte, die die Einrichtung erleichtern. Infos dazu finden sich in meinem SSIS Blog.

-----------------

Bzgl komprimiertem Backup: Vergleichsweise habe ich die gleiche Datenbank einmal unkomprimiert mit der Express Edition gesichert und einmal komprimiert in der Dev-Edition. Interessant war das Ergebnis schon:
AdventureWorks2012 Backup
Unkomprimiert 194.523 KB
7Zip der BAK 24.866 KB

Komprimiert 45.818 KB
7Zip der BAK 42.901 KB
D.h. wenns um den reinen Platz geht, ist unkomprimiert sichern und dann zippen der bessere Weg …

----------- Python ----------

Testweise habe ich gestern erfolgreich ein Python-Script mit der Express Edition getestet. Wenn ich es jetzt noch schaffe, das Launchpad parallel zweimal (auch für die Dev Instanz) zum Laufen zu bringen, dann läuft das auch mit der Dev … (Ich habe bei mir sowohl Developer als auch Express-Edition installiert.)

Launchpad der Instanz muss laufen, Phyton- und R-Support installiert, und External Scripts enabled sein …

-- Python Part 1 - Onte time - Enable External Scripts
sp_configure 'show advanced options', 1
reconfigure with OVERRIDE
reconfigure
GO
sp_configure 'external scripts enabled', 1
reconfigure with OVERRIDE
reconfigure
GO
sp_configure
GO

Danach Dienst neu starten

Was wohl allgemein nicht bekannt ist, wenn du mit dem neuen SSMS im Object Explorer gaaaaanz oben auf den Connect und dort mit der rechten Maustaste auf Restart gehst, dann wird (nach einer separaten Bestätigung in einem extra Fenster) der SQL Server (od. Express) Dienst neu gestartet, ohne dass man extra den Configuration Manager bemühen muss… Finde ich super praktisch.

sp_execute_external_script
@language = N'Python',
@script = N'print("Welcome to my first Python script")'

,,, gibt einem "Welcome ..."  aus

-----------

Neu in der Version SSMS 17.4 ist (rechte Maustaste unter Tasks der Datenbank) ist das sog. „Vulnerability Assessment“ das einem eine Vulnerability-Liste generiert. Naja, für den, der‘s braucht <Achselzuck> …

----------

Da finde ich den seit 17.3 mitgelieferten Import / Export Wizzard denn doch wesentlich praktischer, zumal man da man, im Zusammenspiel mit den Data Tools von Visual Studio (2015 od. 17) aus dem Wizzard ein Script erzeugen und mit VS + SSDT weiterverarbeiten kann. Da man SSIS-Scripts auch unter der Express-Edition ausführen kann, ist das Ganze eine wirklich runde Sache …

----------

PS: Neue Hardware von HP + SQL Server 2017 unter Linux
Absolut sehenswertes 5 Minuten Video von Bob Ward
https://www.youtube.com/watch?v=QElCYYoVA3Q&feature=youtu.be
und der Blog dazu:
https://blogs.technet.microsoft.com/dataplatforminsider/2017/11/29/sql-server-2017-the-worlds-first-enterprise-class-diskless-database/
Und das Rack kostet irgendwas zwischen 5 und 10 k $ - also wirklich „Normalsterblich tauglich“ – beachtlich …
(Die SQL Server Enterprise Lizenz dazu ist <mehr als ?> doppelt so teuer)
Da macht dann das neue SQL Operation Studio so richtig Sinn …


---------------------------------------------
English version
---------------------------------------------

With my current main customer, I am currently working on converting MS Access Backend (bound forms) to SQL Server 2017 Express (unbound forms) and will probably do some things directly with ADO .... I tested the following (unsorted), I thought that might be interesting ...

Prerequisite: SQL Server 2016 or better 2017 (EXPRESS is OK) and the latest SQL Server Management Studio (currently 17.4) as well as Visual Studio 2015 or 17 (Community edition is OK) with SSDT (SQL Server Data Tools) installed

My procedure was: With the SQL Server Migration Assistant 7.6 for Access (see separate blog entry here) the original data of the customer copied into its own (temporary) xx_IMPORT database. Create an empty copy of the _IMPORT DB. Edit this empty database with VS until it suits your needs (including Rowveresion <aka Timestamp> for all tables).
I declared this file as a basic version and made a backup. Then the data is copied over via the change script of the SSDT. This filling process can be repeated as often as desired with newer data ...

-----------------------------------

To test the performance I use the new SQL Server 2017 Query Store. The Query Store is very simple in installation and operation.
I find it interesting, that you can also call the free SentryOne Explorer directly from the SSMS (17.4) and link with the Query Store plans. But I also like the possibilities of visually comparing two ExcutionPlans directly.

As far as I understand it, now the Extended Events and the whole debug rubbish (which was always very suspicious to me and I never really used it) are probably not so urgent <if ever> needed anymore. What I miss is a tip on how and when to best set the default settings of the Query Store, as I have no up-to-date production data (over time) ... I think that for smaller databases rather a shorter interval, but also "only" one week to save historical data makes sense.
A very good English introduction to the Query Store can be found here (https://www.youtube.com/watch?v=HZIkOGDpq3E)

----------------------------------

Also the new Temporal Tables I'll probably use in two places, because the customer asked me to get a change history for articles and customers  ... (Especially since the Temporal Tables, if you consider the restrictions, really very easy to implement and use)

https://docs.microsoft.com/en-us/sql/relational-databases/tables/temporal-table-usage-scenarios
Attention - Drawback for SSMS: in SSMS 2017, the right mouse button changes its behaviour, when a table is changed from a "normal" to a "temporal" table.
German-speaking deep-dive webinar by Uwe (Ricken) in addition - in the usual Super-Ricken quality:
https://channel9.msdn.com/Events/microsoft-techncial-summit/Technical-Summit-2016/SQL-Server-2016-Temporal-Tables

-----------------------------------------------------

To the SQL Server Management Studio (SSMS): <I always use the latest version here, because with the SSMS you can edit all common, earlier SQL Server versions.>

In SSMS, I use the following options, deviating from the standard settings:

Tools
  Options
    Designers
    Prevent saving changes that require table re-creation (unchecked)

Tools
  Options
    SQL Server Object Explorer
      All output values increased, output 10,000 instead of 1,000 ... Edit 2,000 instead of 200

  
For Output in a seperate Tab

Tools
  Options
    Query Results
      SQL Server
        Results to Grid
          Display Results in a Separate Tab (checked)
          Switch to Results tab after the query executes (ticked)
        Results to text
          Display Results in a Separate Tab (checked)
          Switch to Results tab after the query executes (ticked)

SSMS additional tools - all free of charge:
SentryOne
Plan Explorer (can be called directly from SSMS - also together with the Query Store)

Redgate
SQL Search

ApexSQL Refactor
Two functions: Formatting of unformatted SQL code
and
Convert to code

Convert to Code creates a VBA-wrapper for SQL Code which is extrmely useful for SP called from VBA

For the Convert to Code I have generated the "Custom language" VBA
Save VBA
Escape Charachter "
Copy code with less than 60 chars as a single line
Code before
Dim sql As string
sql = "

Code after
"

Line terminator
"_
    & "

-------------------------------------

Two things that are still missing in Express Edition are the automatic compression of backups and a dedicated task manager. The task manager of Windows is a horror. However, there are Powershell scripts that make it easier to set up. Information can be found in my SSIS blog.

Regarding compressed backup: Comparatively, I once backed up the same database uncompressed within the Express Edition and one compressed in the Dev Edition.
The result is rather interesting, i think:
AdventureWorks2012 Backup
Uncompressed 194,523 KB
7Zip of the BAK 24,866 KB

Compressed 45,818 KB
7Zip of the BAK 42.901 KB
So uncompressed backup and zipping it seperately gives a better compression (and frees more space)

----------- Python ----------

As a test, yesterday I successfully tested a Python script with the Express Edition. If I manage to get the Launchpad running twice (also for the Dev instance), then it works with the Dev ...
(I have both Developer and Express Edition installed on my system).

Launchpad for used Instance must be running, Phyton and R support installed, and External Scripts enabled ...

- Python Part 1 - Onte time - Enable External Scripts
sp_configure 'show advanced options', 1
reconfigure with OVERRIDE
reconfigure
GO
sp_configure 'external scripts enabled', 1
reconfigure with OVERRIDE
reconfigure
GO
sp_configure
GO

Then restart the service

What generally is unknown, if you click SSMS in Object Explorer (on top) into the Database-Connect and there click with the right mouse button on Restart, then (after a separate confirmation in an extra window) the SQL Server (or Express ) Service is restarted, without having to open the Configuration Manager extra ... I find it super handy.

sp_execute_external_script
@language = N'Python ',
@script = N'print ("Welcome to my first Python script") '

will show the "Welcome ..."

-----------

New in the version SSMS 17.4 (right mouse click under Tasks of a database) is the so-called "Vulnerability Assessment" which generates a vulnerability list.
Well, for the one who needs it <shrug shoulders> ...

----------

The Import / Export Wizzard however, included since 17.3 is much more practical, especially because it enables you, in conjunction with the Data Tools of Visual Studio (2015 od. 17) from the Wizzard to generate a script and then process it with VS + SSDT. As you can also run SSIS scripts under the Express Edition (as explained in a separate blog), the whole thing runs really smooth  ...

----------

PS: New hardware from HP + SQL Server 2017 on Linux
Absolutely worth seeing 5 minute video of Bob Ward
https://www.youtube.com/watch?v=QElCYYoVA3Q&feature=youtu.be
and the blog about it:
https://blogs.technet.microsoft.com/dataplatforminsider/2017/11/29/sql-server-2017-the-worlds-first-enterprise-class-diskless-database/
Tthe rack costs something between 5 and 10 k $ - so really "normal mortality" - considerable ...
(The SQL Server Enterprise license is <more than?> twice as expensive)
That's where the new SQL Operation Studio makes sense ...

 

 

KleinerTipp zu ConnectionString (ADO / VBA) im SQL Server - Updated

english Version at the end

Ein kleiner Tipp zum (VBA / ADO) Connection-String des SQL Servers (getestet mit: Win10 64bit / Access 2013 32-bit / SQL Server 2017):

' ADOConn.ConnectionString = "Driver={SQL Server};Server=localhost\SQLEXPRESS;Database=Northwind;Trusted_Connection=Yes;APP=MeinName\MeinPC\MyApp1;"
' ADOConn.ConnectionString = "Provider='sqloledb';Data Source='localhost\SQLEXPRESS';Initial Catalog='Northwind';Trusted_Connection=yes;APP=MeinName\MeinPC\MyApp2;"
' ADOConn.ConnectionString = "Provider=SQLNCLI11;Server=localhost\SQLEXPRESS;Database=Northwind;Trusted_Connection=yes;APP=MeinName\MeinPC\MyApp3;"
' ADOConn.ConnectionString = "Driver={SQL Server Native Client 11.0};Server=localhost\SQLEXPRESS;Database=Northwind;Trusted_Connection=Yes;APP=MeinName\MeinPC\MyApp4;"

' ADOConn.ConnectionString = "Driver={SQL Server};Server=localhost\SQLEXPRESS;Database=Northwind;User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp5;"
' ADOConn.ConnectionString = "Provider='sqloledb';Data Source='localhost\SQLEXPRESS';Initial Catalog='Northwind';User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp6;"
' ADOConn.ConnectionString = "Provider=SQLNCLI11;Server=localhost\SQLEXPRESS;Database=Northwind;User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp7;"
' ADOConn.ConnectionString = "Driver={SQL Server Native Client 11.0};Server=localhost\SQLEXPRESS;Database=Northwind;User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp8;"

SELECT App_Name()

abrufen. 

Achtung: Überschreibt den APP-Wert der "normalerweise" übergeben würde.

Idee: Auch wenn man mit "normalisierten" Logins arbeitet, so kann man, wenn man pro User einen individuellen Connection-String zusammenbastelt, diesen an den SQL Server übergeben und man hat dann immer den "richtigen" Computer\Usernamen , so als ob man mit Trusted Connection arbeiten würde. Finde ich praktischer, als jedesmal in der Abfrage den Usernamen explizit übergeben zu müssen ... Zudem kann es einem die Fehlersuche auf dem SQL Server wesentlich erleichtern ...

Funktioniert mit allen oben angegebenen Connectionstrings

------------------------------------------ english Version ------------------------------------------

Small tip for using VBA ADO connection-string for SQL Server: (Tested in Win10 64bit / Access 2013 32-bit / SQL Server 2017)

' ADOConn.ConnectionString = "Driver={SQL Server};Server=localhost\SQLEXPRESS;Database=Northwind;Trusted_Connection=Yes;APP=MeinName\MeinPC\MyApp1;"
' ADOConn.ConnectionString = "Provider='sqloledb';Data Source='localhost\SQLEXPRESS';Initial Catalog='Northwind';Trusted_Connection=yes;APP=MeinName\MeinPC\MyApp2;"
' ADOConn.ConnectionString = "Provider=SQLNCLI11;Server=localhost\SQLEXPRESS;Database=Northwind;Trusted_Connection=yes;APP=MeinName\MeinPC\MyApp3;"
' ADOConn.ConnectionString = "Driver={SQL Server Native Client 11.0};Server=localhost\SQLEXPRESS;Database=Northwind;Trusted_Connection=Yes;APP=MeinName\MeinPC\MyApp4;"

' ADOConn.ConnectionString = "Driver={SQL Server};Server=localhost\SQLEXPRESS;Database=Northwind;User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp5;"
' ADOConn.ConnectionString = "Provider='sqloledb';Data Source='localhost\SQLEXPRESS';Initial Catalog='Northwind';User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp6;"
' ADOConn.ConnectionString = "Provider=SQLNCLI11;Server=localhost\SQLEXPRESS;Database=Northwind;User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp7;"
' ADOConn.ConnectionString = "Driver={SQL Server Native Client 11.0};Server=localhost\SQLEXPRESS;Database=Northwind;User ID=sa;Password=MyPW;APP=MeinName\MeinPC\MyApp8;"

If having a user individual APP=MeinName\MeinPC\MyAppN;

then one can fetch that with

SELECT App_Name()

Pay Attention: Overwrites the "original" APP value (which "normally" would be passed)

 Idea behind: Using an indiviual ADO Connection-String per user with VBA is simpler than passing the computer\user each time as parameter. So one is able to have the same information for "computer\user" even if not working with Trusted_connection but with "normalized" login-strings, without transmitting each time explicit user-name parameter ... Additionally it eases the debugging a lot as you know exactly which user etc ...

Does work with all shown ConnectionStrings 

Maybe helpful ?

SSIS und SQL Server Express

English translation at the end of the german part

Im Gegensatz zu manchen Aussagen ist es durchaus LEGAL möglich, SSIS Pakete mit einer Express-Edition zu managen:

D.h. man entwickelt ein Paket und deployt es auf den SQL Server Express und führt das Paket mittels einer Stored-Procedure aus.

Bei SSIS muss man zwischen Paket-Entwicklung, Paket-Deployment und Paket-Ausführung unterscheiden.

Im Verzeichnis in meinem Onedrive sind im Unterverzeichnis SSIS alle notwendigen Scripte gespeichert
In einem weiteren Unterverzeichnis davon sind weitere wichtige Links zu SSIS und Powershell vorhanden
Da das gesamte Verzeichnis SSIS sehr klein ist, empfielt es sich, das Verzeichnis als Gesamtes downzuloaden
Um das Handling zu erleichtern, habe ich alle scripts mit der zusätzlichen Endung .txt versehen.

 SSIS-Entwicklung

Es werden SSIS-Pakete mit Visual Studio entwickelt. 
Minimalvoraussetzungen zur Entwicklung sind: 

  • Visual Studio 2015 oder besser 2017 (Community Edition reicht)
  • SQL Server Data Tools dazu
  • Hinweis dazu: ssis-designer-is-now-available-for-visual-studio-2017
  • SQL Server (Express oder Developer Edition) <mit den Anwendungsdaten>
  • Hinweis: Der SQL Server muss Version 2012 oder größer sein.
  • SQL Server 2017 Management Studio (kann mit allen gängigen älteren SQL Server Versionen zusammenarbeiten)
  • Das KnowHow, SSIS-Pakete zu erstellen
  • -  Absolut kompletter, 19-teiliger (englischsprachiger) SSIS-Kurs von Wise-Owl in Youtube - Meines Erachtens ein echter 5-Sterne *****-Kurs

SSIS-Deployment

Seit SQL Server 2012 kann man vorhandene SSIS-Pakete im SQL Server in die spezielle Catalog-Datenbank SSISDB deployen 
und von dort aus mit eigenen Stored Procedures starten
Minimalvoraussetzungen dafür sind:

  • SQL Server Management Studio 2017 (installiert die notwendige SSIS IntegrationServices.dll automatisch mit 
  • und kann mit allen gängigen älteren SQL Server Versionen zusammenarbeiten)
  • SQL Server <Express> (Zugriff mit SA Rechten)
  • Hinweis: Der SQL Server muss Version 2012 oder größer sein.
  • Powershell größer gleich Version 4 (Ausführung als Admin)

Doing: 

a) Einmalig: SQL-Script "SQL SQL Server auf CLR enabled setzen.sql" ausführen
da für das folgende Script der Server auf CLR enabled = Yes stehen muss

b) für jedes neue Paket:
Ein Powershell-Script, das einem die Catalog-Datenbank im SQL-Server-Express erzeugt und die Pakete in die Catalog-Datenbank deployt
"PS SSIS Catalog and Project Deployment with PowerShell___Als_Admin_ausführen.ps1" als Admin ausführen
Erklärungen Inline

c) da diese Checkbox bei der Express Edition fehlt:
There is a checkbox when you create an SSIS catalog which says "Enable automatic execution of Integration Services stored procedure at SQL Server startup"
Einmalig: SQL-Script "SQL SET SQL Server Enable automatic execution of SSIS Startup SP.sql" ausführen, um diese Checkbox via SQL auf ON zu setzen

Hilfreich: SQL-Script "SQL SET XP_CommandShell_Ole Automation Procedures_Start.sql" um XP Commandshell zu erlauben (nicht notwendig)
Hilfreich: Ein SQL-Script, das einem hilft, die SPs auszuführen

SSIS-Ausführung

Die in der SSISDB-Datenbank liegenden Pakete werden via Stored Procedures ausgeführt.
Da der SQL Server Express keinen eigenen Scheduler hat, empfiehlt es sich, für automatische Tasks den in Windows eingebauten Taskmanager zu verwenden.
Um automatisch Dinge zu schedulen, bietet sich an, Powershell-scripts im Taskmanager ausführen zu lassen ...
Eine Verknüpfung (auf dem Desktop) zum Taskmanager finde ich hilfreich:

Name: Taskmanager

Ziel: %SYSTEMROOT%\System32\taskschd.msc
Ausführen in: %windir%\System32
Erweitert: Als Administrator ausführen

Hilfreich: Ein SQL-Script, das einem den Status der Ausführung eines Paketes anzeigt
Hilfreich: Ein SQL-Script, das einem hilft, die SPs auszuführen
Hilfreich: Einige Links zum Zusammenspiel mit Scheduler, Powershell und dem SQL Server

 

------------------------------------------------------------------------------------------------

English Version

SSIS and SQL Server Express

Unlike some statements, it is quite possible to manage legally  SSIS packages within an SQL Server Express edition:

You develop a package and deploy it to the SQL Server Express and run the package using a stored procedure.

For SSIS, one generally must distinguish between package development, package deployment, and package execution.

In the directory in my onedrive all necessary scripts are stored in the subdirectory SSIS
In a further subdirectory there are other important links to SSIS and Powershell
As the entire directory SSIS is very small, it is recommended to download the directory as a whole.
For easier handling, all scripts have an additional .txt ending ... 

SSIS Development

SSIS packages are developed with Visual Studio.
Minimum requirements for development are:

  • Visual Studio 2015 or better 2017 (Community Edition is enough)
  • SQL Server Data Tools
  • Note: ssis-designer-is-now-available-for-visual-studio-2017
  • SQL Server (Express or Developer Edition) <with the application data>
  • Note: SQL Server must be version 2012 or larger.
  • SQL Server 2017 Management Studio (can work with all common older versions of SQL Server)
  • The know-how to create SSIS packages
  • - Absolutely complete, 19-part (English language) SSIS course from Wise-Owl in Youtube - In my opinion, a real 5-star ***** course

SSIS Deployment

Beginning with SQL Server 2012, you can deploy existing SSIS packages in SQL Server to the special catalog database named SSISDB
and from there start the packages with own stored procedures
Minimum requirements for this are:

  • SQL Server Management Studio 2017 (automatically installs the necessary SSIS IntegrationServices.dll
  • and can work with all common older versions of SQL Server)
  • SQL Server <Express> (access with SA rights)
  • Note: SQL Server must be of version 2012 or larger.
  • Powershell greater than or equal to version 4 (starting as admin)

Doing:

a) One-time: SQL script "SQL SQL Server set to CLR enabled.sql"
because for the following script the server must be CLR enabled = Yes

(b) for each new package:
A Powershell script that creates the Catalog database in the SQL Server Express and deploys the packages into the Catalog database
"PS SSIS Catalog and Project Deployment with PowerShell ___ As_Admin_Execute.ps1" as Admin
Explanations Inline

c) On larger Editions of SQL Server you have "There is a checkbox when you create an SSIS catalog that says "SQL Server startup" which is missing in Express Edition.
Therefore - One-time (SSISDB already must exist): SQL-Script "SQL SET SQL Server Enable automatic execution of SSIS Startup SP.sql" to set this checkbox to ON via SQL

Helpful: SQL script "SQL SET XP_CommandShell_Ole Automation Procedures_Start.sql" to allow XP Commandshell (not necessary)
Helpful: An SQL script that helps you run the SPs

SSIS execution

The packages located in the SSISDB database are executed via stored procedures.
Because the SQL Server Express does not have its own scheduler, it is recommended to use the task manager built into Windows for automatic tasks.
In order to automatically schedule things, it is recommended to run Powershell scripts in the task manager ...
I find a link (on the desktop) to the task manager helpful:

Name: Taskmanager

Target:% SYSTEMROOT% \ System32 \ taskschd.msc
Run to:% windir% \ System32
Advanced: Run as administrator

Helpful: An SQL script that shows the status of the execution of a package
Helpful: An SQL script that helps you run the SPs
Helpful: Some additional links to explain scheduler, PowerShell and SQLServer

 

 

SQL Server 2017 - Kumulatives Update CU1 verfügbar.

Hi,

David Peter Hansen hat eine beachtliche Liste "SQL SERVER PERFORMANCE TROUBLESHOOTING FREE SCRIPTS AND TOOLS LIST" zusammengetragen.

Der vorletzte Eintrag ist der Eintrag zur Seite Microsoft SQL Server Version List 

Diese zeigt (wenn man weiter runter blättert)  an, dass es für den SQL Server 2017 seit dem 23.10.2017 ein neues kumulatives Update gibt, das einige wichtige Fehler behebt. 

Microsoft hat die Strategie dahingehend geändert, dass es ab der SQL Server Version 2017 keine traditionellen Servicepacks mehr gibt, sondern nur noch "kumulative Updates", wie hier nachzulesen ist.

Daher würde ich dringend empfehlen, diese jeweils nach Erscheinen zu installieren. 

Meines Wissens sind diese Updates nicht in den automatisch installierten Windows-Updates enthalten, müssen also immer "manuell" downgeloaded und  installiert werden.

mfg

Klaus