ನಿಮ್ಮ ಸಿಂಕ್ರೊನಸ್ SQL ಕಮಿಟ್ VPN ರೌಂಡ್ ಟ್ರಿಪ್ಗಾಗಿ ಕಾಯುವುದೇಕೆ
ಲಭ್ಯತೆ ಗುಂಪಿನಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್ ದೂರದ ಲಾಗ್ನ ಸ್ಥಿರೀಕರಣವನ್ನು ಒಳಗೊಂಡಿದೆ. ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ಅನ್ನು ದೂಷಿಸುವ ಅಥವಾ ಮೋಡ್ ಬದಲಿಸುವ ಮೊದಲು ಆ ಮಾರ್ಗವನ್ನು ಅಳೆಯಿರಿ.
ಎರಡನೇ ಸೈಟ್ಗೆ ರೆಪ್ಲಿಕಾ ಸ್ಥಳಾಂತರಗೊಂಡ ನಂತರ ಬರವಣಿಗೆಯ ಲೇಟೆನ್ಸಿ ಜಿಗಿದಿತು, ಮತ್ತು ಟನೆಲ್ ಹೊಸತಾದ ಅಂಶವಾಗಿದೆ, ಆದ್ದರಿಂದ ದೋಷ ಅದರ ಮೇಲೆ ಬೀಳುತ್ತದೆ. ಟನೆಲ್ ನಿರ್ದೋಷವಾಗಿರಬಹುದು: ಸಿಂಕ್ರೊನಸ್-ಕಮಿಟ್ ಲಭ್ಯತೆ ಗುಂಪಿನ ಒಳಗೆ ಪ್ರಾಥಮಿಕವು ದೂರದ ಲಾಗ್ ಬರವಣಿಗೆ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಮಿಟ್ ಅನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಪ್ರತಿ ವಹಿವಾಟು ಒಂದು ರೌಂಡ್ ಟ್ರಿಪ್ ಪಾವತಿಸುತ್ತದೆ, ಲಿಂಕ್ ಎಷ್ಟು ಮೆಗಾಬಿಟ್ ಸಾಗಿಸಬಲ್ಲದಿದ್ದರೂ. ಥ್ರೂಪುಟ್ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಬೈಟ್ಗಳನ್ನು ಅಳೆಯುತ್ತದೆ, ಲೇಟೆನ್ಸಿ ಒಂದು ವಿನಿಮಯ ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಅಳೆಯುತ್ತದೆ, ಮತ್ತು ಕಮಿಟ್ ಮುಗಿಯಲು ಒಂದು ಸಣ್ಣ ವಿನಿಮಯ ಸಾಕು. ಒಂದು ಸಂಖ್ಯೆ ವಾದವನ್ನು ತೀರ್ಮಾನಿಸುತ್ತದೆ: ಸಣ್ಣ ವಹಿವಾಟಿನ ಕಮಿಟ್ ಅವಧಿ, ಲಭ್ಯತೆ ಡೇಟಾಬೇಸ್ನ ಒಳಗೆ ಮತ್ತು ನಂತರ ಅದೇ ಇನ್ಸ್ಟಾನ್ಸ್ನ ಸ್ಥಳೀಯ ಕೋಷ್ಟಕದ ವಿರುದ್ಧ ಮತ್ತೊಮ್ಮೆ ಅಳೆಯಲಾಗುತ್ತದೆ.
ಪ್ರಾಥಮಿಕವು ನಿಜವಾಗಿ ಯಾವುದಕ್ಕಾಗಿ ಕಾಯುತ್ತದೆ
ಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್ ಅಡಿಯಲ್ಲಿ ಪ್ರಾಥಮಿಕವು ಪಾಲುದಾರ ತನ್ನ ಲಾಗ್ ದಾಖಲೆಗಳು ಸ್ಥಿರವಾಗಿ ಬರೆಯಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುವವರೆಗೆ ಕಮಿಟ್ ಮನ್ನಣೆಯನ್ನು ಹಿಡಿದಿಡುತ್ತದೆ. ಸ್ಥಿರವಾಗಿ ಎಂದರೆ ದ್ವಿತೀಯದ ವಹಿವಾಟು ಲಾಗ್ಗೆ ಶಾಶ್ವತವಾಗಿ ಬರೆಯಲಾಗಿದೆ, ಅದರ ಡೇಟಾ ಪುಟಗಳಲ್ಲಿ ಮತ್ತೆ ಚಲಾಯಿಸಲಾಗಿಲ್ಲ. ರೀಡೂ ಪ್ರಾಥಮಿಕದ ಕಮಿಟ್ಗೆ ಒಂದು ಮಿಲಿಸೆಕೆಂಡ್ ಸೇರಿಸದೆ ನಿಮಿಷಗಳ ಕಾಲ ಹಿಂದೆ ಬೀಳಬಹುದು.
ಲಭ್ಯತೆ ಮೋಡ್ಗಳ ಬಗ್ಗೆ Microsoft ನ ದಾಖಲೆ ಆ ಹಸ್ತಲಾಘವವನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಪಾಲುದಾರ ಹೊರಬಿದ್ದಾಗ ಪ್ಲಾಟ್ಫಾರ್ಮ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ. ಸಿಂಕ್ರೊನಸ್ ಎಂದು ಗುರುತಿಸಲಾದ ರೆಪ್ಲಿಕಾ ಕಾಯುವಿಕೆಯ ಬಗ್ಗೆ ಒಂದು ನಿಯಮ, ಪ್ರತಿ ಕಮಿಟ್ಗೂ ಆರೋಗ್ಯಕರ ದೂರದ ಪ್ರತಿ ಇದೆ ಎಂಬ ಶಾಶ್ವತ ಭರವಸೆ ಅಲ್ಲ. ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡ ಮಾರ್ಗವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದು ಕೇವಲ ಕಮಿಟ್ ವಿಫಲವಾಗುವುದು ಅಲ್ಲ.
ಆದ್ದರಿಂದ ನೀವು ನೋಡುವ ಕಾಯುವಿಕೆ ಒಂದು ಮೊತ್ತ: ಲಾಗ್ ಸಾಗಣೆ, ಎರಡೂ ಹೋಸ್ಟ್ಗಳಲ್ಲಿ ಶೆಡ್ಯೂಲಿಂಗ್ ಮತ್ತು ದೂರದ ಸಂಗ್ರಹಕ್ಕೆ ಬರವಣಿಗೆ. ಸ್ಯಾಚುರೇಟೆಡ್ ಲಾಗ್ ಪರಿಮಾಣದ ದ್ವಿತೀಯವು ಯಾವುದೇ ವೇಗ ಪರೀಕ್ಷೆ ತೋರಿಸದ ಸಮಯವನ್ನು ಸೇರಿಸುತ್ತದೆ. ದೂರು VPN ಅನ್ನು ಹೆಸರಿಸಿದಾಗ ಆ ಡಿಸ್ಕ್ ವಿರಳವಾಗಿ ಅಳೆಯಲಾಗುತ್ತದೆ.
ಬ್ಯಾಂಡ್ವಿಡ್ತ್ ರೌಂಡ್-ಟ್ರಿಪ್ ವಿಳಂಬವಲ್ಲ
ವೇಗ ಪರೀಕ್ಷೆ ಮಾರ್ಗವನ್ನು ಸ್ವಲ್ಪ ಸಮಯ ಮುಳುಗಿಸಿ ದರವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಕಮಿಟ್ ಹೆಚ್ಚು ಸಂಕುಚಿತವಾದದ್ದನ್ನು ಕೇಳುತ್ತದೆ: ಸಣ್ಣ ಸಂದೇಶವು ಇನ್ನೊಂದು ಬದಿಯನ್ನು ತಲುಪಲು, ಸಂಗ್ರಹವಾಗಲು ಮತ್ತು ಹಿಂತಿರುಗಲು ಎಷ್ಟು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮಾರ್ಗದ ಉದ್ದ, ಸರದಿ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ನಷ್ಟ ಆ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಪೂರೈಕೆದಾರ ಮಿತಿಯನ್ನು ಹೆಚ್ಚಿಸಿದಾಗ ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಸುಧಾರಿಸುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ «ವೇಗದ» ಟನೆಲ್ ಅನೇಕ ಸಣ್ಣ ಅನುಕ್ರಮ ವಹಿವಾಟುಗಳಿಂದ ನಿರ್ಮಿಸಲಾದ ಬರವಣಿಗೆ-ಭಾರೀ ಕೆಲಸದ ಹೊರೆಗೆ ಗೋಚರ ದಂಡವನ್ನು ಸೇರಿಸಬಹುದು. ಅದೇ ಒಟ್ಟು ಬೈಟ್ಗಳನ್ನು ಸಾವಿರ ಕಮಿಟ್ಗಳಿಗೆ ಹಂಚಿದರೆ ರೌಂಡ್ ಟ್ರಿಪ್ ಅನ್ನು ಸಾವಿರ ಬಾರಿ ಪಾವತಿಸುತ್ತದೆ; ಒಂದು ಬೃಹತ್ ವರ್ಗಾವಣೆ ಅದನ್ನು ಒಮ್ಮೆ ಪಾವತಿಸುತ್ತದೆ.
ಪ್ರತಿನಿಧಿ ಹೊರೆಯ ಅಡಿಯಲ್ಲಿ ರೆಪ್ಲಿಕಾ ಮಾರ್ಗದ ಮೇಲೆಯೇ ವಿಳಂಬ ಮತ್ತು ನಷ್ಟವನ್ನು ಅಳೆಯಲು ನೆಟ್ವರ್ಕ್ ಮಾಲೀಕರನ್ನು ಕೇಳಿ. ಕಚೇರಿ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ VPN ಗೇಟ್ವೇಗೆ ಪಿಂಗ್, ಅಥವಾ ಹತ್ತಿರದ ನೋಡ್ಗೆ ವೇಗ ಪರೀಕ್ಷೆ, ಲಾಗ್ ನಿಜವಾಗಿ ಸಾಗುವ ಮಾರ್ಗಕ್ಕೆ ಬಹುತೇಕ ಏನನ್ನೂ ಆರೋಪಿಸುವುದಿಲ್ಲ. ಅಳತೆ ವಿಂಡೋ ನಿಧಾನ ಬರವಣಿಗೆಯ ಗಂಟೆಗಳೊಂದಿಗೆ ಒಂದಾಗುವಂತೆ ಮಾಡಿ.
ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ರೆಪ್ಲಿಕಾ ಸ್ಥಿತಿಯನ್ನು ಓದಿ
ಇನ್ಸ್ಟಾನ್ಸ್ಗಳು ತಮ್ಮ ಬಗ್ಗೆ ವರದಿ ಮಾಡುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಏಕೆಂದರೆ ಪಾಲುದಾರಿಕೆ ಎಷ್ಟು ಆರೋಗ್ಯಕರ ಎಂಬುದರ ಬಗ್ಗೆ ಎರಡೂ ಬದಿಗಳು ಒಪ್ಪದಿರಬಹುದು ಮತ್ತು ಡ್ಯಾಶ್ಬೋರ್ಡ್ನ ಸರಾಸರಿ ಯಾವ ಸರದಿ ಚಲಿಸುತ್ತಿದೆ ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ. ಕೆಳಗಿನ ಪ್ರಶ್ನೆಗಳು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತವೆ: ಒಂದು ಪ್ರತಿ ಡೇಟಾಬೇಸ್ಗೆ ರೆಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿಯನ್ನು ಓದುತ್ತದೆ, ಇನ್ನೊಂದು ಪ್ರತಿ ರೆಪ್ಲಿಕಾ ಹೇಗೆ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ಓದುತ್ತದೆ. ಯಾವುದೇ ಮೋಡ್ ಮುಟ್ಟುವ ಮೊದಲು ಎರಡನ್ನೂ ಚಲಾಯಿಸಿ.
SELECT ag.name AS ag_name, drs.database_id, drs.synchronization_state_desc,
drs.log_send_queue_size, drs.redo_queue_size, drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id;
SELECT ar.replica_server_name, ar.availability_mode_desc, ar.failover_mode_desc
FROM sys.availability_replicas AS ar;
ಮೊದಲ ಫಲಿತಾಂಶ ಲಾಗ್ ಸಾಗಣೆಯನ್ನು ರೀಡೂದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. log_send_queue_size ಏರುತ್ತಿದ್ದರೆ redo_queue_size ಸಮತಟ್ಟಾಗಿದ್ದರೆ ಲಾಗ್ ಬಂದಿಲ್ಲ ಎಂದರ್ಥ; ವಿರುದ್ಧವಾದರೆ ಅದು ಬಂದಿದೆ ಮತ್ತು ಮರುಪ್ಲೇ ಹಿಂದಿದೆ ಎಂದರ್ಥ. ಕಮಿಟ್ ಮಾರ್ಗದಲ್ಲಿ ಮೊದಲ ಪ್ರಕರಣ ಮಾತ್ರ ಕುಳಿತುಕೊಳ್ಳುತ್ತದೆ.
ಎರಡನೇ ಫಲಿತಾಂಶ ಯಾವ ರೆಪ್ಲಿಕಾಗಳು ನಿಜವಾಗಿ ನೀವು ಊಹಿಸಿದಂತೆ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಹಿಂದಿನ ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಬದಲಾದ ಮೋಡ್ ಬದಲಾದ ಮತ್ತು ದಾಖಲೆಯಿಲ್ಲದ ಸ್ಥಿತಿಯಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. ಗುಂಪಿನ ಡೀಫಾಲ್ಟ್ ಬದಲು ನಿಮಗೆ ಮುಖ್ಯವಾದ ಸಾಲನ್ನು ಓದಿ: availability_mode_desc ಮತ್ತು failover_mode_desc ಪ್ರತಿ ರೆಪ್ಲಿಕಾಗೆ. secondary_lag_seconds SQL Server 2016 ಮತ್ತು ನಂತರದ್ದರಲ್ಲಿ ಮಾತ್ರ ಇದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ ಬಿಲ್ಡ್ ನಿಮಗೆ ಕಳುಹಿಸುವ ಸರದಿ ಮತ್ತು ರೀಡೂ ಕಾಲಮ್ಗಳನ್ನು ಮಾತ್ರ ಬಿಡುತ್ತದೆ.
ನಂತರ ಡ್ಯಾಶ್ಬೋರ್ಡ್ನ ಸರಾಸರಿಯನ್ನು ನಂಬುವ ಬದಲು ಪ್ರತಿನಿಧಿ ಬರವಣಿಗೆಯನ್ನು ಅಳೆಯಿರಿ. ಕೆಳಗಿನ ಬ್ಲಾಕ್ ಅನ್ನು ಲಭ್ಯತೆ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಚಲಾಯಿಸಿ, ನಂತರ ಅದೇ ಇನ್ಸ್ಟಾನ್ಸ್ನಲ್ಲಿ ಗುಂಪಿನ ಹೊರಗಿನ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಅದೇ ಕೋಷ್ಟಕ ಆಕಾರದ ವಿರುದ್ಧ ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಎರಡು ಅವಧಿಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ದೂರದ ಲಾಗ್ನ ಒರಟು ಬೆಲೆ, ಮತ್ತು ನೆಟ್ವರ್ಕ್ ತಂಡದೊಂದಿಗೆ ವಾದದಲ್ಲಿ ಅದು ಗ್ರಾಫ್ಗಿಂತ ಬಹಳ ಚೆನ್ನಾಗಿ ನಿಲ್ಲುತ್ತದೆ. ನಂತರ ಒಂದೊಂದಾಗಿ ಒಂದು ವೇರಿಯೇಬಲ್ ಬದಲಿಸಿ, ಇಲ್ಲದಿದ್ದರೆ ವ್ಯತ್ಯಾಸದ ಅರ್ಥ ಉಳಿಯುವುದಿಲ್ಲ.
IF OBJECT_ID('dbo.CommitProbe') IS NULL
CREATE TABLE dbo.CommitProbe (probe_id int PRIMARY KEY, touched_at datetime2(3));
IF NOT EXISTS (SELECT 1 FROM dbo.CommitProbe WHERE probe_id = 1)
INSERT INTO dbo.CommitProbe (probe_id) VALUES (1);
SET STATISTICS TIME ON;
BEGIN TRANSACTION;
UPDATE dbo.CommitProbe SET touched_at = SYSUTCDATETIME() WHERE probe_id = 1;
COMMIT TRANSACTION;
SET STATISTICS TIME OFF;
ಅಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್ ಏನು ಖರೀದಿಸುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ
ಅಸಿಂಕ್ರೊನಸ್ ಕಮಿಟ್ನೊಂದಿಗೆ ಪ್ರಾಥಮಿಕವು ದೂರದ ಸ್ಥಿರೀಕರಣದ ದೃಢೀಕರಣಕ್ಕಾಗಿ ಕಾಯುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ರೌಂಡ್ ಟ್ರಿಪ್ ಕಮಿಟ್ ಮಾರ್ಗದಿಂದ ಹೊರಟುಹೋಗುತ್ತದೆ. ಕಮಿಟ್ ಲೇಟೆನ್ಸಿ ಇಳಿಯುತ್ತದೆ ಮತ್ತು ದ್ವಿತೀಯವು ಯಾರೂ ನಿಯಂತ್ರಿಸದಷ್ಟು ಹಿಂದೆ ಬೀಳಲು ಸ್ವತಂತ್ರವಾಗಿರುತ್ತದೆ. ಅದು ಕಾಯುವಿಕೆಗೆ ನಿಜವಾದ ಪರಿಹಾರ ಮತ್ತು ಭರವಸೆಗೆ ನಿಜವಾದ ಬದಲಾವಣೆ.
ಬೆಲೆ ಚೇತರಿಕೆ ಬಿಂದುವಿನ ನಿರ್ಧಾರ. ಪ್ರಾಥಮಿಕವು ತನ್ನ ಲಾಗ್ ನಿಜವಾಗಿ ಬಳಸಬಹುದಾದ ಫೇಲ್ಓವರ್ ಗುರಿಯನ್ನು ತಲುಪುವ ಮೊದಲು ಸತ್ತರೆ, ಸೇವೆಯನ್ನು ಅಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಗೆ ಸರಿಸುವುದು ಅಪ್ಲಿಕೇಶನ್ ಈಗಾಗಲೇ ಕಮಿಟ್ ಎಂದು ವರದಿ ಮಾಡಿದ ವಹಿವಾಟುಗಳನ್ನು ಎಸೆಯುತ್ತದೆ. ಯಾವುದೇ ಸಂರಚನಾ ಸಂವಾದ ಅದನ್ನು ಹಾಗೆ ಪ್ರಸ್ತುತಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಸ್ವೀಕಾರಾರ್ಹ ನಷ್ಟದ ಬಗ್ಗೆ ವ್ಯಾಪಾರ ಪ್ರಶ್ನೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಸೆಟ್ಟಿಂಗ್ ಅಲ್ಲ. ಸಹಿಸಬಹುದಾದ ನಷ್ಟ ವಿಂಡೋವನ್ನು ಘಟನೆಯ ಮೊದಲು ಬರೆಯಿರಿ, ಅದರ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ.
ಮೋಡ್ ಅನ್ನು ಡೇಟಾ ಮಾಲೀಕರೊಂದಿಗೆ ಲಿಖಿತವಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳಿ, ಆದ್ಯತೆಯ ಗುರಿ ಲಭ್ಯವಿಲ್ಲದ ಸಂದರ್ಭದ ಫೇಲ್ಓವರ್ ಕಾರ್ಯವಿಧಾನದೊಂದಿಗೆ. ವಿನ್ಯಾಸ ದಾಖಲೆಯಲ್ಲಿ ಸಿಂಕ್ರೊನಸ್ ಕಾರ್ಯಾಚರಣಾ ಕೈಪಿಡಿ ಅಲ್ಲ, ಮತ್ತು ಅಸಿಂಕ್ರೊನಸ್ ಸರದಿಗಳನ್ನು ನೋಡುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಪರವಾನಗಿ ಅಲ್ಲ.
ನಂತರ ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಪರಿಹಾರವನ್ನು ಆಯ್ಕೆಮಾಡಿ
ನಾಲ್ಕು ಪ್ರಾಮಾಣಿಕ ಆಯ್ಕೆಗಳಿವೆ. ಅಪ್ಲಿಕೇಶನ್ನ ಅರ್ಥಶಾಸ್ತ್ರವು ಬ್ಯಾಚಿಂಗ್ಗೆ ಅನುಮತಿಸುವಲ್ಲಿ ತಪ್ಪಿಸಬಹುದಾದ ಕಮಿಟ್ ರೌಂಡ್ ಟ್ರಿಪ್ಗಳನ್ನು ಕಡಿತಗೊಳಿಸಿ; ನೀವು ಅಳೆದ ಸಾಗಣೆ ಅಥವಾ ಸಂಗ್ರಹ ಅಡಚಣೆಯನ್ನು ಸರಿಪಡಿಸಿ, ಅದು ದ್ವಿತೀಯದಲ್ಲಿ ದೊಡ್ಡ ಪೈಪ್ನ ಬದಲು ವೇಗವಾದ ಲಾಗ್ ಪರಿಮಾಣವನ್ನು ಅರ್ಥೈಸಬಹುದು; ರೌಂಡ್ ಟ್ರಿಪ್ ಕುಗ್ಗಲು ರೆಪ್ಲಿಕಾವನ್ನು ಹತ್ತಿರಕ್ಕೆ ತನ್ನಿ; ಅಥವಾ ರಕ್ಷಣಾ ನೀತಿಯನ್ನು ಸಡಿಲಗೊಳಿಸಿ ಮತ್ತು ವಿಶಾಲ ನಷ್ಟ ವಿಂಡೋವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಿ. ಪ್ರತಿಯೊಂದೂ ಲೇಟೆನ್ಸಿಯನ್ನು ಬೇರೆ ಯಾವುದನ್ನೋ ಖರ್ಚು ಮಾಡಿ ಖರೀದಿಸುತ್ತದೆ, ಮತ್ತು ನಾಲ್ಕನೆಯದು ಬಾಳಿಕೆಯನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ. ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಖರ್ಚನ್ನು ಹೆಸರಿಸಿ.
ಕೆಲಸದ ಹೊರೆಯ ಲೇಟೆನ್ಸಿ ಗುರಿ ಮತ್ತು ಅದರ ಬಾಳಿಕೆ ಅಗತ್ಯವನ್ನು ಒಟ್ಟಿಗೆ ಮುಂದೆ ಇಟ್ಟುಕೊಂಡು ನಿರ್ಧರಿಸಿ, ಏಕೆಂದರೆ ಒಂದನ್ನು ಅತ್ಯುತ್ತಮಗೊಳಿಸುವುದು ಇನ್ನೊಂದನ್ನು ಮೌನವಾಗಿ ಖರ್ಚು ಮಾಡುತ್ತದೆ. ನಂತರ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಅಳೆದ ಅದೇ ವಹಿವಾಟನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಆ ಸಂಖ್ಯೆಯನ್ನು ಅಲುಗಾಡಿಸಲಾಗದ ಪರಿಹಾರ ಬದಲಾವಣೆ ಟಿಕೆಟ್ ಧರಿಸಿದ ಊಹೆ.
ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಮೊದಲು ಮತ್ತು ನಂತರದ ಓದುಗಳನ್ನು ಇರಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ ನಿಧಾನ ಬರವಣಿಗೆಯನ್ನು ನೋಡುವ ಮುಂದಿನ ವ್ಯಕ್ತಿ ತನಿಖೆಯನ್ನು ಮೊದಲಿನಿಂದ ಪುನರಾವರ್ತಿಸಿ ಮತ್ತೆ ಟನೆಲ್ ಅನ್ನು ದೂಷಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ.