␡
- Synchronization Methods
- Synchronization Command
- Synchronization Internals
- Synchronization Performance and Troubleshooting
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Synchronization Internals
To learn the internals of the synchronization feature, you can monitor your source and target servers using SQL Profiler (and, optionally, Filemon utility). The process can be summarized as follows:
- SSAS acquires an exclusive lock on the source instance. This is implemented by an explicit BEGIN TRANSACTION command within the database being synchronized. This transaction will prevent any schema or data changes in the source database.
- SSAS traverses database metadata on source and target instances to detect the differences: the list of files that need to be transferred to ensure that two databases are identical. This phase of synchronization, often referred to as the compare phase, used to be very slow when using SSAS 2005, particularly with databases that had a large number of files. The compare phase has been improved dramatically in 2008 and later versions. Compare phase evaluates the version number and size of each file to determine whether it has changed since the last sync.
- Once SSAS has the list of necessary files, Profiler will report "synchronization started" on the target server, and files will be copied, one at a time, from the source database folder into a temporary folder created on the target instance. SQL Profiler will display the full path and name of each file being transferred, along with the file's size; for example:
\\?\C:\Program Files\Microsoft SQL Server\MSAS10_50.R2QUERYINSTANCE\OLAP\Data\353E78AF53D4B389BE7\Adventure Works DW.0.db\0.CryptKey.bin; Size=0KB
The temporary folder will have a name consisting of a globally unique identifier (GUID); in the example above, the temporary folder is called 353E78AF53D4B389BE7. Browse the contents of this folder to see the structure of the files and directories being copied from source to target database. Note that synchronization's file copy phase is single-threaded. When copying a large file over a slow network, this might lead you to suspect a problem; synchronization might appear to "hang" because the Profiler won't report file copy operations for a while. In fact synchronization is not hung, but is waiting for the large file's copy to finish before proceeding to copy the next file. - Once all updated files are copied from source database into the temporary folder, SSAS will copy any missing files from an existing target database folder to the temporary folder. SQL Profiler reports "Synchronization finished" to indicate completion of file copy phase. At this point, the temporary folder will have every single file (and no other extraneous files) that exists on the source instance. Note that if any files exist in the target database do not exist in the source, synchronization will delete them. Suppose the source instance "A" has 10 partitions and you happened to create the 11th partition on the target instance "B". Next we synchronize from instance A to instance B — the 11th partition will be removed — synchronization does not have an option to keep files that only exist on the target instance.
- Analysis Services performs a final check to ensure synchronization target folder's metadata is valid. This is done by checking file version numbers and comparing to version numbers in the master.vmp (version map) file. If all is well, the synchronization command is committed, otherwise it is rolled back. The existing target database folder containing an obsolete copy of the database is deleted; next, the temporary folder is renamed to the database identifier. In case you were not aware, each SSAS object has a name and identifier that may or might not be identical to each other. Note that SSAS will increment the database version number on the target instance; version numbers are appended to the database folder name. During this phase, no one can query the target database because synchronization acquires a write commit lock on it. The commit phase is normally very short.
- SSAS releases the exclusive lock on the source instance. This is implemented through an explicit ROLLBACK TRANSACTION command.