ಇಲ್ಲ, ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ನಿಮ್ಮ VPN ಸುರಂಗವನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ
VPN ಅನ್ನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಅಥವಾ ಕ್ಲೈಂಟ್ ಹೊಂದಿದೆ, ಡ್ರೈವರ್ ಎಂದಿಗೂ ಅಲ್ಲ. ಮೊದಲು ಸುರಂಗವನ್ನು ಮೇಲೆತ್ತಿ, netonly ಜೊತೆ ಡೊಮೇನ್ ರುಜುವಾತುಗಳನ್ನು ರವಾನಿಸಿ, ನಂತರ ಕರ್ಸರ್ನ ಹೋಗುಬರುವಿಕೆಗಳನ್ನು ಪರಿಶೀಲಿಸಿ.
ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್, JDBC URL ಅಥವಾ tnsnames.ora ನಮೂದು VPN ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಸ್ಥಳವನ್ನು ಡೆವಲಪರ್ಗಳು ಇನ್ನೂ ಹುಡುಕುತ್ತಿದ್ದಾರೆ. ಅಂತಹ ಸ್ಥಳವಿಲ್ಲ. ಸುರಂಗವನ್ನು ವರ್ಚುವಲ್ ಅಡಾಪ್ಟರ್ ನೋಂದಾಯಿಸುವ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಅಥವಾ ಮಾರಾಟಗಾರನ ಕ್ಲೈಂಟ್ ಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ಮೇಲಿನ ಪ್ರತಿಯೊಂದು ಡೇಟಾಬೇಸ್ ಗ್ರಂಥಾಲಯವು ಅದರಿಂದ ಉಂಟಾಗುವ ಸಾಕೆಟ್ ಪದರವನ್ನು ಬಳಸುತ್ತದೆ. ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಹೋಸ್ಟ್, ಪೋರ್ಟ್ ಮತ್ತು ರುಜುವಾತನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು ಇಷ್ಟೇ ಪೂರ್ತಿ ಪದಕೋಶ.
ಪುರಾಣ: ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಸುರಂಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು
ಡ್ರೈವರ್ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ಗೆ TCP ಸಾಕೆಟ್ ತೆರೆಯುತ್ತದೆ. ಸುರಂಗವನ್ನು ಮೇಲೆತ್ತಲು ಅದಕ್ಕೆ ಯಾವುದೇ API ಇಲ್ಲ, ಸುರಂಗ ಪ್ರೊಫೈಲ್ಗೆ ಕ್ಷೇತ್ರವಿಲ್ಲ, ಮತ್ತು VPN ಗೇಟ್ವೇಗೆ ದೃಢೀಕರಿಸುವ ದಾರಿಯಿಲ್ಲ.
ಆದ್ದರಿಂದ ಮಾರ್ಗವೊಂದು ಇದ್ದಾಕ್ಷಣ ಉಪಕರಣಗಳು ಒಂದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ. SSMS, DBeaver, Eclipse Data Tools ಮತ್ತು ಸಾಮಾನ್ಯ sqlcmd ಸರ್ವರ್ ಸ್ಥಳೀಯ ಜಾಲದಲ್ಲಿದ್ದಂತೆ ವರ್ತಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಸಾಕೆಟ್ನ ದೃಷ್ಟಿಯಿಂದ ಅದು ಹಾಗೆಯೇ ಇದೆ. ವರ್ಚುವಲ್ ಅಡಾಪ್ಟರ್ ಡೇಟಾಬೇಸ್ ಉಪಜಾಲವನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡಿತು, ಮತ್ತು ಡ್ರೈವರ್ಗೆ ಅದು ಹೇಗೆ ಎಂದು ಎಂದಿಗೂ ತಿಳಿಯದು.
ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಕಡಿತವಾದ ಸುರಂಗವನ್ನು ಏಕೆ ಸರಿಪಡಿಸಲಾಗದು ಎಂಬುದನ್ನೂ ಇದು ವಿವರಿಸುತ್ತದೆ. ಕೊಂಡಿ ಸತ್ತಾಗ, ಡ್ರೈವರ್ ಸಮಯ ಮೀರಿಕೆ ಅಥವಾ ಸಾಮಾನ್ಯ ಜಾಲ ದೋಷವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಪ್ರಶ್ನೆ ಸಮಸ್ಯೆ ಎಂದು ಪರಿಗಣಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಶಾಶ್ವತವಾಗಿ ತಪ್ಪು ಪದರವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ.
ಡ್ರೈವರ್ ಚಾಲನೆಯಾಗುವ ಮೊದಲು ಸುರಂಗವನ್ನು ಮೇಲೆತ್ತಿ
ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂ ಮಟ್ಟದಲ್ಲಿ VPN ಸಂಪರ್ಕಿಸಿ, ಪೂರೈಕೆದಾರರು ಅಥವಾ ಜಾಲ ತಂಡದ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ, ಮತ್ತು ನಂತರವೇ ಉಪಕರಣವನ್ನು ತೆರೆಯಿರಿ. ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದರರ್ಥ ಡ್ರೈವರ್ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸುವ ಮೊದಲು ಡೇಟಾಬೇಸ್ ಉಪಜಾಲಕ್ಕೆ ಮಾರ್ಗವಿದೆ.
ಸುರಂಗದ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಅಪ್ಲಿಕೇಶನ್ನ ಹೊರಗೆ ಇರಿಸಿ. ಕೊಂಡಿಯನ್ನು ತಾನೇ ಮೇಲೆತ್ತಲು ಪ್ರಯತ್ನಿಸುವ PHP ಅಥವಾ Java ಸೇವೆ ಒಬ್ಬ ಪೂರೈಕೆದಾರರ ನಡವಳಿಕೆಯನ್ನು ವ್ಯಾಪಾರ ಕೋಡ್ಗೆ ಬರೆಯುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ವೈಫಲ್ಯ ವರ್ಗಾವಣೆಯೂ ಅಪ್ಲಿಕೇಶನ್ ಬಿಡುಗಡೆಯಾಗುತ್ತದೆ. ಸುರಂಗವನ್ನು ಹೊಂದಿರುವ, ಅದನ್ನು ಗಮನಿಸುವ ಮತ್ತು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುವ ಮೇಲ್ವಿಚಾರಕನು ಪ್ರಶ್ನೆ ಮಾರ್ಗದಿಂದ ಪ್ರತ್ಯೇಕ ವಿಷಯ.
ಡ್ರೈವರ್ಗೆ ದೂರು ಹೇಳುವ ಮೊದಲು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ: ಹೋಸ್ಟ್ ಪರಿಹರಿಸದಿದ್ದರೆ ಅಥವಾ ಶೆಲ್ನಿಂದ ಪೋರ್ಟ್ ಉತ್ತರಿಸದಿದ್ದರೆ, ಯಾವುದೇ ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.
ಪುರಾಣ: Windows ದೃಢೀಕರಣ ವೈಫಲ್ಯ ಎಂದರೆ ಮಾರ್ಗ ಮುರಿದಿದೆ
VPN ಮೂಲಕ Windows ದೃಢೀಕರಣವು ಹಲವು ಬಾರಿ ಜಾಲ ದೋಷದಂತೆ ಕಾಣುವ ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ, ಆದರೆ ಮಾರ್ಗ ಸರಿಯಾಗಿರುತ್ತದೆ. ಖಾತೆ ಬೇರೆ ಡೊಮೇನ್ಗೆ ಸೇರಿದ್ದು ಲ್ಯಾಪ್ಟಾಪ್ ಅದನ್ನು ಸೇರಲು ಸಾಧ್ಯವಾಗದಿದ್ದಾಗ, ಡೆಸ್ಕ್ಟಾಪ್ ಅಧಿವೇಶನದ ಗುರುತಿನ ಬದಲು ಸ್ಪಷ್ಟ ರುಜುವಾತುಗಳೊಂದಿಗೆ ಕ್ಲೈಂಟ್ ಪ್ರಾರಂಭಿಸಿ.
runas /noprofile /netonly /user:CORP\dbreader "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"/netonly ಸ್ವಿಚ್ ಆ ರುಜುವಾತುಗಳನ್ನು ದೂರದ ದೃಢೀಕರಣಕ್ಕೆ ಮಾತ್ರ ಇರಿಸುತ್ತದೆ. ಸಂಪರ್ಕ ಸಂವಾದವನ್ನು ನಂಬುವ ಬದಲು SELECT SUSER_SNAME() ಬಳಸಿ ಸರ್ವರ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಪಡೆದಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಸರ್ವರ್ ವಿಳಾಸದ ರುಜುವಾತನ್ನು Windows Credential Manager ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುವುದು SSMS ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಬೇರೆ ಖಾತೆಯ ಅಡಿಯಲ್ಲಿ ಚಲಿಸುವ ಸೇವೆಗೆ ಯಾವಾಗಲೂ ಅಲ್ಲ ಎಂದು ವರದಿಯಾಗಿದೆ, ಆದ್ದರಿಂದ ಲಾಗಿನ್ ಬದಲಿಸುವ ಮೊದಲು ಪ್ರಕ್ರಿಯೆ ಯಾವ ಗುರುತನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ವಿಳಂಬವು ಸರ್ವರ್-ಸೈಡ್ ಕರ್ಸರ್ ಅನ್ನು ಸಮಯ ಮೀರಿಕೆಯಾಗಿ ಮಾರ್ಪಡಿಸುತ್ತದೆ
ಸರ್ವರ್-ಸೈಡ್ ಕರ್ಸರ್ ಡೇಟಾಬೇಸ್ಗೆ ಫಲಿತಾಂಶವನ್ನು ಇಟ್ಟುಕೊಂಡು ಅದನ್ನು ಕ್ರಮೇಣ ತರಲು ಕೇಳುತ್ತದೆ, ಇದು ಒಂದು ದೊಡ್ಡ ಫಲಿತಾಂಶವನ್ನು ಅನೇಕ ಸಣ್ಣ ಹೋಗುಬರುವಿಕೆಗಳಾಗಿ ಬದಲಿಸುತ್ತದೆ. LAN ನಲ್ಲಿ ಅದು ಅಗ್ಗ. ಹತ್ತಾರು ಮಿಲಿಸೆಕೆಂಡುಗಳ ಹೆಚ್ಚುವರಿ ವಿಳಂಬವಿರುವ ಸುರಂಗದ ಮೂಲಕ ಅದೇ ಪ್ರಶ್ನೆ ಹೆಚ್ಚು ಡೇಟಾ ರವಾನಿಸದೆಯೇ ಆಜ್ಞೆಯ ಸಮಯ ಮೀರಿಕೆಯನ್ನು ಮೀರಬಹುದು.
ಕ್ಲೈಂಟ್-ಸೈಡ್ ಕರ್ಸರ್ಗೆ ಬದಲಿಸಿ, ಅಥವಾ fetch size ಹೆಚ್ಚಿಸಿ ಸಾಲುಗಳನ್ನು ಬ್ಯಾಚ್ ಮಾಡಿ, ಆಗ ಹೋಗುಬರುವಿಕೆಗಳ ಸಂಖ್ಯೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ಅಡಚಣೆ ಎಂಬುದು ವಿನಿಮಯಗಳ ಸಂಖ್ಯೆ, ನಾಮಮಾತ್ರ ಕೊಂಡಿ ವೇಗವಲ್ಲ, ಆದ್ದರಿಂದ ಥ್ರೂಪುಟ್ ಅಳೆಯುವುದು ನಿಮ್ಮನ್ನು ದಾರಿ ತಪ್ಪಿಸುತ್ತದೆ, ಹೋಗುಬರುವಿಕೆಗಳನ್ನು ಅಳೆಯುವುದು ತಪ್ಪಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಬಳಕೆದಾರರು ನಿಜವಾಗಿ ಎಳೆಯುವ ಅತಿ ದೊಡ್ಡ ಫಲಿತಾಂಶ ಸೆಟ್ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ, ತಕ್ಷಣ ಮರಳುವ ಒಂದು ಸಾಲಿನ ಪ್ರಶ್ನೆಯೊಂದಿಗೆ ಅಲ್ಲ. ಸಮಯ ಮೀರಿಕೆ ಸರಿದರೂ ಮಾಯವಾಗದಿದ್ದರೆ, ಆಜ್ಞೆಯ ಸಮಯ ಮೀರಿಕೆ ಮತ್ತು fetch size ಎರಡನ್ನೂ ಒಟ್ಟಿಗೆ ಹೆಚ್ಚಿಸಿ ಮತ್ತೆ ಅಳೆಯಿರಿ.
ಅದೇ ಅಂಕಗಣಿತವು ಮಾತಾಡುವ ORM ಗಳಿಗೆ ಮತ್ತು ಪ್ರತಿ ಸಾಲಿಗೆ ಒಂದು ಹೇಳಿಕೆ ಹೊರಡಿಸುವ ಯಾವುದೇ ಕ್ಲೈಂಟ್ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಪ್ರಶ್ನೆ ಯೋಜನೆ ಚೆನ್ನಾಗಿದ್ದು ರವಾನೆ ಚಿಕ್ಕದಾಗಿದ್ದರೆ, ಡೇಟಾಬೇಸ್ ಟ್ಯೂನ್ ಮಾಡುವ ಮೊದಲು ಜಾಲ ವಿನಿಮಯಗಳನ್ನು ಎಣಿಸಿ.
ಪೋರ್ಟ್, ಇನ್ಸ್ಟಾನ್ಸ್ ಮತ್ತು ಸ್ಥಳೀಯ ಫಿಲ್ಟರ್ ಪರಿಶೀಲಿಸಿ
ಹೆಸರಿಸಿದ ಇನ್ಸ್ಟಾನ್ಸ್ ಕ್ರಿಯಾತ್ಮಕ ಪೋರ್ಟ್ನಲ್ಲಿ ಕೇಳುತ್ತದೆ, ಆದ್ದರಿಂದ 1433 ಎಂದು ಊಹಿಸದೆ ಪೋರ್ಟ್ ಖಚಿತಪಡಿಸಿ. ಡೀಫಾಲ್ಟ್ ಇನ್ಸ್ಟಾನ್ಸ್ನಲ್ಲಿ ಮೌಲ್ಯವನ್ನು ಇನ್ಸ್ಟಾನ್ಸ್ನ SuperSocketNetLib ಕೀ ಅಡಿಯಲ್ಲಿನ TcpPort ರಿಜಿಸ್ಟ್ರಿ ಮೌಲ್ಯದಿಂದ ಓದಬಹುದು. Oracle ಗೆ, tnsnames.ora ನಲ್ಲಿನ ಹೋಸ್ಟ್ ಪರಿಹರಿಸುತ್ತದೆ, ವಿಳಾಸ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು listener ಪೋರ್ಟ್ ಅನುಮತಿಸಲಾಗಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ; 1521 ಸಾಮಾನ್ಯ ಡೀಫಾಲ್ಟ್, ಖಾತರಿ ಅಲ್ಲ.
ನಂತರ ಸುರಂಗದ ಸ್ವಂತ ಪ್ರವೇಶ ಪಟ್ಟಿಯನ್ನು ಮತ್ತು ಕೊನೆಗೆ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಒಂದೇ ಯಂತ್ರವಾಗಿದ್ದರೂ ಸಂಪರ್ಕವನ್ನು ತಡೆಯುವ ಸ್ಥಳೀಯ ಆಂಟಿವೈರಸ್ ಅಥವಾ ಹೋಸ್ಟ್ ಫೈರ್ವಾಲ್ ಅನ್ನು ಹೊರಗಿಡಿ. ಸಂರಚನೆ ಬದಲಿಸುವ ಮೊದಲು ವಿಫಲವಾಗುವ ಹಂತವನ್ನು ದಾಖಲಿಸಿ, ಏಕೆಂದರೆ ಹೆಸರು ಪರಿಹಾರ, TCP ತಲುಪುವಿಕೆ ಮತ್ತು TLS ಅಥವಾ ಲಾಗಿನ್ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಸಂದೇಶದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ.
ಹಂತವನ್ನು ಟಿಕೆಟ್ನಲ್ಲಿ ಬರೆಯಿರಿ. ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ಇದೆಲ್ಲವನ್ನೂ ಪ್ರಾರಂಭಿಸಿದ ಅದೇ ಸಂಪರ್ಕ-ಸ್ಟ್ರಿಂಗ್ ಹುಡುಕಾಟವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ.