Skip to main content

Snapsync Troubleshooting - Check Snapsync Job History

Display Snapsync job history

Using the top menu in the Delphix administrative console, go to Manage > Dashboard to display the job history...

In the field Filter By Keyword field on the Job History listing, enter a phrase like SnapSync for database "XYZ", where XYZ is the name of the dSource, to find all of the SnapSync (a.k.a. DB_SYNC) jobs for that dSource.  The start and end times for the job will be shown in each entry...

If the job history shows that the SnapSync jobs have had approximately the elapsed time duration as always, then this indicates that nothing has changed recently, which is good information to have when trying to understand the nature of the problem.  If the SnapSync job durations have always been unsatisfactory, then we need to examine how the dSource was setup.

If the job history shows that the SnapSync jobs are taking progressively longer amounts of elapsed time, then this may indicate that the source database is simply growing progressively larger or busier.

If the job history shows a sudden change in the duration of the SnapSync jobs, then that indicates that something may have changed in either the configuration of the Delphix dSource, or that something may have changed in the configuration of the source database or the source environment (i.e. database host/server/cluster).

Measuring Daily Change Rate in an Oracle Database
If the customer is using RMAN, then simply look at the size of the daily incremental dumps. This information is stored in the DB Control File or in the RMAN Catalog. 

One may have to look at several time periods (e.g., one week, one month, one quarter)  to calculate the average daily change rate.The following SQL script demonstrates how to do this.

select to_char(completion_time, 'DD-MON-YY') as "Day",
       round(sum(blocks * block_size)/1024/1024) as "Data Change (MB)",
       to_char(round(avg(blocks*100/datafile_blocks)), '90.99') as  "Percent Data Change"
  from v$backup_datafile bdf
 where nvl(incremental_level, 0) >= 1
group by to_char(completion_time, 'DD-MON-YY')
order by to_date(to_char(completion_time, 'DD-MON-YY'));

Day       Data Change (MB) Percen
--------- ---------------  ------
13-OCT-15            39738   4.00
14-OCT-15           120601   2.00
15-OCT-15           120329   2.00
16-OCT-15           116750   2.00
17-OCT-15            71035   8.00

One possible explanation for a sudden increase in SnapSync timing might be that a recovery was performed on the source database, causing the SnapSync service to perform a "link" (a.k.a. initial snapshot) of the database again.

Another possibility, specifically for Oracle dSources, is that Block Change Tracking (BCT) may have been disabled on the source database.  For more information on this possibility, please check the section below entitled Consider enabling Oracle BCT.

These are not the only possibilities, but knowing when sudden changes happened in the duration of the SnapSync jobs can help you locate what changed in the source database or source environment (i.e. database host/server/cluster).

  • Was this article helpful?