2 Replies Latest reply on Jun 26, 2017 9:21 AM by Ed Juarbe

    Running Responder 24/7

    Ed Juarbe

      Hi-

       

      I am again reaching out this user community to get some advice, thought, or feedback regarding how we can get our Responder clients closer to a 24/7 up time.

       

      Let me begin by stating that I understand there are many solutions out there to get to that point, some of which are not options for us due to cost and other considerations.  So am before detailing the issues we are experiencing, I'll try to describe our current infrastructure, and what some of the issues are that we are experiencing, keeping in mind that unless there is some cost effective adjustment to our current infrastructure, I mostly trying to find suggestions that will fit within our current infrastructure.

       

      Current Infrastructure:

      Our utility company is a small one geographically. However, we own and maintain Electric, Gas, Water, Sewer, and a small Fiber network, all are on an enterprise geodatabase, but only the electric and fiber is using ArcFM.  Our servers are VMs running on VMware.  We have separate ArcSDE/ArcFM servers for our GIS data and Responder.  Our Control Room clients run on Windows 7 desktops.  Finally, we currently use Veeam system for our server backups (it's importance will be explained later).

       

      The issues we have are two-fold:

       

      Firstly, we recently realized that ArcMap has a known bug in it whereby any disruption between any features in the map and the database server will fire off an error.  The disruption can be a very short duration, and in some cases occurs in under 1 second.  The only way to get by this is to restart ArcMap.  As long as the connection to the data is restored by the time ArcMap reopens, all data connection work as expected...until the next disruption.

       

      Secondly, out Veeam backup system includes a job to perform a full server backup which not only disrupts the connection to the GIS data, but also breaks connection to the Responder server, which results in the services to stop.  We do have a nightly server job that restarts the service, and are able to launch the restart job at the exact time the server backups complete.  However, this does not alleviate the end user from needing to restart ArcMap.

       

      The combination of these two issues is that we can anticipate our control room operators (and other users) to need to restart ArcMap once a day, which would not be acceptable during a storm event.

       

      So, given this information, does anyone have any solutions or recommendations on how you handle the ArcMap disconnects.  Anyone using Veeam successfully, or other backup solutions that just works without disrupting the data connections? Finally, as mentioned, I understand there are many solutions ranging from setting up fail over server and such, but these would not be something I can entertain, so would request limiting suggestions that would fit our current infrastructure.

       

      Thanks in advance for your suggestions and comments.

        • Re: Running Responder 24/7
          David Miller

          Ed,

           

          Are you running ArcSDE as an application server?  Or are you utilizing direct connect to your database?  Either way, you should be able to increase the TNS timeout on your database to keep connections alive longer.  We run 24/7 and rarely experience a dropped connection unless our network totally hiccups.

            • Re: Running Responder 24/7
              Ed Juarbe

              David-

               

              Thanks for the feedback.  Correct me if I'm wrong, but I think the TNS timeout is for Oracle, we're a SQL shop, but I do realize there are similar timeout settings present in SQL as well.

               

              I was actually hoping to explore is any other users have experienced similar timeouts (maybe similar behaviors with backup software or connection drop outs, and have found any way to keep ArcMap happy without resorting to restart.