Voilà un truc tout bête, à connaitre quand on met en place une réplication par fusion.
Symptôme : Je crée une réplication sur un serveur de pré prod, à partir d’un script d’une réplication qui fonctionne sur un serveur de dev.
LE script, généré par le wizard donc, ressemble à quelque chose comme ça :
1: use [TestDB]
2: exec sp_replicationdboption @dbname = N'TestDB', @optname = N'merge publish', @value = N'true'
3: GO
4: -- Adding the merge publication
5: use [TestDB]
6: exec sp_addmergepublication @publication = N'replTest',
7: @description = N'Merge publication of database ''TestDB'' from Publisher ''MIM\SQL2008''.', @sync_mode = N'character', @retention = 14,
8: @allow_push = N'true', @allow_pull = N'true', @allow_anonymous = N'true', @enabled_for_internet = N'false', @snapshot_in_defaultfolder = N'true',
9: @compress_snapshot = N'false', @ftp_port = 21, @ftp_subdirectory = N'ftp', @ftp_login = N'anonymous', @allow_subscription_copy = N'false',
10: @add_to_active_directory = N'false', @dynamic_filters = N'false', @conflict_retention = 14, @keep_partition_changes = N'false',
11: @allow_synctoalternate = N'false', @max_concurrent_merge = 0, @max_concurrent_dynamic_snapshots = 0, @use_partition_groups = null,
12: @publication_compatibility_level = N'90RTM', @replicate_ddl = 1, @allow_subscriber_initiated_snapshot = N'false', @allow_web_synchronization = N'true',
13: @allow_partition_realignment = N'true', @retention_period_unit = N'days', @conflict_logging = N'both', @automatic_reinitialization_policy = 0
14: GO
15:
16:
17: exec sp_addpublication_snapshot @publication = N'replTest', @frequency_type = 4, @frequency_interval = 14, @frequency_relative_interval = 1,
18: @frequency_recurrence_factor = 0, @frequency_subday = 1, @frequency_subday_interval = 5, @active_start_time_of_day = 500,
19: @active_end_time_of_day = 235959, @active_start_date = 0, @active_end_date = 0,
20: @job_login = N'MIM\ReplicationAdmin', @job_password = 'MY_PASSWORD_', @publisher_security_mode = 1
21:
22:
23: use [TestDB]
24: exec sp_addmergearticle @publication = N'replTest', @article = N'Table1', @source_owner = N'dbo', @source_object = N'Table1',
25: @type = N'table', @description = null, @creation_script = null, @pre_creation_cmd = N'drop',
26: @schema_option = 0x000000B208034FF1, @identityrangemanagementoption = N'manual',
27: @force_reinit_subscription = 1, @column_tracking = N'false', @subset_filterclause = null, @vertical_partition = N'false',
28: @verify_resolver_signature = 1, @allow_interactive_resolver = N'false', @fast_multicol_updateproc = N'true', @check_permissions = 0,
29: @subscriber_upload_options = 0, @delete_tracking = N'true', @compensate_for_errors = N'false', @stream_blob_columns = N'false', @partition_options = 0
30: GO
Bref, rien de bien extraordinaire…
Je l’exécute, classique, tout se passe bien et je me dis “tiens allons vérifier si ma table”
Et là c’est le drame, ma table ne contient, ni rowguid, ni triggers !
Le script serait 'il donc moisi ???
Et bien pas du tout !
Les triggers, et autres colonne supplémentaire, bref tous les composants nécessaires à la table, ne seront générés que lors de la création du premier snapshot !
Après lancement du Snapshot Agent :
Voici l’état de ma table
Alors la question simple : Pourquoi ne pas avoir créé les triggers avant ?
Tout simplement, pour des raisons de performances.
Inutile de créer des colonnes, et triggers supplémentaires (et autre procédures stockées systèmes etc …) alors qu’aucun snapshot n’a été généré, aucun abonné n’a demandé à récupérer des informations de la table, bref, aucun intérêt !
Bref, juste une question de gain de performance, bien pensé en somme !