ದೀರ್ಘ 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';

ಇತಿಹಾಸವು ಪ್ರತಿ ಹಂತದ ಫಲಿತಾಂಶ ಮತ್ತು ಸಮಯವನ್ನು ತೋರಿಸುತ್ತದೆ, ಇದು ಒಂದೇ ಯಶಸ್ಸಿನ ಬಾವುಟಕ್ಕಿಂತ ಉಪಯುಕ್ತ. ಡೇಟಾವನ್ನು ಬದಲಿಸುವ ಕಾರ್ಯಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಪರಿಶೀಲನೆಯನ್ನೂ ಸೇರಿಸಿ: ಸಾಲುಗಳ ಎಣಿಕೆ, ಚೆಕ್ಸಮ್ ಅಥವಾ ಕೆಲಸ ಬರೆಯುವ ಸ್ಥಿತಿ ಸಾಲು. ಎರಡು ಸ್ವತಂತ್ರ ದಾಖಲೆಗಳೇ ಮರುಪ್ರಯತ್ನವನ್ನು ಸುರಕ್ಷಿತಗೊಳಿಸುತ್ತವೆ, ಮತ್ತು ದಾಖಲಾದ ಕೆಲಸದ ಇತಿಹಾಸ ಅವುಗಳಲ್ಲಿ ಮೊದಲನೆಯದು.

ಮತ್ತೆ ಸಲ್ಲಿಸುವ ಮೊದಲು ಹೊಂದಿಸಿ

ವೀಕ್ಷಣಾ ಸಂಪರ್ಕ ಕಣ್ಮರೆಯಾದಾಗ, ಇನ್ನೊಂದನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಇರುವ ಸರದಿಯನ್ನು ಹುಡುಕಿ. ಅದರ ಹಂತಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಓದಿ ಮತ್ತು ಕೆಲಸ ಬದ್ಧವಾಯಿತೇ, ಭಾಗಶಃ ಪೂರ್ಣಗೊಂಡಿತೇ, ಅಥವಾ ಎಂದೂ ಪ್ರಾರಂಭವಾಗಲಿಲ್ಲವೇ ಎಂದು ನಿರ್ಧರಿಸಿ. ಆಗಷ್ಟೇ ವರ್ಕ್ಫ್ಲೋ ವ್ಯಾಖ್ಯಾನಿಸುವ ಮರುಪ್ರಯತ್ನ ನಿಯಮವನ್ನು ಅನ್ವಯಿಸಿ, ಏಕೆಂದರೆ ಕುರುಡು ಮರುಸಲ್ಲಿಕೆ ಲೋಡ್ ಅನ್ನು ದ್ವಿಗುಣಗೊಳಿಸಬಹುದು ಅಥವಾ ಎರಡನೇ ಬಾರಿ ಅರ್ಧದಾರಿಯಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು.

ಶಾಶ್ವತ ಮಾಲೀಕ ಮತ್ತು ಪರಿಶೀಲಿಸಬಹುದಾದ ಫಲಿತಾಂಶವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ, ಆಗ ಸಣ್ಣ ಪ್ರವೇಶ ವೈಫಲ್ಯವು ಊಹೆಯ ಬದಲು ಅನಾನುಕೂಲವಾಗುತ್ತದೆ. ಇದೇ ಇಡೀ ವಿನ್ಯಾಸದ ಗುರಿ: ಕೆಲಸವು ಅದನ್ನು ಕೇಳಿದ ಸಂಪರ್ಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಬದುಕಬೇಕು.