Diferencias
Muestra las diferencias entre dos versiones de la página.
Ambos lados, revisión anterior Revisión previa Próxima revisión | Revisión previaÚltima revisiónAmbos lados, revisión siguiente | ||
wiki:3.-servidor:3.5.-replicador:e.-selectividad:start [2017/10/31 15:13] – [MASTER_REPLICA_SELECTED] patricia | wiki:3.-servidor:3.5.-replicador:e.-selectividad:start [2019/06/26 13:16] – [Rellenar la Selectividad] ejetoro | ||
---|---|---|---|
Línea 1: | Línea 1: | ||
+ | {{indexmenu_n> | ||
+ | ===== Selectividad ===== | ||
+ | \\ | ||
+ | Por selectividad debemos entender el conjunto de reglas que debemos definir para que los clientes (dispositivos) reciban una base de datos " | ||
+ | En proyectos en los que la base de datos del servidor es grande, esto es incluso obligatorio, | ||
+ | \\ | ||
+ | <WRAP center round important 60%> | ||
+ | A partir de que un proyecto se va a definir con selectividad, | ||
+ | </ | ||
+ | |||
+ | Las tablas que intervienen en la selectividad son: | ||
+ | |||
+ | ^ CAMPO ^ DESCRIPCIÓN | ||
+ | | **ADM_SELECTED_TEMPLATE** | ||
+ | | **ADM_DINAMYC_SELECTED** | ||
+ | | **MASTER_REPLICA_SELECTED** | ||
+ | | **MASTER_REPLICA_SQUEUE** | ||
+ | |||
+ | |||
+ | ==== ADM_SELECTED_TEMPLATE ==== | ||
+ | |||
+ | Esta tabla **NO** define la selectividad directamente, | ||
+ | |||
+ | ^ CAMPO ^ TIPO ^ DESCRIPCIÓN | ||
+ | | **ID** | Autonumérico | | | ||
+ | | **TABLENAME** | ||
+ | | **ALWAYS** | Numérico | ALWAYS=1, se reciben todas las operaciones de la tabla especificada en TABLENAME y se ignora lo que haya definido en CRITERIA, ALWAYS=0, se evalúa la consulta que haya definida en el campo CRITERIA | ||
+ | | **CONDITIONAL** | Numérico | Deprecated. Utilizado en el servidor de réplica anterior a .NET. Cuando ALWAYS=1, CONDITIONAL=0 y cuando ALWAYS=0, CONDITIONAL=1. | ||
+ | | **CRITERIA** | Varchar(4096) | Si el criterio es simple se puede especificar simplemente la condición (P.Ej: | ||
+ | === Ejemplos de CRITERIA en TEMPLATE === | ||
+ | <code sql> | ||
+ | /* Ejemplo de registro de plantilla para la tabla de clientes, a los clientes se le asocia un IDUSUARIO | ||
+ | y al enlazar en ADM_DINAMYC_SELECTED el usuario con el dispositivo, | ||
+ | recibirá los registros que afecten a dicho cliente por estar asociado a ése usuario. | ||
+ | La macro ##MID## la sustituiremos cuando vayamos a rellenar la tabla MASTER_REPLICA_SELECTED. | ||
+ | SELECT c.ROWID FROM gen_clientes c | ||
+ | INNER JOIN adm_dinamyc_selected a ON c.IDUSUARIO=a.IDUSUARIO WHERE a.MID=## | ||
+ | |||
+ | /* En este otro ejemplo, para la tabla de visitas, el dispositivo únicamente recibirá las operaciones de visitas | ||
+ | de los clientes que tienen asociado su IDUSUARIO. */ | ||
+ | SELECT D.ROWID FROM gen_visitas D | ||
+ | LEFT OUTER JOIN gen_clientes C ON D.IDCLIENTE= C.ID | ||
+ | INNER JOIN adm_dinamyc_selected S ON c.IDUSUARIO=S.IDUSUARIO WHERE S.MID=## | ||
+ | </ | ||
+ | |||
+ | <WRAP center round important 90%> | ||
+ | El campo CRITERIA es para especificar la SQL con la condición a cumplir, se pone Varchar(4096) o más, evitar el uso de NTEXT o TEXT en el tipo de dato, pues posteriormente no funcionará la función replace si queremos ejecutar alguna consulta sobre esta tabla reemplazando los valores para insertarlos en la tabla MASTER_REPLICA_SELECTED. | ||
+ | </ | ||
+ | ==== ADM_DINAMYC_SELECTED ==== | ||
+ | Esta tabla contiene la relación entre un USUARIO y un MID (dispositivo). Esta relación se establece cuando se asocia Usuario-Dispositivo en el < | ||
+ | |||
+ | <WRAP center centeralign > | ||
+ | |< 94% 20% 80% >| | ||
+ | ^ 1.- Datos en ADM_DINAMYC_SELECTED | ||
+ | | {{ : | ||
+ | </ | ||
+ | |||
+ | En esta tabla podemos poner otros campos que creamos necesarios para la selectividad de nuestro proyecto, de forma que podemos asociar un dispositivo con un IDZONA o un IDTIPO o con cualquier otra cosa que nos resulte necesaria. | ||
+ | ==== MASTER_REPLICA_SELECTED ==== | ||
+ | Esta tabla es la que define realmente las condiciones de selectividad del proyecto. Si una operación de la tabla MASTER_REPLICA_QUEUE del servidor cumple las condiciones definidas en ésta tabla, dicha operación se inserta en la tabla MASTER_REPLICA_SQUEUE que es la tabla que se mira para saber las operaciones que tienen que descargarse los dispositivos que tienen definida selectividad. | ||
+ | |||
+ | <WRAP center round important 90%> | ||
+ | Si una tabla NO tiene ningún registro definido en la tabla MASTER_REPLICA_SELECTED para un determinado MID (dispositivo), | ||
+ | </ | ||
+ | |||
+ | ^ CAMPO ^ TIPO ^ DESCRIPCION | ||
+ | | **ID** | Autonumérico | | | ||
+ | | **MID** | ||
+ | | **TBL** | ||
+ | | **OPER** | ||
+ | | **CONDITIONAL** | Numérico | Deprecated. Utilizado en el servidor de réplica anterior a .NET. Cuando ALWAYS=1, CONDITIONAL=0 y cuando ALWAYS=0, CONDITIONAL=1. | ||
+ | | **ALWAYS** | Numérico | ALWAYS=1, se reciben todas las operaciones de la tabla especificada en TABLENAME y se ignora lo que haya definido en CRITERIA, con ALWAYS=0 se evalúa la consulta que haya definida en el campo CRITERIA | ||
+ | | **CONSOLIDATE** | Numérico | Deprecated. Anterior al servidor .NET. Campo de sistema para compatibilidad con versiones antiguas del replicador. | ||
+ | | **CRITERIA** | Varchar(4096) | Si el criterio es simple se puede especificar simplemente la condición (P.Ej: | ||
+ | | **CRITERIAPROVISIONNING** (Con 2 N) | Varchar(4096) | **Opcional**. Puede ser utilizado para saltarnos la condición definida para la selectividad en el campo CRITERIA a la hora de provisionar una base de datos. Si este campo está vacío, se coge lo que haya en el campo CRITERIA. <wrap hi>La SQL que se defina en este campo rescataría TODOS los datos de la tabla en cuestión y NO únicamente el ROWID</ | ||
+ | |||
+ | ==== SQLs UTILES ==== | ||
+ | |||
+ | === Rellenar la Selectividad === | ||
+ | Consulta para generar de nuevo la selectividad (MASTER_REPLICA_SELECTED) a partir de la plantilla definida en ADM_SELECTED_TEMPLATE sustituyendo la cadena ##MID## por el MID correspondiente de la tabla MASTER_REPLICA_SLAVE. | ||
+ | <code sql> | ||
+ | truncate table master_replica_selected; | ||
+ | |||
+ | INSERT INTO master_replica_selected (MID, | ||
+ | SELECT S.MID, T.TABLENAME, | ||
+ | FROM master_replica_slave S, adm_selected_template T | ||
+ | WHERE MID>1 ORDER BY MID | ||
+ | |||
+ | /* En caso de que también tengamos CRITERIAPROVISIONNING... */ | ||
+ | INSERT INTO master_replica_selected (MID, | ||
+ | SELECT S.MID, T.TABLENAME, | ||
+ | FROM master_replica_slave S, adm_selected_template T | ||
+ | WHERE MID>1 ORDER BY MID | ||
+ | |||
+ | /* REINICIAR EL SERVICIO DE REPLICA */ | ||
+ | </ | ||
+ | <WRAP center round important 90%> | ||
+ | La consulta anterior vuelve a generar los registros en la tabla MASTER_REPLICA_SELECTED para todos los MID a partir del 1, si previamente había registros en ésta tabla, habría que borrarlos. Tras rellenar de nuevo la tabla de la selectividad, | ||
+ | </ | ||
+ | |||
+ | === Ver registros por recibir === | ||
+ | Consulta para conocer las operaciones que tiene pendientes de descarga por réplica un MID(Dispositivo). Estas operaciones son las que hayan cumplido los criterios de selectividad descritos en la tabla MASTER_REPLICA_SELECTED, | ||
+ | <code sql> | ||
+ | SELECT * | ||
+ | FROM master_replica_queue | ||
+ | WHERE (ID in (select qid from master_replica_squeue where MID=432) | ||
+ | AND 1=(select CONDITIONAL from master_replica_slave where MID=432)) | ||
+ | OR ( | ||
+ | (ID> | ||
+ | AND (0=(select CONDITIONAL from master_replica_slave where MID=432) | ||
+ | OR (select CONDITIONAL from master_replica_slave where MID=432) IS NULL) | ||
+ | ) | ||
+ | OR (ID> | ||
+ | ORDER BY DMID DESC, ID ASC; | ||
+ | </ | ||
+ | <WRAP center round important 90%> | ||
+ | La consulta anterior saca un listado con las siguientes operaciones que tiene pendientes de descargarse un dispositivo, | ||
+ | \\ | ||
+ | Para saber los DMID que tiene un dispositivo por descargarse: | ||
+ | \\ | ||
+ | SELECT * FROM master_replica_queue WHERE ID> | ||
+ | </ |