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 ਹੋ ਚੁੱਕਾ ਹੈ, ਜਾਂ ਅਜੇ ਵੀ ਅਣਸੁਲਝਿਆ ਹੈ।