Picture Perfect 4.6 Enterprise Edition User Manual - UTCFS Global ...
Picture Perfect 4.6 Enterprise Edition User Manual - UTCFS Global ... Picture Perfect 4.6 Enterprise Edition User Manual - UTCFS Global ...
110Picture Perfect 4.6 Enterprise EditionUser Manual15 Will person/badge notes be synchronized? If so, since they were not synchronized inprevious Picture Perfect versions, is there anything special about handling the initialsynchronization?Yes, person/badge notes will be synchronized/replicated with ER.As person/badge notes were independent (not replicated) in previous versions, they would probablyhave same id values on the different hosts. During initial synchronization (hostconfig), the idvalues of the notes records on the different hosts are reset using the sequence number in the rangefor that host. The person/badge notes are then merged and synchronized across the entire system.16 Why is there a new index on tables, which always includes a ifx_replcheck column?This is an Informix ER requirement for the command cdr check to run efficiently. This commandchecks differences in the data on the hosts.17 What is the purpose of the new database spaces (entrepdbs and entrepsbs)?These are new database spaces used by Informix ER to hold transactions when the memory queuefills up and spooling starts. They are sized to 40% of the base database space size. When this spacefills up to 90%, an alarm is generated. Under normal conditions, this should never occur. If it does, itimplies that a host in the ER setup is offline and should be disconnected from ER (by usingercmd.sh). An option also exists within ercmd.sh to extend this database space.18 Why were the new tables host_time and currseq added to the proteus database?The host_time table keeps the times on each of the hosts and is replicated from subhosts to nethost.The nethost has the times of all the hosts. The table is used to determine which subhost is the causeof ER database spaces being filled up.The currseq table ensures that max(id) is not used during inserts of records to the replicating tables.19 Why do chkpptriggers and chkppprocedures list some duplicates, additional triggers,and stored procedures from standalone on the ER system?To ensure the usage of sequence values and prevent usage of max(id) for id values during inserts toreplicating tables, some standalone triggers/stored procedures have been modified and some newones have been added.20 What if I need to make a change to the database during the upgrade?Once the upgrade process has begun, we strongly recommend freezing the database to ensureminimum impact to database synchronization between all servers in the installation.If a change is required during the upgrade, any changes to the database (not related to Historytransactions) must be written down so that they can be applied to the new system once it is up andrunning (replicating, databases synchronized).Usually, person-related data is changed on the nethost (person/badge/category or anything accessrelated), and device-related data (micro/reader/door) is changed on the subhost.If both the old and new systems up and running (that is, both nethosts are running), changes can bemade on both systems without waiting for the upgrade to finish.
Chapter 7FAQs11121 At what point is it not recommended to fall back to Picture Perfect 4.0?A fallback to the old version is not recommended when the nethost and the first subhost are installed,their databases are completely synchronized, and the micros start communicating with the subhost.The following scenarios illustrate how a fallback could be managed:A. Existing Picture Perfect 4.0 production servers are upgradedIf the existing Picture Perfect 4.0 servers match the minimum system requirements for PicturePerfect 4.6 and the end user plans to use them for the upgrade, the database must be convertedon the production servers. Once the conversion is done, the database is no longer functional in aPicture Perfect 4.0 environment. If a fallback to version 4.0 is needed, it may be necessary toreinstall the operating system and Picture Perfect 4.0 software on the production servers.In this scenario, we recommend a fallback to version 4.0 before upgrading the first subhost.B. Spare servers are available for database conversion; existing servers are upgradedWhen spare servers are available, the database can be converted and validated on the spareservers before reinstalling the production servers. The old system continues to control theEnterprise installation during the conversion process. The conversion will not damage theproduction servers.In this scenario, a fallback is not recommended after the production nethost and first subhost areconfigured and the databases are synchronized.C. New servers are provided; spare servers are not available for database conversionThis scenario is similar to scenario A, except that the old Picture Perfect 4.0 servers are stillavailable and can be brought back online easily by performing a drop-reload of the database.The OS does not need to be reinstalled.In this scenario, a fallback is not recommended after the new nethost and first subhost areconfigured, the databases are synchronized, and the micros start communicating with the newsubhost.22 Can I add an existing Picture Perfect standalone server as a subhost?An existing Picture Perfect Standalone server cannot be migrated easily to a Picture PerfectEnterprise 4.6 system. The main constraint is that the global tables must be synchronized with thenethost. For global tables, the standalone may have already used same range of record ids withdifferent data, which can cause loss of records when the tables are synchronized with the nethost(master).In this case, please contact UTC Fire & Security Enterprise Consulting to estimate the work requiredto merge the data from the Picture Perfect standalone server in the Enterprise Replication system.
- Page 68 and 69: 60Picture Perfect 4.6 Enterprise Ed
- Page 70 and 71: 62Picture Perfect 4.6 Enterprise Ed
- Page 72 and 73: 64Picture Perfect 4.6 Enterprise Ed
- Page 74 and 75: 66Picture Perfect 4.6 Enterprise Ed
- Page 76 and 77: 68Picture Perfect 4.6 Enterprise Ed
- Page 78 and 79: 70Picture Perfect 4.6 Enterprise Ed
- Page 80 and 81: 72Picture Perfect 4.6 Enterprise Ed
- Page 82 and 83: 74Picture Perfect 4.6 Enterprise Ed
- Page 84 and 85: 76Picture Perfect 4.6 Enterprise Ed
- Page 86 and 87: 78Picture Perfect 4.6 Enterprise Ed
- Page 88 and 89: 80Picture Perfect 4.6 Enterprise Ed
- Page 90 and 91: 82Picture Perfect 4.6 Enterprise Ed
- Page 92 and 93: 84Picture Perfect 4.6 Enterprise Ed
- Page 94 and 95: 86Picture Perfect 4.6 Enterprise Ed
- Page 96 and 97: 88Picture Perfect 4.6 Enterprise Ed
- Page 98 and 99: 90Picture Perfect 4.6 Enterprise Ed
- Page 100 and 101: 92Picture Perfect 4.6 Enterprise Ed
- Page 102 and 103: 94Picture Perfect 4.6 Enterprise Ed
- Page 104 and 105: 96Picture Perfect 4.6 Enterprise Ed
- Page 106 and 107: 98Picture Perfect 4.6 Enterprise Ed
- Page 108 and 109: 100Picture Perfect 4.6 Enterprise E
- Page 110 and 111: 102Picture Perfect 4.6 Enterprise E
- Page 112 and 113: 104Picture Perfect 4.6 Enterprise E
- Page 114 and 115: 106Picture Perfect 4.6 Enterprise E
- Page 116 and 117: 108Picture Perfect 4.6 Enterprise E
- Page 120 and 121: 112Picture Perfect 4.6 Enterprise E
- Page 122 and 123: 114Picture Perfect 4.6 Enterprise E
- Page 124 and 125: 116Picture Perfect 4.6 Enterprise E
- Page 126: 118Picture Perfect 4.6 Enterprise E
Chapter 7FAQs11121 At what point is it not recommended to fall back to <strong>Picture</strong> <strong>Perfect</strong> 4.0?A fallback to the old version is not recommended when the nethost and the first subhost are installed,their databases are completely synchronized, and the micros start communicating with the subhost.The following scenarios illustrate how a fallback could be managed:A. Existing <strong>Picture</strong> <strong>Perfect</strong> 4.0 production servers are upgradedIf the existing <strong>Picture</strong> <strong>Perfect</strong> 4.0 servers match the minimum system requirements for <strong>Picture</strong><strong>Perfect</strong> <strong>4.6</strong> and the end user plans to use them for the upgrade, the database must be convertedon the production servers. Once the conversion is done, the database is no longer functional in a<strong>Picture</strong> <strong>Perfect</strong> 4.0 environment. If a fallback to version 4.0 is needed, it may be necessary toreinstall the operating system and <strong>Picture</strong> <strong>Perfect</strong> 4.0 software on the production servers.In this scenario, we recommend a fallback to version 4.0 before upgrading the first subhost.B. Spare servers are available for database conversion; existing servers are upgradedWhen spare servers are available, the database can be converted and validated on the spareservers before reinstalling the production servers. The old system continues to control the<strong>Enterprise</strong> installation during the conversion process. The conversion will not damage theproduction servers.In this scenario, a fallback is not recommended after the production nethost and first subhost areconfigured and the databases are synchronized.C. New servers are provided; spare servers are not available for database conversionThis scenario is similar to scenario A, except that the old <strong>Picture</strong> <strong>Perfect</strong> 4.0 servers are stillavailable and can be brought back online easily by performing a drop-reload of the database.The OS does not need to be reinstalled.In this scenario, a fallback is not recommended after the new nethost and first subhost areconfigured, the databases are synchronized, and the micros start communicating with the newsubhost.22 Can I add an existing <strong>Picture</strong> <strong>Perfect</strong> standalone server as a subhost?An existing <strong>Picture</strong> <strong>Perfect</strong> Standalone server cannot be migrated easily to a <strong>Picture</strong> <strong>Perfect</strong><strong>Enterprise</strong> <strong>4.6</strong> system. The main constraint is that the global tables must be synchronized with thenethost. For global tables, the standalone may have already used same range of record ids withdifferent data, which can cause loss of records when the tables are synchronized with the nethost(master).In this case, please contact UTC Fire & Security <strong>Enterprise</strong> Consulting to estimate the work requiredto merge the data from the <strong>Picture</strong> <strong>Perfect</strong> standalone server in the <strong>Enterprise</strong> Replication system.
Change language