VPN ಕಡಿತದ ನಂತರ SQL Server ನಿಂದ Oracle ಗೆ ಲೋಡ್ ಅನ್ನು ಮರುಪ್ರಾಪ್ತಿ ಮಾಡಿ
VPN ಕಡಿತವಾದಾಗ ಕರೆಮಾಡುವವರಿಗೆ Oracle ನಲ್ಲಿ commit ಪೂರ್ಣಗೊಂಡಿದೆಯೇ ಎಂಬ ಖಚಿತತೆ ಇರುವುದಿಲ್ಲ. ಶಾಶ್ವತ ಬ್ಯಾಚ್ ID ಎಕ್ಸ್ಟ್ರಾಕ್ಟ್, ಅಪ್ಲೈ ಮತ್ತು ರಿಕನ್ಸೈಲ್ ಪ್ರಶ್ನೆಗಳಿಗೆ ಒಂದೊಂದಾಗಿ ಉತ್ತರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
VPN ಕಡಿತವಾದಾಗ ಡೇಟಾಬೇಸ್-ನಿಂದ-ಡೇಟಾಬೇಸ್ಗೆ ವರ್ಗಾವಣೆ ಸಾಯುತ್ತದೆ, ಮತ್ತು «ಮತ್ತೊಮ್ಮೆ ಚಲಾಯಿಸು» ಒಂದು ಮರುಪ್ರಾಪ್ತಿ ಯೋಜನೆ ಅಲ್ಲ. ಮೂಲದ ಎಕ್ಸ್ಟ್ರಾಕ್ಷನ್ ಪೂರ್ಣಗೊಂಡಿರಬಹುದು, ಗುರಿಯು ಈಗಾಗಲೇ commit ಮಾಡಿರಬಹುದು, ಅಥವಾ ಉತ್ತರವು ಹಿಂತಿರುಗುವ ದಾರಿಯಲ್ಲಿ ಸುಮ್ಮನೆ ಕಳೆದುಹೋಗಿರಬಹುದು. ಈ ಮೂರು ಸ್ಥಿತಿಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ಕ್ರಮಗಳು ಬೇಕು, ಮತ್ತು «ದೋಷ» ಮಾತ್ರ ತಿಳಿದಿರುವ ಕ್ಲೈಂಟ್ ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾರದು.
ಪರಿಹಾರವು ವಾಸ್ತುಶಿಲ್ಪದ್ದಾಗಿದೆ: ಪ್ರತಿ ರನ್ಗೆ ಶಾಶ್ವತ ಬ್ಯಾಚ್ ಗುರುತನ್ನು ನೀಡಿ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಊಹಿಸಲು ಬಿಡುವ ಬದಲು ಡೇಟಾಬೇಸ್ಗಳು ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲಿ.
ಡೇಟಾಬೇಸ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ
SQL Server ಮತ್ತು Oracle ಎರಡೂ ಒಂದು ವಹಿವಾಟಿನ ಒಳಗೆ ಪರಮಾಣುತೆಯನ್ನು ನೀಡುತ್ತವೆ. ಎರಡರ ನಡುವೆ ಪರಮಾಣುತೆಯನ್ನು ಯಾವುದೂ ನೀಡುವುದಿಲ್ಲ. ಕಳೆದುಹೋದ ಸಂಪರ್ಕ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹಾಳುಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಕೈಯಿಂದ ರೋಲ್ಬ್ಯಾಕ್ ಮಾಡಲು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಸರ್ವರ್ ನಿಮ್ಮಿಲ್ಲದೆ ತನ್ನ ವಹಿವಾಟನ್ನು ಸ್ವತಃ ಪರಿಹರಿಸುತ್ತದೆ. ಮುರಿಯುವುದು ಕರೆಮಾಡುವವರ ಫಲಿತಾಂಶದ ಜ್ಞಾನ.
ಪ್ರತ್ಯೇಕವಾಗಿ commit ಎಂದರೆ ಪ್ರತ್ಯೇಕವಾಗಿ commit. ಎರಡೂ ಸಂಪರ್ಕಗಳನ್ನು ಹೊತ್ತೊಯ್ಯುವ VPN ಎರಡು commit ಅನ್ನು ಒಂದೇ ಕೆಲಸದ ಘಟಕಕ್ಕೆ ವಿಲೀನಗೊಳಿಸುವುದಿಲ್ಲ.
ನೀವು ಎಂದೂ ಕೇಳದ commit
ಒಂದು ವೈಫಲ್ಯ ವಿಧಾನವು ಮುಗ್ಧ ಮರುಪ್ರಯತ್ನ ತರ್ಕವನ್ನು ಶಿಕ್ಷಿಸುತ್ತದೆ: ಸರ್ವರ್ commit ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸ್ವೀಕೃತಿ ಎಂದೂ ಕರೆಮಾಡುವವರನ್ನು ತಲುಪುವುದಿಲ್ಲ. Oracle ಇದನ್ನು ಅಜ್ಞಾತ-ಫಲಿತಾಂಶ ಸಮಸ್ಯೆ ಎಂದು ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕಾಗಿ ವಹಿವಾಟು ದಾಖಲಾತಿಯಲ್ಲಿ Transaction Guard ಒದಗಿಸುತ್ತದೆ. ಸಂವಹನ ದೋಷವು ಕಳುಹಿಸಿದ commit ವಿಫಲವಾಯಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸಾಕ್ಷ್ಯವಾಗಿ ಪರಿಗಣಿಸುವುದೇ ಬ್ಯಾಚ್ ಎರಡು ಬಾರಿ ಪೋಸ್ಟ್ ಆಗುವ ದಾರಿ. ಈ ವ್ಯತ್ಯಾಸವು ಮರುಪ್ರಯತ್ನ ಮಾರ್ಗದಲ್ಲಿ ಅತ್ಯಂತ ಮುಖ್ಯ, ಅಲ್ಲಿ ನಿರ್ವಾಹಕನಿಗೆ ದೋಷ ಸಂದೇಶವಿದೆ ಮತ್ತು ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಲು ಬೇರೆ ಯಾವುದೇ ಸಂಕೇತವಿಲ್ಲ.
ಆದ್ದರಿಂದ ಮರುಪ್ರಾಪ್ತಿ ಹಂತವು ಫಲಿತಾಂಶವನ್ನು ದೋಷ ಪಠ್ಯದಿಂದ ಊಹಿಸುವ ಬದಲು ಗುರಿಯಿಂದ ಓದಬೇಕು.
ವರ್ಗಾವಣೆಗೆ ಬ್ಯಾಚ್ ಗುರುತನ್ನು ನೀಡಿ
ಪ್ರತಿ ರನ್ಗೆ ಬದಲಾಗದ ಬ್ಯಾಚ್ ID ಸಿಗುತ್ತದೆ, ಮತ್ತು ಗುರಿಯು ಆ ID ಯೊಂದಿಗೆ ಏನು ಮಾಡಿತು ಎಂಬುದನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಜೀವನಚಕ್ರವು ನಾಲ್ಕು ಹಂತಗಳನ್ನು ಹೊಂದಿದೆ, ಮತ್ತು ಮಾರಾಟಗಾರರು ಯಾರೇ ಆಗಿರಲಿ ಅದು ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ:
- ಎಕ್ಸ್ಟ್ರಾಕ್ಟ್ ದಾಖಲಾದ ಸ್ಕೀಮಾ ಮತ್ತು ಮಿತಿಯೊಂದಿಗೆ ಗುರುತಿಸಲಾದ, ಬದಲಾಗದ ಮೂಲ ಬ್ಯಾಚ್.
- ವರ್ಗಾಯಿಸಿ ಅದನ್ನು ಗುರಿಯ ಸ್ಟೇಜಿಂಗ್ ಪ್ರದೇಶಕ್ಕೆ, ಮತ್ತು ಸಿದ್ಧ ಎಂದು ಘೋಷಿಸುವ ಮೊದಲು ಅಪೂರ್ಣ ಅಥವಾ ವಿರೋಧಾತ್ಮಕ ವಿಷಯವನ್ನು ಪತ್ತೆ ಮಾಡಿ.
- ಅನ್ವಯಿಸಿ ಗುರಿಯ ಸ್ವಂತ ವಿಶಿಷ್ಟತೆ ಅಥವಾ ಲಾಕಿಂಗ್ ನಿಯಮಗಳ ಅಡಿಯಲ್ಲಿ, ಮತ್ತು ಅದೇ ಸ್ಥಳೀಯ ವಹಿವಾಟಿನಲ್ಲಿ ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು ದಾಖಲಿಸಿ.
- ರಿಕನ್ಸೈಲ್ ಶಾಶ್ವತ ಫಲಿತಾಂಶವನ್ನು ಬೆಂಬಲಿತ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ, ಸ್ವೀಕೃತಿ ಅಥವಾ ಮರುಪ್ರಯತ್ನದ ಮೊದಲು.
ಮರುಪ್ರಯತ್ನಗಳು ಅದೇ ID ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುತ್ತವೆ. ಪ್ರತಿ ಪ್ರಯತ್ನಕ್ಕೆ ಹೊಸ ID ನೀವು ಈಗಷ್ಟೇ ನಿರ್ಮಿಸಿದ ನಕಲು ತಡೆಯನ್ನು ಹಾಳುಮಾಡುತ್ತದೆ, ಇದು ಮರುಪ್ರಯತ್ನ ರ್ಯಾಪರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಒಂದನ್ನು ಉತ್ಪಾದಿಸುವವರೆಗೆ ಸ್ಪಷ್ಟವೆನಿಸುತ್ತದೆ.
ID ನಿಮಗೆ ನಂತರ ರಿಕನ್ಸೈಲ್ ಮಾಡಲು ಏನನ್ನಾದರೂ ನೀಡುತ್ತದೆ, ಕ್ಲೈಂಟ್ ಪ್ರಕ್ರಿಯೆ ಬಹಳ ಹಿಂದೆಯೇ ಮಾಯವಾದ ನಂತರವೂ.
ಬ್ಯಾಚ್ ಅನ್ನು ಕ್ಲೈಮ್ ಮಾಡಿ, ನಂತರ ಅನ್ವಯಿಸಿ
ಅನ್ವಯಿಸುವ ಹಂತವು ಬ್ಯಾಚ್ ID ಅನ್ನು ಕ್ಲೈಮ್ ಮಾಡಬೇಕು, ವ್ಯಾಪಾರ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬೇಕು, ಮತ್ತು ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯನ್ನು ಒಂದೇ ಸ್ಥಳೀಯ ವಹಿವಾಟಿನಲ್ಲಿ ದಾಖಲಿಸಬೇಕು. ಪರಿಶೀಲನೆ ಮತ್ತು ಸೇರಿಸುವಿಕೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಹೇಳಿಕೆಗಳಾಗಿ ಮಾಡುವುದು ನೀವು ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸಿದ ರೇಸ್ ಅನ್ನು ಮತ್ತೆ ತರುತ್ತದೆ. ಇಬ್ಬರು ಕೆಲಸಗಾರರು ಸ್ಪರ್ಧಿಸಿದರೆ, ನಿಖರವಾಗಿ ಒಂದು ಕ್ಲೈಮ್ ಗೆಲ್ಲುತ್ತದೆ ಮತ್ತು ಇನ್ನೊಬ್ಬರಿಗೆ ಅದನ್ನು ತಿಳಿಸಲಾಗುತ್ತದೆ.
ಪೂರ್ಣಗೊಳಿಸುವಿಕೆಯ ದಾಖಲೆ ಇಲ್ಲದಿರುವುದು ಪ್ರಗತಿಯಲ್ಲಿರುವ ವಹಿವಾಟು ಎಂದೂ commit ಮಾಡದು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಕ್ಲೈಮ್ ಸ್ಪರ್ಧಾತ್ಮಕ ಪ್ರಯತ್ನಗಳನ್ನು ಕ್ರಮಬದ್ಧಗೊಳಿಸಬೇಕು, ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ಯಾವುದೇ ನಿರ್ಧಾರಕ್ಕೆ ಮೊದಲು ಶಾಶ್ವತ ಫಲಿತಾಂಶವನ್ನು ಓದಬೇಕು.
ಆ ಕ್ರಮಬದ್ಧತೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ನಲ್ಲಿ ಪರಿಶೀಲಿಸಿ-ನಂತರ-ಪುನರಾವರ್ತಿಸಿ ಲೂಪ್ ಬದಲು ಡೇಟಾಬೇಸ್ನ ಬೆಂಬಲಿತ ಕಾರ್ಯವಿಧಾನವನ್ನು ಬಳಸಿ.
ವಿನ್ಯಾಸವು ಇನ್ನೂ ಏನನ್ನು ಭರವಸೆ ನೀಡಲಾರದು
ಸ್ಟೇಜಿಂಗ್ ಕೆಲಸವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಬಹುದಾದಂತೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಒಂದು ದೀರ್ಘಾವಧಿ ಅವಧಿಯ ಮೇಲಿನ ಅವಲಂಬನೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದು SQL Server, Oracle ಮತ್ತು ಕೆಲಸವು ಮಾಡುವ ಯಾವುದೇ ಬಾಹ್ಯ ಅಡ್ಡಪರಿಣಾಮದ ಮೇಲೆ ಒಂದೇ ಪರಮಾಣು commit ಅನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ವ್ಯಾಪಾರಕ್ಕೆ ನಿಜವಾಗಿ ಅದು ಬೇಕಾದರೆ, ಬೆಂಬಲಿತ ವಿತರಿತ ವಹಿವಾಟು ಅಥವಾ ರಿಕನ್ಸೈಲಿಯೇಶನ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿ ಮತ್ತು ಅರ್ಹಗೊಳಿಸಿ, ಅನಿಶ್ಚಿತ ಫಲಿತಾಂಶದ ಕೆಲಸ ಯಾರದ್ದು ಎಂಬುದೂ ಸೇರಿದಂತೆ. ಅದಕ್ಕಿಂತ ದುರ್ಬಲವಾದದ್ದು ವರ್ಗಾವಣೆ ಕೋಡ್ನಲ್ಲಲ್ಲ, ರಿಕನ್ಸೈಲಿಯೇಶನ್ ರನ್ಬುಕ್ನಲ್ಲಿದೆ.
ಮೂರು ಸ್ಥಳಗಳಲ್ಲಿ ಅಡಚಣೆಯನ್ನು ಸ್ವೀಕರಿಸಿ: ವರ್ಗಾವಣೆಯ ಸಮಯದಲ್ಲಿ, ಅನ್ವಯದ ಸಮಯದಲ್ಲಿ, ಮತ್ತು commit ನಂತರ ಆದರೆ ಸ್ವೀಕೃತಿಗೆ ಮೊದಲು. ನಂತರ ಕ್ಲೈಂಟ್ನ ಸಂದೇಶದ ಬದಲು ವ್ಯಾಪಾರ ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಬ್ಯಾಚ್ ಲೆಡ್ಜರ್ ಕೆಲಸವು ಅಪೂರ್ಣ, commit ಆಗಿದೆ, ಅಥವಾ ಇನ್ನೂ ಬಗೆಹರಿಯದಿದೆ ಎಂದು ಹೇಳಲಿ.