Доўгая задача SQL: не дайце ёй спыніцца, калі VPN абрываецца

VPN абрываецца праз дваццаць хвілін пасля пачатку перабудовы індэкса, ваш кліент SQL паказвае разарванае злучэнне, і відавочнае пытанне не мае адказу ў гэтай памылцы. Ці завяршыўся аператар, ці адкаціўся, ці працягваў працаваць без вас? Паўторнае падключэнне і паўторная адпраўка — горшы з трох варыянтаў, бо ён ператварае адзін няпэўны вынік у два магчымыя. Перанясіце працу на нешта з устойлівым уладальнікам да наступнага акна.

Што памылка злучэння вам не кажа

Памылка на баку кліента апісвае кліента. Яна паведамляе, што сокет зачынены, а не тое, што сервер зрабіў з транзакцыяй. Аператар можа ўсё яшчэ выконвацца, мог быць зафіксаваны за імгненне да абрыву сувязі або адкочаны, калі яго сеанс быў ачышчаны. Усе тры выпадкі даюць на вашым ноўтбуку адно і тое ж паведамленне.

Толькі стан сервера можа гэта вырашыць. Загляніце туды, перш чым нешта вырашаць.

Перадайце працу ўладальніку на баку сервера

Для працы, якая не патрабуе чалавечага нагляду, няхай хост базы даных валодае выкананнем. SQL Server Agent запускае задачы па запыце або па раскладзе і запісвае кожны запуск, таму жыццёвы цыкл задачы не залежыць ад вашага сеансу VPN. Ідэнтычнасці задачы патрэбныя менавіта тыя правы, якія патрабуе задача, а не поўны інтэрактыўны кантэкст адміністратара. Тады ноўтбук запускае працу і чытае вынікі, замест таго каб быць працэсам, які трымае яе жывой.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Даступнасць Agent залежыць ад рэдакцыі і службы, якія вы разгарнулі. Выкарыстоўвайце механізм, які ваша платформа фактычна прадастаўляе, замест таго каб меркаваць, што гэты ёсць усюды.

Прамежкавы хост побач з базай даных скарачае шлях і варты таго, каб быць, але ён не змяняе пытанне ўладальніцтва. Сеанс усё роўна скончыцца, калі скончыцца сетка. Выкарыстоўвайце яго для назірання, а не як тое, што трымае працу жывой.

Пакіньце запіс, які зможа прачытаць наступны сеанс

Запішыце імя задачы або ідэнтыфікатар, мэтавую базу даных і вынік, які вы чакаеце. Менавіта гэты запіс дазваляе іншаму сеансу або іншаму чалавеку адказаць на пытанне, на якое не змагла памылка. Без яго ў вас застаецца туманнае ўспамінанне пра абнаўленне і ніякай магчымасці праверыць.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

Гісторыя паказвае вынік і час па кожным кроку, што карысней за адзіны сцяг поспеху. Для задач, якія змяняюць даныя, дадайце таксама ўласную праверку праграмы: колькасць радкоў, кантрольную суму або радок стану, запісаны задачай. Менавіта два незалежныя запісы робяць паўтор бяспечным, і запісаная гісторыя задачы — першы з іх.

Зверцеся з данымі перад паўторнай адпраўкай

Калі назіральнае злучэнне знікае, знайдзіце існуючы запуск, перш чым пачынаць новы. Прачытайце вынікі яго крокаў і вырашыце, ці праца была зафіксавана, выканана часткова або не пачыналася. Толькі тады ўжывайце правіла паўтору, якое вызначае працэс, бо сляпая паўторная адпраўка можа дубляваць загрузку або зноў зваліцца на паўдарозе.

Трымайце ўстойлівага ўладальніка і правераны вынік, і кароткі збой доступу стане незручнасцю, а не здагадкай. У гэтым і ўся мэта дызайну: праца павінна перажыць злучэнне, якое яе запытала.