Category Archives: SQL Server

Rechten op uitsluitend een secondary database

Posted on by

In log shipping omgevingen bestaat regelmatig de wens om een (service-)account
uitsluitend leesrechten te geven op de secondary database, terwijl dit account
geen toegang mag hebben tot de primary database.
Typische use-cases zijn rapportages, exports of monitoring die bewust buiten
de productieomgeving worden gehouden.

SQL Server Log Shipping leent zich hier goed voor, omdat een log shipping secondary
geen automatische failover kent. Een eventuele promotie van de secondary
naar primary gebeurt altijd handmatig en bewust, wat deze inrichting
goed beheersbaar maakt.

Uitgangspunten

  • Log Shipping is een Disaster Recovery mechanisme, geen High Availability oplossing
  • De secondary database staat in STANDBY / READ ONLY modus
  • Er vindt geen automatische rolwissel plaats tussen primary en secondary
  • Deze inrichting is bedoeld voor leesgeoriënteerde, niet-kritische workloads

Technische achtergrond

Bij SQL Server Log Shipping gelden de volgende technische eigenschappen:

  • Database-objecten en database-rechten worden doorgezet via transaction log restores
  • Logins zijn server-level objecten en worden niet meegenomen in log shipping
  • Toegang wordt bepaald door:
    • de status van de login (enabled / disabled)
    • de aanwezigheid van een database user

Dit onderscheid maakt het mogelijk om toegang functioneel te beperken tot uitsluitend
de secondary database.

De inrichting

Stap 1 – Maak een Active Directory service account aan

Gebruik één vast AD-account dat bedoeld is voor rapportage- of leesdoeleinden.

Stap 2 – Maak de login aan op beide SQL Servers

Maak dezelfde login aan op:

  • De primary SQL Server instance
  • De secondary SQL Server instance

Omdat het om een AD-account gaat, is de SID op beide servers gelijk.

Stap 3 – Maak een database user aan in de primary database

  • Koppel de database user aan de login
  • Geef uitsluitend db_datareader rechten

Deze database-rechten worden via log shipping automatisch doorgezet naar
de secondary database.

Stap 4 – Disable de login op de primary SQL Server

Door de login te disablen op de primary SQL Server:

  • kan het account niet verbinden met de primary instance
  • blijven de database-rechten wel bestaan

Stap 5 – Laat de login enabled op de secondary SQL Server

Op de secondary SQL Server blijft de login enabled, waardoor:

  • verbinding met de secondary database mogelijk is
  • alleen leesacties kunnen worden uitgevoerd

Resultaat

  • Het account heeft leesrechten op de secondary database
  • Het account kan niet verbinden met de primary database
  • Rapportage- en leesprocessen zijn gescheiden van productie
  • De inrichting blijft overzichtelijk en beheersbaar

Beheer en aandachtspunten

Wanneer een log shipping secondary handmatig wordt gepromoveerd tot primary
(bijvoorbeeld in een DR-situatie), is het belangrijk om:

  • de status van de login opnieuw te beoordelen
  • expliciet te bepalen of het account toegang mag behouden

Omdat dit een bewuste beheeractie is, kan dit eenvoudig worden opgenomen
in bestaande DR-procedures.

Conclusie

Binnen een log shipping omgeving is het technisch en operationeel goed
verdedigbaar om een account uitsluitend toegang te geven tot de secondary database
door het combineren van database-rechten met een gecontroleerde login-status.

Deze oplossing past bij de aard van log shipping als DR- en reporting-mechanisme
en biedt een praktische en veilige scheiding tussen productie en leesworkloads,
zonder de complexiteit van Always On Availability Groups.

Belangrijke security update voor Microsoft SQL Server

Posted on by

Microsoft heeft twee belangrijke kwetsbaarheden in de beveiliging binnen Microsoft SQL Server gevonden en deze twee issues met een security update gedicht. Het gaat onder andere om een security update binnen de SQL Server Agent, waarbij met behulp van SQL Injectie een aanvaller sysadmin-rechten op de database server zou kunnen verkrijgen.

Er is bovendien met deze security update een lek binnen linked servers gedicht. SQLTeam.NL adviseert uit performance overwegingen nooit linked servers te gebruiken en data op andere manieren binnen data platformen te verplaatsen; bijvoorbeeld door gebruik van SSIS packages te maken.

