## 2.7 Secondary System Usage
In system replication landscapes, you can run other systems (for example, DEV, QA systems, or even productive systems) on the secondary system's hardware while the primary system is in production.
## Recommendations
When running other systems on the secondary system's hardware, keep in mind the following recommendations:
- We recommend using a separate storage infrastructure for each system. Since the secondary system requires the same I/O capacity as the primary, the additional systems could have a negative impact on the secondary's I/O.
- The SIDs and instance numbers used for the additional systems running on the secondary hardware must be different from the system replication SID.
- The &lt;instance number&gt;+1 of the productive system must not be used and must be free on both sites, because this port range is used for the system replication communication.
- To save memory resources, switch off the preload of tables on the secondary system using global.ini/ [system\_replication]-&gt; preload\_column\_tables=false .
The takeover process will take longer as no data is preloaded to memory on the secondary system.
- The available memory on the secondary system's hardware must be shared among the systems running there. However, the secondary system should receive the amount of memory it needs. Only the remaining memory can be shared among the DEV or QA systems.
- To allocate memory for every system running on the secondary's hardware, set the global allocation limit for each system using global.ini/[memorymanager]-&gt; global\_allocation\_limit .
- If there are not enough resources to handle the load of all systems, the additional systems running on the secondary need to be shut down in case of a takeover.
- You can change the global.ini on the secondary accordingly and then activate the change with hdbnsutil -reconfig because no SQL is possible in this state.
## Resources required on the secondary system
When planning to run other systems on the secondary system, you need to consider the available hardware resources, the table preload option ( preload\_column\_tables ), and the memory ( global\_allocation\_limit ) needed by the secondary system.
The tables below describe these requirements for each combination of table preload and operation mode:
Operation Mode: delta\_datashipping
## Preload Memory needed for the secondary system (global\_allocation\_limit)
On Set the global\_allocation\_limit to the same value as the memory available on the primary system.
## Off minimum 64 GB
or row store size + 20 GB (if this sum is higher)
Determine the row store size with the following statement:
select host, round (sum(page\_size*USED\_BLOCK\_COUNT)/1024/1024/1024,2) as "RowStore Size GB" from m\_data\_volume\_page\_statistics where page\_sizeclass = '16k-RowStore' group by host;
If this limit is not set, the SAP HANA database on the secondary system uses as much memory as it can get and possibly takes it away from the DEV/QA systems, which could run into out-of-memory.
##  Note
If the row store size of the primary system grows during operation, it might become necessary to increase the global\_allocation\_limit on the secondary system.
Operation Mode: logreplay
## Preload Memory needed for the secondary system (global\_allocation\_limit)
On Set the global\_allocation\_limit to the same value as the memory available on the primary system.
Off size of loaded column tables (in-memory) + row store size + 50 GB
Determine the size of the loaded column tables (in-memory) with this SQL statement:
select round(sum(memory\_size\_in\_total)/1024/1024/1024) size\_GB from m\_cs\_tables;
##  Note
If the row store size of the primary system grows during operation, it might become necessary to increase the global\_allocation\_limit on the secondary system.
Operation Mode: logreplay\_readaccess
## Preload Memory needed for the secondary system (global\_allocation\_limit)
- On Set the global\_allocation\_limit to the same value as the memory available on the primary system.
##  Note
Read access on the Active/Active (read enabled) secondary system requires additional CPU capacity.
- Off Set the global\_allocation\_limit to the same value as the memory available on the primary system.
##  Note
This load option reduces the required memory size for the Active/Active (read enabled) secondary thanks to tables which are used read-only in the primary system. However, read access on the Active/Active (read enabled) secondary system requires additional CPU capacity.
All resources that are not needed by the secondary system can be used to run further systems on the secondary. These resources must be granted to them by explicitly setting the global allocation limit.
For more information on multiple SAP HANA systems running productively on one host, see SAP Note 1681092 .
The note also provides information about the cross replication possibility of two systems with two hosts.
## Related Information
<!-- image -->
SAP Note 1681092