Security Expert Data Sync Log Error 'Failed to GetTableSchema' and Server memory configuration

[Alan_Wood]

Warning

Potential for Data Loss: The steps detailed in the resolution of this article may result in a loss of critical data if not performed properly. Before beginning these steps, make sure all important data is backed up in the event of data loss. If you are unsure or unfamiliar with any complex steps detailed in this article, please contact Product Support for assistance.

Issue

Security Expert Data Sync Service is randomly crashing and there is an error 'Failed to GetTableSchema' in the DSS Log

Product Line

Security Expert

Environment

• Security Expert Application Server
• Security Expert Data Sync Service
• Microsoft Windows
• IIS

Cause

Memory may be consumed by IIS over time and crashes data sync service once the total memory approaches Microsoft's 4 GB limitation for 32-bit applications.

Resolution

There are a few items that can be configured in Data Sync Service (DSS) and in IIS to manage memory consumption which will prevent application crashes and DSS from not importing .csv contents

1. Removal of additional table references 
   Removal of these tables in the Settings.xml configuration file located in the C:\Program Files (x86)\Schneider  Electric\Data Sync Service will stop the Security Expert application event view errors from posting.
   Here is what is seen in the SX application event view.
   Each event will represent a different table.  The below example shows the Salto Calendars
   1. Make a backup copy of the settings.xml file
   2. Copy the settings.xml to a temp folder
   3. Edit the settings.xml in the temp folder using Notepad++ Admin mode and remove all unnecessary rows just below the <DataMapping> section.
      <RecordType238...
      <RecordType225...
      
      The example below removes all entries except *Users
      Before:
      
      After:
      
   4. Save the file
   5. Copy the settings.xml from the temp folder into the C:\Program Files (x86)\Schneider Electric\Data Sync Service  folder and select the Replace option (This ensures the older settings.xml file is overwritten)
   6. Close the DSS application and restart it.
      
      When the new settings.xml file is being used only *Users will have an asterisk in DSS.
      
      Also, as a result of this change, the errors in the SX application log will stop posting and no longer consume "extra" resources.
      
2. Increase the IIS Worker Processes from 1 to 4
   1. Open IIS Manager
   2. Select Application Pools
   3. Select DefaultAppPool
   4. Select Advanced Settings
   5. Change the Worker Process from 1(default) to 2, 3 or 4
      (In at least one case, R&D recommended setting this to 4 in order to spread the processes and memory out)
   6. Select Recycle in the right-hand pane
      
3. Recycling Condition Workers
   IIS by default sets application pool(s) to recycle after an interval of 29 hours (1740 minutes).
   This can cause issues when using in-memory sessions.
   Example: DSS application crashing about every 28 hours. Memory was being accumulated over such a long period without being recycled. Recycling every 8 hours reduces the time the memory accumulates. This setting is like a  Windows reboot, but specific to an application pool.
   1. Open IIS
   2. Go to Application Pools, select DefaultAppPool. In the right-hand pane select Recycling.
   3. Change Regular time intervals (in minutes) from 1740(29 hours) to 480 (8 hours)
   4. Click Next, Finish
   5. Select Recycle

Summary:

Making these changes will reduce the memory consumption that increases over time for the Data Sync Service application and prevent crashing of the application.