ਲੰਮਾ 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';

ਇਤਿਹਾਸ ਹਰ ਕਦਮ ਦਾ ਨਤੀਜਾ ਅਤੇ ਸਮਾਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਜੋ ਇੱਕ ਸਫਲਤਾ-ਝੰਡੇ ਨਾਲੋਂ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਹੈ। ਡੇਟਾ ਬਦਲਣ ਵਾਲੇ ਕੰਮਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਪੜਤਾਲ ਵੀ ਸ਼ਾਮਲ ਕਰੋ: ਕਤਾਰਾਂ ਦੀ ਗਿਣਤੀ, ਚੈੱਕਸਮ ਜਾਂ ਕੰਮ ਵੱਲੋਂ ਲਿਖੀ ਸਥਿਤੀ-ਕਤਾਰ। ਦੋ ਸੁਤੰਤਰ ਰਿਕਾਰਡ ਹੀ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨ, ਅਤੇ ਦਰਜ ਕੀਤਾ ਕੰਮ ਇਤਿਹਾਸ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਪਹਿਲਾ ਹੈ।

ਦੁਬਾਰਾ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਮਿਲਾਨ ਕਰੋ

ਜਦੋਂ ਨਿਰੀਖਣ ਕਨੈਕਸ਼ਨ ਗਾਇਬ ਹੋ ਜਾਵੇ, ਦੂਜਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਰਨ ਲੱਭੋ। ਇਸਦੇ ਕਦਮਾਂ ਦੇ ਨਤੀਜੇ ਪੜ੍ਹੋ ਅਤੇ ਤੈਅ ਕਰੋ ਕਿ ਕੰਮ ਕਮਿਟ ਹੋਇਆ, ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਪੂਰਾ ਹੋਇਆ, ਜਾਂ ਕਦੇ ਸ਼ੁਰੂ ਹੀ ਨਹੀਂ ਹੋਇਆ। ਫਿਰ ਹੀ ਵਰਕਫਲੋ ਵੱਲੋਂ ਪਰਿਭਾਸ਼ਿਤ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਨਿਯਮ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਅੰਨ੍ਹੇਵਾਹ ਦੁਬਾਰਾ ਭੇਜਣਾ ਲੋਡ ਨੂੰ ਦੁੱਗਣਾ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਦੂਜੀ ਵਾਰ ਅੱਧੇ ਰਾਹ ਵਿੱਚ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।

ਸਥਾਈ ਮਾਲਕ ਅਤੇ ਜਾਂਚਯੋਗ ਨਤੀਜਾ ਬਣਾਈ ਰੱਖੋ, ਤਦੋਂ ਥੋੜ੍ਹੀ ਪਹੁੰਚ ਅਸਫਲਤਾ ਅੰਦਾਜ਼ੇ ਦੀ ਬਜਾਏ ਅਸੁਵਿਧਾ ਬਣ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਪੂਰੇ ਡਿਜ਼ਾਈਨ ਦਾ ਟੀਚਾ ਹੈ: ਕੰਮ ਨੂੰ ਉਸ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਧ ਜੀਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੇ ਇਸਦੀ ਮੰਗ ਕੀਤੀ।