Simptomi
Pieņemsim, ka izmantojat Microsoft SQL Server 2012, 2014 vai 2016. Kad dublējat datu bāzi ar Microsoft Azure BLOB krātuves pakalpojuma vietrādi URL, darbība var neizdoties, un jūs saņemsit šādus kļūdas ziņojumus gan klienta pusē, gan SQL Server kļūdu žurnālfailā.
SQL Server klienta kļūda
Msg 3271, līmenis 16, valsts 1, Line rindas numurs% Failā "https://<BlobStorageServerName>. blob.core.windows.net/sqlbackup/<DB_Backup_Name. bak>" dublēšana uz vietrādi URL saņēma izņēmumu no attālā galapunkta. Izņēmuma ziņojums: pamata savienojums tika aizvērts: saņemšanā radās neparedzēta kļūda. Msg 3013, līmenis 16, valsts 1, Line rindas numurs% DUBLĒJUMA datu bāze tiek anormāli izbeigta.
SQL Server kļūdu žurnāls
<DateTime> ======== BackupToUrl Initiated =========
<DateTime> Inputs: Backup = True, PageBlob= True, URI = https://<BlobStorageServerName>.blob.core.windows.net/sqlbackup/<DB_Backup_Name.bak>, Acct= lbtesting2096, Key= KeyValue, FORMAT= False, Instance Name = MSSQLSERVER, DBName = <DB_Name> LogPath = C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log
<DateTime> Process Id: 3668
<DateTime> Time for Initialization = 202.7451 ms
<DateTime> BackupToUrl Client is getting configuration from SqlServr
<DateTime> Time for Handshake and VDI config = 31.2507 ms
<DateTime> Time for Get BlobRef = 15.6263 ms
<DateTime> Time for - EXCEPTION Get Fetchattributes = 45364.4979 ms
<DateTime> An exception occurred during communication with Azure Storage, exception information follows
<DateTime> Exception Info: The underlying connection was closed: An unexpected error occurred on a receive.
<DateTime> Stack: at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteSync[T](StorageCommandBase`1 cmd, IRetryPolicy policy, OperationContext operationContext)
at BackupToUrl.Program.MainInternal(String[] args)
<DateTime> The Active queue had 1 requests until we got a clear error.
Šī kļūda rodas, ja klienta serveris ir iespējojis transporta slāņa drošības (TLS) protokola versiju 1,2 ar šādu reģistru.
Reģistra atslēgas nosaukums:
HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1,2 \ klients Vērtība 0 Nosaukums: iespējots Ierakstiet: REG_DWORD Dati: 0x1
Risinājums
Šī problēma ir novērsta šādos kumulatīvajos SQL Server 2014 un 2016 atjauninājumos:
Kumulatīvais atjauninājums 7 SQL Server 2016 RTM
Katrā jaunajā kumulatīvajā SQL Server atjauninājumā ir iekļauti visi labojumfaili un visi drošības labojumi, kas bija iekļauti iepriekšējā kumulatīvajā atjauninājumā. Skatiet jaunākos kumulatīvos atjauninājumus SQL Server:
SQL Server 2012 risinājums
Šī problēma rodas, ja instalētā .NET Framework ir preference TLS 1,0, lai gan tā atbalsta TLS 1,2.
SQL Server 2012 nav labojumu. Lai atrisinātu šo problēmu SQL Server 2012, lai iespējotu stipru šifrēšanu, varat veikt tālāk norādītās darbības.
-
Reģistra dublēšana
-
Atveriet reģistra redaktoru un pārejiet pie tālāk norādītajām reģistra apakšatslēgām: HKLM\software\Wow6432Node\Microsoft.NETFramework\ un HKLM\software\microsoft.NETFramework\
-
Zem katras šīs atslēgas apakšatslēgas pastāv versiju numuri (piemēram, v 4.5, v 4.5.1). Pievienojiet DWORD vērtību ar nosaukumu SchUseStrongCrypto ar vērtību 1 katrai versijai.
-
Sadaļā HKLM\Software\Microsoft.NetFramework atslēgu nosaukumiem nav jābūt tieši 4,5 vai 4.5.1. Lielākoties tie sāksies no v 2.0 XXX, v 3.0 XXX un v 4.0 XXX. Visām pieejamajām versijām ir jāpievieno DWORD vērtība ar nosaukumu "SchUseStrongCrypto" ar vērtību 1.
-
Atsāknējiet SQL Server datoru.
PiezīmeVarat arī mēģināt instalēt .NET Framework 4,8. Pēc noklusējuma .NET Framework 4,7 un jaunākas versijas ir konfigurētas izmantot TLS 1,2 un atļaut savienojumus, izmantojot TLS 1,1 vai TLS 1,0.
Atsauces
Uzziniet par terminoloģiju, ko Microsoft izmanto, lai aprakstītu programmatūras atjauninājumus.
Statusa
Microsoft ir apstiprinājusi, ka šī problēma pastāv Microsoft produktos, kas ir norādīti sadaļā "attiecas uz".
