The Direct Replication Scheme


When a call is finished, GW_Relay will save the data not directly into GW_CDR in the local SQL server but into a buffer table called Log_PendingRepl, in the form of an SQL statement to be executed at the remote Billing Server. Check below






{CALL proc_GW_CDR(3870829,`10/04/2003 09:49:01`,15390,581,`30175113309712`,,116,4112,`g729r8`,1,,30171,0.02,159,0,16656,330064,19907,398140,`GW1_Gigatel`)}


{CALL proc_GW_CDR(3870826,`10/04/2003 09:50:47`,5320,497,`30175113376068`,,207,4112,`g729r8`,1,,30171,0.04,169,0,8983,175589,23335,466700,`GW1_Gigatel`)}


{CALL proc_GW_CDR(3870830,`10/04/2003 09:55:47`,12810,204,30175114972862,,114,4112,`g729r8`,1,,30171,0.04,190,0,7277,142886,5597,111940,`GW1_Gigatel`)}


Notice the use above of the accent instead of the apostrophe, this is because apostrophes have a functional meaning within SQL statements, this way you avoid the SQL interpreter from misinterpreting.  


The Replication Scheme involved two applications: 

Only after receiving the ACK is that it will delete the record from the Log_PendingRepl table. SrcRepl will re-send the ACK packet to the OmniMonitor and it will blink the Ack indicator with "Rpl" in green background on the GW_Monitor.


If for any reason SQLReplic canít perform the transaction, then it sends a not acknowledge packet (NAK) to SrcRepl. When a NAK is received by SrcRepl, it will wait 5 seconds and re-send the same SQL but will send a NAK instead to the OmniMonitor that, this time, will blink the indicator in red. The same SQL will be re-resent until the transaction is successful. After 20 replication failures in a row, ReplSrc will send an Alarm 12 to the GW_Relay that will be broadcasted to all the monitors.


The SrcReplic window shows the last packet sent, while SQLReplic window shows the last transaction performed and the result message below. When there is a replication failure, you can check on these windows to figure out what is going wrong


Possible reasons for transactions to fail:

         Different record with same CallID (if it were the same record, ACK will be sent back)

         No disc space for the SQL Server

         No space for Transaction Log (Dump transaction in TempDB)

         The table locked for some query being modifying records.

         Sum check fails.


There's another field in the Log_PendingRepl table which is Priority. This field plays a more complex role in the OmniBox Extended Replication System, but still play one here. After trying 20 times with persistent failure, SrcRepl will not keep insisting in replicating that record because that would stall the whole replication process, at this time, it will lower its priority, so that it will insist on that one only when there is nothing pending. A persisting failure will generate a recurrent alarm # 12 that will warn operators that some human intervention is needed. 


SQLReplic makes an ODBC connection to the billing database, the default DNS is ReplSrc, but a different one may be specified in the S/ command line switch. This connection may require a user name and password, maybe a different port number than the default 1099 or if the computer has several network adapters you may need to specify which IP is it that you need to work with. You specify these parameters using the SQLReplic command line switches. Syntax below:


SQLReplic.exe N/[port Number]  U/[User name] P/[Password] I/{Ip address] S/[ODBC Source name]



The ReplSrc.exe Setup


The ReplSrc parameters are not read from the command line as the SQLReplic, but from the sys_parameter table. ReplSrc parameters are the ones belonging to set 100, 

Set_ID ParamID ParamNumValue ParamStringValue Description
100 1 Local IP address for replication
100 6 1065 0 GW_Relay UDP port number*
100 7 0   Delete without Verifying check sum **
100 8 GW_Relay IP**
100 14 1099 SQLReplic port and IP of the Billng Server


*This is needed for the acknowledge message sent to the OmniMonitor

**For trouble shooting by #include only, must be always set to 0. 


ReplSrc uses UDP port 1998.