De kwetsbaarheden zijn in deze link (in het Engels) beschreven. Het artikel bevat ook de links naar alle downloads voor elke versie van SQL Server. Ik adviseer deze update zo spoedig mogelijk in acceptatie te testen en vervolgens in productie te nemen.

SQL Server query’s op secondaries zijn langzaam

Posted on by

Tijdens één van mijn leertrajecten op SQL Server onderzocht ik het gedrag van query’s op READ ONLY secondaries binnen Always-On clusters. Wat opviel was dat query’s op deze database langzamer draaiden; dus, dezelfde query draait op de primary sneller. Nu gebruik ik in het dagelijks werkleven meer secondary logshipomgevingen, waardoor mijn werk niet direct wordt geraakt, maar als SQL Server Enthousiast werd mijn interesse behoorlijk geprikkeld.

Bij mijn zoektocht op internet, kwam ik gelukkig weer bij Microsoft uit. Dit artikel verklaarde precies de exacte oorzaak van mijn testsituatie.

Hoe zie ik dat het fout gaat?

  • De query voert een index scan uit op een groot gedeelte van een tabel, die een clustered row-store index hebben.
  • De query maakt gebruik van de NOLOCK query hintDe dynamic management view sys.dm_db_index_physical_stats laat een significante fragmentatie van de index zien
  • Loskoppelen van de secondary uit het Always-On Cluster lost de performance kwestie op

Hoe zit dit nu? Wat is de oorzaak?
Op secondary databases binnen een always-on cluster wordt snapshot isolation bij query’s afgewdongen. De optie NOLOCK wordt daarbij genegeerd. Dit zorgt ervoor dat de index scan op volgorde van de index key door SQL Server wordt uitgevoerd Als de clustered index significant gefragmenteerd is, valt SQL Server terug op het lezen van één pagina per IO request. Op de primary database (waar snapshot isolation niet wordt afgedwongen) zal SQL Server nog steeds terugvallen op het lezen van meerdere pagina’s per IO request.

De oplossing?
Om dit probleem voor te blijven, is het verstandig de clustered index van de betrokken tabellen opnieuw op te bouwen. De nieuw opgebouwde indexen zullen dan via de Always-On naar de secondaries worden overgezet, waardoor de query’s net zo snel als op de primary database worden.

De Featured Image komt van deze pagina.

Wijzig Analysis Server van Multidimensional naar Tabular Model of andersom

Posted on by

Jarenlang zijn multi-dimensionale kubussen de standaard geweest. Uw organisatie is er nu klaar voor om tabular models in te zetten. Daarvoor moet de analysis server worden omgezet van een multidimensional instance naar een tabular instance. Hoe werkt dat?

Microsoft beschrijft in deze link dat het omzetten van de DeploymentMode property in het bestand msmdsrv.ini niet wordt ondersteund. In principe zal Microsoft SQL Server Analysis Service opnieuw op de server moeten worden geïnstalleerd, nadat de multidimensional instance is verwijderd, maar…

Het omzetten van de DeploymentMode property in het bestand msmdsrv.ini werkt wél. Voor een test- of acceptatieomgeving of om tabular models tijdelijk te testen is het omzetten van deze eigenschap dus een prima oplossing die veel tijd scheelt. Hoe werkt het precies?

  • Ga met verkenner op de analysis server naar de folder C:\Program Files\Microsoft SQL Server\[uw versie]\OLAP\Config
  • Maak een kopie van het bestand msmdsrv.ini naar bijvoorbeeld de temp-folder
  • Open het bestand in de temp-folder
  • Zoek in het bestand naar DeploymentMode
  • Wijzig de waarde naar behoefte: 0=Multidimensional en 2=Tabular
  • Sla het bestand op
  • Maak een backup van het originele bestand in de SSAS folder
  • Kopieer vervolgens het aangepaste bestand uit de temp-folder naar de SSAS-folder toe
  • Herstart de analysis server
BELANGRIJK: Het is dus nadrukkelijk niet de bedoeling deze werkwijze op een productie-server te gebruiken. Microsoft ondersteunt deze werkwijze gewoon niet.

Fouten in SQL Server Agent taken worden niet via e-mail gestuurd

Posted on by

Wanneer zich fouten voordoen in SQL Agent taken, is het fijn wanneer deze via e-mail worden gedeeld. Bij u blijkt dat een uitdaging en werkt het niet.

  • De SQL Server heeft voldoende rechten om e-mail via de mail-server te kunnen sturen
  • Er is een mail account in Database Mail binnen de SQL Server aangemaakt
  • Er is een profiel voor het mail account binnen Database Mail aangemaakt
  • Een testbericht vanuit Database Mail van de SQL Server komt ook gewoon aan
… en helaas: er komen geen mailberichten van de SQL Server Agent binnen.

De eerste plaats waar u kijkt, is zonder uitzondering de logbestanden! In dit geval dus het actuele logbestand van de SQL Server Agent. De kans is vrij groot dat u in de log de volgende regel tegenkomt: [476] Database Mail is not enabled for agent notifications. Cannot send e-mail to [E-mail ontvangers].

Database Mail moet nog aan de SQL Server Agent worden gekoppeld en dat gaat als volgt:

  • Start SQL Server Management Studio
  • Maak verbinding met de betrokken SQL Server
  • Rechtermuisklik op SQL Server Agent
  • Klik op Properties
  • Klik links in het geopende venster op Alert System
  • Vink Enable mail profile aan
  • Selecteer het juiste Mail system
  • Selecteer de het juiste Mail profile
  • Klik op [OK] om de nieuwe instellingen te bevestigen
Klaar!

Foutmeldingen in transactie logshipping

Posted on by

Ik kom regelmatig situaties tegen waarbij logshipdatabases (=secondaries) niet meer via logshipping wordt bijgewerkt. Meestal zien we dan in de geschiedenis van de LSRestore-job in de SQL Agent van de database server waar de logshipdatabase op draait een melding die aangeeft dat transactielogs niet meer kunnen worden ingelezen omdat ze ‘out-of-sequence’ of ‘too recent’ zijn. Deze situatie wordt meestal door één van onderstaande scenario’s veroorzaakt:

  • Er is een FULL backup van de database gemaakt zonder de optie COPY_ONLY.
  • Het recovery model is aangepast. Het aanpassen van het recovery model wordt in de SQL Server gelogd als Setting database option RECOVERY to SIMPLE for database ‘[naam van de database]’ (zonder blokhaken).
  • Er heeft een RESTORE plaats gevonden waarbij de database in NonRecovery is gezet
  • Er zijn transactielogs van de brondatabase verwijderd of naar een andere locatie gekopieerd. Wanneer deze transactielogs nog ergens zijn te vinden, kan worden volstaan met het plaatsen van de transactielogs in de folder van waaruit de LSRestore-job de transactielogs inleest. Voor de veiligheid worden deze transactielogs uit de bronfolder gekopieerd en niet verplaatst.

De gebruikte query om inzicht te krijgen in uitgevoerde restore jobs is

SELECT
       rh.destination_database_name AS [Database],
       CASE
             WHEN rh.restore_type = 'D' THEN 'Database'
             WHEN rh.restore_type = 'F' THEN 'File'
             WHEN rh.restore_type = 'I' THEN 'Differential'
             WHEN rh.restore_type = 'L' THEN 'Log'
       ELSE rh.restore_type END AS [Restore Type],
       rh.restore_date AS [Restore Date],
       bmf.physical_device_name AS [Source], 
       rf.destination_phys_name AS [Restore File],
       rh.user_name AS [Restored By]
FROM msdb.dbo.restorehistory rh
INNER JOIN msdb.dbo.backupset bs ON rh.backup_set_id = bs.backup_set_id
INNER JOIN msdb.dbo.restorefile rf ON rh.restore_history_id = rf.restore_history_id
INNER JOIN msdb.dbo.backupmediafamily bmf ON bmf.media_set_id = bs.media_set_id
-- WHERE destination_database_name = '[naam van de database]' -- zonder blokhaken
ORDER BY rh.restore_date DESC
GO

De gebruikte query voor inzicht in gemaakte backups is:

SELECT
       s.database_name,
       m.physical_device_name,
       CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,
       CAST(DATEDIFF(second, s.backup_start_date,
       s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,
       s.backup_start_date,
       CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,
       CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,
       CASE s.[type] WHEN 'D' THEN 'Full'
       WHEN 'I' THEN 'Differential'
       WHEN 'L' THEN 'Transaction Log'
       END AS BackupType,
       s.server_name,
       s.recovery_model
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() -- Remove this line for all the database
ORDER BY backup_start_date DESC, backup_finish_date;

In de meeste gevallen dient de logshipdatabse opnieuw te worden opgebouwd. Alleen wanneer de melding ‘too recent’ zich voordoet en de transactielogs die ontbreken zijn nog beschikbaar, kan de logshipdatabase met de ontbrekende transactielogs worden hersteld.

Nieuwe standaard security in Microsoft OLE DB for SQL Server

Posted on by

Microsoft trekt de security-touwtjes aan! Net als in Microsoft SQL Server Management Studio heeft de driver Microsoft OLE DB for SQL Server vanaf versie 19.0.0 nu ook ‘security-by-default’. Is dat écht nieuw? Nee, deze feature zit er al sinds 15 februari 2022 in toen Microsoft versie 19.0.0 lanceerde. Ik liep er echter deze week tijdens één van mijn installaties tegen aan.

Waar wordt Microsoft OLE DB for SQL Server gebruikt?
Multidimensionale kubusdatabases en tabular models maken gebruik van deze driver om verbinding te maken naar de brondatabase van de analysis server objecten.

Is de security-by-default dan verplicht?
Nee, wanneer in de connection string van de driver Use Encryption for Data=Optional wordt toegevoegd, zal de security worden omzeild. Een voorbeeld connection string:
Provider=MSOLEDBSQL19;Data Source=[Database server];Initial Catalog=[Database];Integrated Security=SSPI;Persist Security Info=false;Use Encryption for Data=Optional

Meer informatie
Meer informatie is beschikbaar in de volgende links (in het Engels)

De database msdb groeit uit z’n voegen!

Posted on by

In de msdb database worden veel processen van microsoft vastgelegd, onder andere systeembrede stored procedures en ook logging van de SQL agent en database mail. Ongemerkt groeit deze database heel snel heel hard en zit deze database in no-time op enkele tientallen gigabyte grootte. Bij goed SQL server beheer hoort dat niet. Die groei moet in de perken worden gehouden.

Waardoor groeit msdb
De groei van de msdb database kent vele oorzaken. De oorzaken die de meeste groei veroorzaken zijn:

  • De historie van SQL agent jobs
  • De logs van database mail
  • De logs van backups
  • De logs van logshipping procedures

Wat kunnen we eraan doen?
Wanneer u nog geen onderhoud op de msdb database heeft gepleegd, is het handig om eerst de volgende punten vast te stellen:

  • Hoe groot is de msdb database nu?
  • Hoeveel van die ruimte is er al vrij?
  • Hoe groot is msdb database op de storage?
  • Wat zijn mijn grootste tabellen in de database?

Het vast stellen van de bovenstaande punten kan het makkelijkst via SQL Server Management Studio. Door met de rechtermuis klik op de msdb database te klikken, kan er voor Reports worden gekozen. De relevante rapporten zijn Disk Usage en Disk Usage by Table. Dit geeft een goed beeld van de database. Wanneer de database groter dan 5GB is, wijst dat al op excessieve historische logging. Per tabel kan vervolgens worden gekeken hoeveel records er in de tabel zitten en hoeveel ruimte die tabel in neemt. Met onderstaande query kan bijvoorbeeld worden gekeken hoeveel stappen er per SQL agent job zijn gedraaid in het verleden.

SELECT
	sj.name			AS [SQL Server Agent job],
	count(sjh.step_name)	AS [Aantal stappen in de historie]
FROM dbo.sysjobhistory sjh WITH (NOLOCK)
JOIN dbo.sysjobs sj ON sjh.job_id = sj.job_id
GROUP BY sj.name
ORDER BY sj.name;
[/code>]

<strong>Opschonen historische SQL agent jobs</strong>
Voor het opschonen van historische SQL agent jobs wordt de stored procedure <em>sp_purge_jobhistory</em> gebruikt. Deze stored procedure kan de hele historie van één job opruimen of de historie van alle jobs tot en met een bepaalde datum; of een combinatie hiervan. Globaal kan daar onderstaande query voor worden gebruikt
[code language="sql"]
DECLARE @Peildatum datetime = (SELECT DATEADD(MONTH,-1,GETDATE()))
EXECUTE [msdb].[dbo].[sp_purge_jobhistory]
--	@job_name = 'LSRestore_CS-DT1712014_HiX62_Support',
	@oldest_date = @Peildatum

Opschonen database mail
Voor het opschonen van database mail worden de stored procedures sysmail_delete_log_sp en sysmail_delete_mailitems_sp gebruikt. Voorbeeld query:

DECLARE @Peildatum datetime = (SELECT DATEADD(MONTH,-1,GETDATE()))
EXECUTE sysmail_delete_log_sp @logged_before = @Peildatum
EXECUTE sysmail_delete_mailitems_sp @sent_before = @Peildatum

Opruimen van de logshipping historie
Voor het opschonen van historische backup data wordt de stored procedure sp_delete_backuphistory gebruikt. Voorbeeld query:

DECLARE @Peildatum datetime = (SELECT DATEADD(MONTH,-1,GETDATE()))
EXECUTE sp_delete_backuphistory @oldest_date = @Peildatum

Opruimen van de logshipping historie
Voor het opschonen van historische logshipping data wordt de stored procedure sp_cleanup_log_shipping_history gebruikt.
LET OP: deze stored procedure draait in de master database! Voorbeeld query:

DECLARE @database nvarchar(100)
DECLARE @agent_id nvarchar(100)
DECLARE @agent_type int
DECLARE @NumberOfRecords int

DECLARE agent_cursor CURSOR FOR
	SELECT DISTINCT
		database_name,
		agent_id,
		agent_type,
		COUNT(*) AS NumberOfRecords
	FROM msdb.dbo.log_shipping_monitor_history_detail
	GROUP BY database_name,agent_id,agent_type
--	ORDER BY database_name, agent_id, agent_type

OPEN agent_cursor
FETCH NEXT FROM agent_cursor
INTO @database, @agent_id, @agent_type, @NumberOfRecords

IF @@FETCH_STATUS <> 0
PRINT 'No records'

WHILE @@FETCH_STATUS = 0
BEGIN
execute master.dbo.sp_cleanup_log_shipping_history 
	@agent_id = @agent_id,
	@agent_type = @agent_type;
	FETCH NEXT FROM agent_cursor
	INTO @database, @agent_id, @agent_type, @NumberOfRecords
END

CLOSE agent_cursor
DEALLOCATE agent_cursor

En dan…? De msdb database is nog steeds niet kleiner geworden (op de storage)
Dat klopt! Verwijderen van data uit tabellen zorgt er alleen maar voor dat er ruimte binnen de database vrijkomt, die dan eerst weer hergebruikt wordt. Met de functie SHRINKFILE kan de database ook op de storage kleiner worden gemaakt. De meningen zijn erg verdeeld of het gebruik van de functie SHRINKFILE wél of niet verstandig is. Deze discussie moet u binnen uw eigen organisatie voeren. Ik leg u in deze bijdrage alleen uit, hoe de functie wordt gebruikt. De query’s:

-- We gaan naar de msdb database
USE msdb;
GO

-- We verkleinen eerst de data file
DBCC SHRINKFILE (N'MSDBData' , 500);
GO

-- We verkleinen dan de log file
DBCC SHRINKFILE (N'MSDBLog' , 200);
GO

-- Daarna is het verstandig de indexen opnieuw op te bouwen
EXEC sp_MSforeachtable @command1="print '?' DBCC DBREINDEX ('?', ' ', 80)";
GO

Het opnieuw indexeren van de tabellen is een belangrijk onderdeel van de procedure om ervoor te zorgen dat eventuele fragmentatie van de database tabellen wordt tegen gegaan.

Nu is de msdb database weer behapbaar. Om dit zo te houden, is mijn advies om alle opruimquery’s in de SQL agent op te nemen en de opruimacties maandelijks uit te voeren. Dat zou uw msdb database in topconditie moeten houden.

SSAS Analysis Server melding Multi-dimensional database is not using latest encryption schema.

Posted on by

Bij het uitrollen van een multi-dimensionale kubussolution krijgt u de melding An error has occurred, please contact your administrator \nErrors in the metadata manager. Multi-dimensional database [kubusdatabase] is not using latest encryption schema. Please create a backup file and restore DB from backup file with the option EnsureProperEncryption to upgrade to the latest encryption..

Dit is een nieuwe functionaliteit in SQL Server 2022. Eenmalig dient er bij deze melding een backup te worden gemaakt van de kubusdatabase en dient deze backup te worden terug gezet waarbij de optie ‘EnsureProperEncryption’ op ‘True’ staat. Is dat eenmaal gebeurt, dan kunnen toekomstige updates van deze kubussolution weer normaal worden uitgerold zonder dat de kubussolution hoeft te worden verwijderd.

Link: Microsoft pagina’s in het Engels die van toepassing zijn.

De LSAlert op de logship database server geeft onterecht een foutmelding!

Posted on by

Het volgende scenario doet zich op de SQL Server database server voor waar de logship database op staat:

  • De LSAlert job geeft aan dat de logship database niet is bijgewerkt en ‘out-of-sync’ is
  • De LSRestore job geeft een groen vinkje om aan te geven dat die job goed heeft gelopen
  • De logship database is bijgewerkt
  • Recente data uit de brondatabase is ook in de logship database zichtbaar en beschikbaar

Maar … de logship database staat op een SQL Server versie die lager is dan de brondatabase. Bijvoorbeeld de logship database draait op SQL Server versie 2016 en de brondatabase draait (al) op SQL Server versie 2022.

Dit kan tot problemen leiden, omdat de database structuur van systeem databases (zoals bijvoorbeeld msdb) waar SQL Server logging naar toe schrijft een andere structuur hebben (bijvoorbeeld nieuwe velden in systeemtabellen of velden die naar andere systeemtabellen zijn verplaatst). Het zou dan kunnen dat de LSRestore job dan gegevens probeert weg te schrijven die in de nieuwere versie van SQL Server niet meer van toepassing zijn of zijn verplaatst.

Valt dit dan nergens op? Tot nu toe heeft SQLTeam een foutmelding in de schijnbaar goed afgeronde LSRestore job gevonden. Namelijk de foutmelding:

*** Error: Could not log history/error message.(Microsoft.SqlServer.Management.LogShipping) ***
*** Error: Failed to convert parameter value from a SqlGuid to a String.(System.Data) ***
*** Error: Object must implement IConvertible.(mscorlib) ***

Het niet kunnen wegschrijven van log historie en foutmeldingen uit bovenstaande melding. Triggert de LSAlert job die van deze logging gebruik maakt om te kijken of een logship database is bijgewerkt. Hoewel de melding uit de LSAlert job dus inderdaad onterecht is, is dat in deze situatie goed te verklaren. Bovenstaande foutmelding doet zich voor wanneer de logship database op een lagere versie draait dan de brondatabase.

Onderstaande foutmelding doet zich voor wanneer de logship database op een hogere versie van SQL Server staat dan de brondatabase.

2024-07-23 03:25:00.87 *** Error: An error occurred restoring the database access mode.(Microsoft.SqlServer.Management.LogShipping) ***
2024-07-23 03:25:00.89 *** Error: Alter failed for Database '[Naam van de logship database]'. (Microsoft.SqlServer.Smo) ***
2024-07-23 03:25:00.89 *** Error: An exception occurred while executing a Transact-SQL statement or batch.(Microsoft.SqlServer.ConnectionInfo) ***
2024-07-23 03:25:00.89 *** Error: Database '[Naam van de logship database]' cannot be opened. It is in the middle of a restore.(.Net SqlClient Data Provider) ***
2024-07-23 03:25:00.92 *** Error: Could not apply log backup file '[Naam en locatie van de transactielog.trn]' to secondary database '[Naam van de logship database]'.(Microsoft.SqlServer.Management.LogShipping) ***
2024-07-23 03:25:00.92 *** Error: This backup cannot be restored using WITH STANDBY because a database upgrade is needed. Reissue the RESTORE without WITH STANDBY.
RESTORE LOG is terminating abnormally.(.Net SqlClient Data Provider) ***

Advies
Zorg ervoor dat de SQL versies van de brondatabase (primary) en de logship databases van die brondatabase(s) (secondary of secondaries) altijd gelijk aan elkaar is om dit soort situaties te voorkomen.