EM414 – SQL Remote Tips & Techniques Robert Waywell Senior Product Support Engineer iAnywhere Solutions Rwaywell@

  • View
    216

  • Download
    0

Embed Size (px)

Text of EM414 – SQL Remote Tips & Techniques Robert Waywell Senior Product Support...

  • EM414 SQL Remote Tips & TechniquesRobert WaywellSenior Product Support EngineeriAnywhere SolutionsRwaywell@sybase.com

  • ObjectivesProvide technical examples showing how to implement real-world business requirements using SQL RemoteDevelop an understanding of these examples which will enable their extension and customization

  • TopicsMultiple SubscriptionsMessage System Control ChartOne-Way PublicationsSelf-Refreshing Primary Key PoolPassthrough in a Multi-Tier EnvironmentRequest QueueDBRemote and DBXtract ExclusivityLast Chance Threshold

  • Sample Databases

  • Multiple SubscriptionsBusiness RequirementA given user or type of user requires a super-set of the data sent to other users or classes of users

    Example: Each sales rep is assigned customers and the manager needs to see all the customers for each of their sales reps

  • Multiple Subscriptions Business Requirement1 Jones Rep12 Rice Rep21 Jones Rep12 Rice Rep2

  • Multiple Subscriptions Design ConsiderationsPublications are handled by the engineThe more publications you have the more work the engine has to do to evaluate each publication and the more information that has to be written to the log fileWhen using SQL Remote for ASE this work is handled by the scan phase (-i) of SSRemote.exe Subscriptions are handled by DBRemote/SSRemoteDuring the send phase, DBRemote/SSRemote maps the current Subscriptions to the Publication information in the log file and generates appropriate messages for each remote user

  • Multiple Subscriptions Design ConsiderationsPublications are handled by the engine2 Rice Rep1UPDATE Customer SET sales_rep = Rep1 WHERE cust_id = 2Log FileCustomer_Pub2OLD()NEW()Customer_Pub1OLD()NEW()UPDATE Customer. . .

  • Multiple Subscriptions Design ConsiderationsSubscriptions are handled by DBRemote/SSRemoteLog FileCustomer_Pub1OLD(Rep1)NEW(Rep2)UPDATE Customer. . . DBRemote/SSRemote

  • Multiple Subscriptions Design AlternativesCreate Two Publications One for the ManagersOne for the Sales Reps

    Create One PublicationPartition records at the Sales Rep levelCreate multiple subscriptions for a Manager

  • Multiple Subscriptions Implementation

  • Multiple Subscriptions ImplementationCREATE PUBLICATION Customer_Pub( TABLE Customer SUBSCRIBE BY ( SELECT salesrep_id FROM Link WHERE Customer.customer_id = Link.customer_id ))

    CREATE SUBSCRIPTION TO Customer_Pub(1) FOR SalesRep1;CREATE SUBSCRIPTION TO Customer_Pub(2) FOR SalesRep2;

    CREATE SUBSCRIPTION TO Customer_Pub(1) FOR Manager1;CREATE SUBSCRIPTION TO Customer_Pub(2) FOR Manager1;

  • TopicsMultiple SubscriptionsMessage System Control ChartSelf-Refreshing Primary Key PoolPassthrough in a Multi-Tier EnvironmentRequest QueueDBRemote and DBXtract ExclusivityLast Chance Threshold

  • Message System Control ChartBusiness RequirementSQL Remote has inherent latency in communications, this is one of the characteristics of message based replication. Remote users are typically expected to replicate on a semi-regular schedule.Need to differentiate between expected latency and unexpected latency.

  • Message System Control Chart Business Requirements

    User_nameLog_sentConfirm_sentRem1332214331903Rem2332214331353

  • Message System Control ChartDesign ConsiderationsLatency can be measured as the difference between the log_sent and confirm_sent values for a given remote (or consolidated) user.Amount of expected latency is specific to a given system. Some factors contributing to latency include:Volume of system activityReplication scheduleBusiness travelVacations

  • Message System Control Chart Design ConsiderationsConcept of a Statistical Control Chart has existed since 1920.Plot sample values relative to a mean valueValues that fall within +/- 3 standard deviations of the mean are considered to be chance variation and the process is in controlValues that fall outside the limits are considered to be assignable variation and the process is out of control

  • Message System Control Chart Design Considerations

  • Message System Control Chart Design AlternativesFlag any remote user whose time_received is not current as an exception.This would flag anyone who is out of the office of a day as an exceptionCould set a range for this, but the value would still be arbitraryGenerate a control chartOver time it will reflect the normal variations in the systemWill filter out the chance variation and be more likely to correctly flag the assignable variation

  • Message System Control Chart ImplementationFormulas:UCLX = X + A2R

    LCLX = X - A2R

    X = ( X )/ N

    R = ( R ) /N

  • Message System Control Chart ImplementationUse a database event to capture the daily average latency, range of latency, and record out of control remote users in an exception reportRequires 3 working tables:Control_chart Latency_calculationLatency_Exception_Report

  • Message System Control Chart ImplementationCREATE TABLE control_chart(sample_numberINTDEFAULT AUTOINCREMENT PRIMARY KEY,sample_meanNUMERIC(20,0)NOT NULL,sample_rangeNUMERIC(20,0)NOT NULL,sample_dateDATEDEFAULT now());

  • Message System Control Chart ImplementationCREATE GLOBAL TEMPORARY TABLE latency_calculation(user_idINT PRIMARY KEY,latencyNUMERIC(20,0));

  • Message System Control Chart ImplementationCREATE TABLE latency_exception_report(user_nameCHAR(128),exception_dateDATEDEFAULT now(),latencyNUMERIC(20,0),upper_control_limitNUMERIC(20,0),lower_control_limitNUMERIC(20,0),PRIMARY KEY (user_name, exception_date));

  • Message System Control Chart ImplementationCREATE EVENT populate_control_chartSCHEDULE daily_sampleSTART TIME '01:00AM' EVERY 24 HOURSAT ALLHANDLERBEGINDECLARE grand_meanNUMERIC(20,0);DECLARE average_rangeNUMERIC(20,0);DECLARE a_2NUMERIC(20,3);DECLARE uclNUMERIC(20,0);DECLARE lclNUMERIC(20,0);

  • Message System Control Chart ImplementationMESSAGE 'Firing event "populate_control_chart"';

    SET a_2 = 0.729;//this assumes a sample size of 4 remote users, you may want to use a larger sample sizeINSERT INTO latency_calculation SELECT TOP 4 user_id, (log_sent-confirm_sent) AS latency FROM sys.sysremoteuser;

    INSERT INTO control_chart(sample_mean, sample_range) SELECT avg(latency) AS mean, ( max( latency )-min( latency ) ) AS range FROM latency_calculation;

    TRUNCATE TABLE latency_calculation;

  • Message System Control Chart ImplementationSELECT avg(sample_mean) INTO grand_mean FROM control_chart;SELECT avg(sample_range) INTO average_range FROM control_chart;

    SET ucl = grand_mean + (a_2*average_range);SET lcl = grand_mean - (a_2*average_range);

  • Message System Control Chart ImplementationINSERT INTO latency_exception_report( user_name, latency, upper_control_limit, lower_control_limit) SELECT user_name, ( log_sent - confirm_sent ) AS latency, ucl, lcl FROM sys.sysremoteusersWHERE latency > ucl OR latency < lcl;

    END;

  • TopicsMultiple SubscriptionsMessage System Control ChartSelf-Refreshing Primary Key PoolPassthrough in a Multi-Tier EnvironmentRequest QueueDBRemote and DBXtract ExclusivityLast Chance Threshold

  • Self-Refreshing Primary Key Pool Business RequirementIn a distributed system, the generation and assignment of unique primary key values must be built in to the application.

  • Self-Refreshing Primary Key Pool Design ConsiderationsSince the assignment of a key value must be done consistently regardless of the front-end application the proper place to implement this functionality is in the database.A Primary Key Pool allows you to generate a single column primary key as opposed to a using a composite key.The Global Autoincrement default (introduced in 7.0) may still require refreshing over time.Manual maintenance of a key pool would be an unacceptable risk.

  • Self-Refreshing Primary Key Pool Design ConsiderationsTrigger Actions Dont Replicate! Except:Running DBRemote with the -t switchRunning SSRemoteResult of a RESOLVE UPDATE triggerModification to the current row in a BEFORE triggerAn UPDATE PUBLICATION statementAn update to a SUBSCRIBE BY column that changes ownership of the row

  • Self-Refreshing Primary Key Pool Design AlternativesUse database EVENTs to automate the maintenance of the Primary Key PoolEvents were introduced in ASA 7.0.Events can be triggered by a type of action or they can be scheduledConnectEVERY Can not be used on ASEUse a trigger to maintain the Primary Key PoolTake advantage of the exceptions under which trigger actions will replicate

  • Self-Refreshing Primary Key Pool ImplementationExpenseExpenseKeyPoolExpense 1 SalesRep1Expense 2 SalesRep2Expense 3 SalesRep1

    KeyPoolExpense 1Expense 3Mileage $40.0011 Mileage $40.00Expense 4 NoOneSalesRep1Expense 4

  • Self-Refreshing Primary Key Pool ImplementationRegional Office - Table Definition

    CREATE TABLE KeyPool( table_name VARCHAR(128) NOT NULL, value INTEGER NOT NULL, remote_location VARCHAR(128) NOT NULL, PRIMARY KEY (table_name, value));

  • Self-Refreshing Primary Key Pool ImplementationSalesRep1 - Table Definition

    CREATE TABLE KeyPool( table_name VARCHAR(128) NOT NULL, value INTEGER NOT NULL, PRIMARY KEY (table_name, value));

  • Self-Refreshing Primary Key Pool ImplementationRegional Office - Publication & Subscriptions

    Create Publication Admin_Pub( TABLE KeyPool( table_name, value ) SUBSCRIBE BY ( remote_location ));

    CREATE SUBSCRIPTION TO Admin_Pub('Sales