cancel
Showing results for 
Search instead for 
Did you mean: 

Related to log cache at sybase

suznCB
Participant

We have a warm standby replication between two sybase ase databases, to tune performance of both sybase ase and sybase replication, we added a log cache for active database, on the side of this database, we noted it became more agile when we execute storedprocedure that deal with huge tables, i.e this procedure was taken about 2 min to finish, after adding the log cache it takes now about 50 sec, and in the sysmon report , in replication agent section, we found that time needed to scan log was decreaeed comparing to the time needed when we were exec the same procedure before adding the log cache, but we also noted the latency between two databases increased , is there any related issue between them ?

We get latency by calculate the difference between origin time and commited time in the rs_lastcommit table at standby database

Any hint will be useful

Regards

suznCB
Participant
0 Kudos

Dears

would you help in our issue, Please?

View Entire Topic
Mark_A_Parsons
Contributor

You haven't provided any additional details about the original issue (latency) so I take it this topic is now on the back burner.

As for the change in topic (should probably be a new/separate question) ...

------------------

If you disable replication of some tables then those tables will be out of sync so if/when you perform a switch active you'll find the 'new' active database is 'missing' data from those non-replicated tables. While there's nothing wrong with this kind of setup (eg, you don't want to replicate what are effectively 'scratch' tables) you need to be 100% certain this is the correct approach for said tables.

As for disabling replication of some tables ... you can still use sp_reptostandby but then you'll want to follow that up with sp_setreptable <tablename>, 'never'. [See Example 6 in the documentation for sp_setreptable.]

------------------

As for the last item, this is merely highlighting the fact that if a table's primary key (used by Repserver to build a where clause for replicated delete/update statements) includes a column based on an approximate datatype (eg, real/float), then the where clause may not function properly due to the approximate nature of the values in said column (ie, if the where clause does not function properly then the delete/update statement may not be replicated). This has nothing to do with replication but rather the general issue of how a where clause may not function as expected when applied to a column based on an approximate datatype.

Your (internet search) reference is suggesting ... if you have a table with a primary key (or unique index) that references a real/float column ... that you explicitly define a primary key (in a table's repdef) to insure that it does not reference the real/float column; 'course this assumes you can define a primary key for the table sans the real/float column (though generally speaking you probably shouldn't have a primary key (or unique index) based on a real/float column to start with).

If you your table's primary key (or unique index) does not reference a column that uses an approximate datatype then you should be able to ignore this issue.

suznCB
Participant
0 Kudos

Thank you very much