– Look at the volume statistics (after the 1920 error is posted): GLYPH<129> Source volume write throughput after the Global Mirror relationships were stopped. GLYPH<SM590000> Are the storage controllers at the remote system overloaded (performing slowly)? – Adding more or faster physical disks to a RAID array. – Changing the RAID level of the array. – Changing the cache settings of the controller and checking that the cache batteries are  healthy, if applicable. – Changing other controller-specific configuration parameter. GLYPH<SM590000> Are the storage controllers at the primary site overloaded?  If write throughput increases greatly (by 30% or more) after the Global Mirror  relationships are stopped, the application host was attempting to perform more I/O  than the remote link can sustain.  When the Global Mirror relationships are active, the overloaded remote link causes  higher response times to the application host. This overload, in turn, decreases the  throughput of application host I/O at the source volume. After the Global Mirror  relationships stop, the application host I/O sees a lower response time, and the true  write throughput returns. To resolve this issue, increase the remote link bandwidth, reduce the application  host I/O, or reduce the number of Global Mirror relationships. Investigate the primary and remote storage controllers, starting at the remote site. If the  back-end storage at the secondary system is overloaded, or another problem is affecting the  cache there, the Global Mirror protocol fails to keep up. Similarly, the problem exhausts the  ( gmlinktolerance ) elasticity and has a similar effect at the primary system. In this situation, ask the following questions: Use IBM Spectrum Control to obtain the back-end write response time for each MDisk at  the remote system. A response time for any individual MDisk that exhibits a sudden  increase of 50 ms or more, or that is higher than 100 ms, generally indicates a problem  with the back end. In case of 1920 error triggered by the  max replication delay exceeded condition, check the peak back-end write response time to see if it has exceeded the  maxreplicationdelay  value around the 1920 occurrence. However, if you followed the specified back-end storage controller requirements and were  running without problems until recently, the error is most likely caused by a decrease in  controller performance because of maintenance actions or a hardware failure of the  controller. Check whether an error condition is on the storage controller, for example,  media errors, a failed physical disk, or a recovery activity, such as RAID array rebuilding  that uses more bandwidth. If an error occurs, fix the problem and then restart the Global Mirror relationships. If no error occurs, consider whether the secondary controller can process the required  level of application host I/O. You might improve the performance of the controller in the  following ways: Analyze the performance of the primary back-end storage by using the same steps that  you use for the remote back-end storage. The main effect of bad performance is to limit  the amount of I/O that can be performed by application hosts. Therefore, you must monitor  back-end storage at the primary site regardless of Global Mirror.  Chapter 5. Copy services  247 Storage controllers