Abstract: Implementations include a first application server interacting with a first infrastructure table of a first version through a first access schema, providing, during an upgrade, a second application server to execute a portion of the upgrade by interacting with data schema through the first access schema, adjusting a structure of a second infrastructure table to provide an adjusted structure, the structure of the first version and the adjusted structure of the second version, the second infrastructure table including a copy of the first infrastructure table, providing a second access schema of the second version, providing a third application server configured to interact with data schema through the second access schema, and activating, by the third application server using an activator of the second version, objects of the second version, the activator including features that are different than an activator of the first version.

Abstract: Implementations include providing, by a deploy tool, clone data components in the first database system, each clone data component being a copy of a data component, defining, by the deploy tool, a source-side green access schema in the first database system, the green access schema providing views to the clone data components, providing, by a replication system and based on statements received from the deploy tool, consumer-side clone data components in the first database system, each consumer-side clone data component being a copy of a respective data component, defining, by a replication system and based on statements received from the deploy tool, a consumer-side green access schema in the first database system, the green access schema providing views to the source-side clone data components, and, during execution of the upgrade, replicating, by a handler of the replication system, data from at least one source-side data component to a consumer-side component.

Abstract: Methods, systems, and computer-readable storage media for deploying upgrade packages during zero downtime upgrade of production systems include actions of receiving an upgrade package, the upgrade package defining one or more changes to be deployed to a system that has already undergone partial deployment during a zero downtime upgrade, and including one or more objects having respective object types, receiving a deployment configuration, the deployment configuration providing a plurality of lists of object types for respective constraints and, for each list of object types, specifying a deployment option for object types in the respective list of object types, determining a set of object types included in the upgrade package, the set of object types comprising one or more object types, and selectively permitting deployment of the upgrade package to execute the one or more changes based on the set of object types and the plurality of lists of object types.

Abstract: Implementations include providing, by a deploy tool, clone data components in the first database system, each clone data component being a copy of a data component, defining, by the deploy tool, a source-side green access schema in the first database system, the green access schema providing views to the clone data components, providing, by a replication system and based on statements received from the deploy tool, consumer-side clone data components in the first database system, each consumer-side clone data component being a copy of a respective data component, defining, by a replication system and based on statements received from the deploy tool, a consumer-side green access schema in the first database system, the green access schema providing views to the source-side clone data components, and, during execution of the upgrade, replicating, by a handler of the replication system, data from at least one source-side data component to a consumer-side component.

Abstract: Various techniques are described for precisely locking database objects within a database during a system upgrade with the use of database freeze triggers. Some database freeze triggers can be utilized to lock transport requests while other database freeze triggers can be utilized to lock database objects such as exchange tables. For transport requests, techniques describe the use of a whitelist identify transport objects or transport object types which shall remain unblocked. As a result, a database freeze trigger can be generated for transport objects or transport object types that are not included in the whitelist. For database objects, techniques describe the identification of a tool or service which has been allowed during the upgrade. Database objects which can be modified during execution of the tool or service can be identified. Database freeze triggers can be generated for the database objects besides those identified.

Abstract: A zero downtime upgrade procedure is initiated that upgrades a first version of software executing on a source system comprising at least one source server to a second version of software executing on a target system comprising at least one target server. The source system initially starts operating in a read-write mode. Thereafter, concurrent with the operation of the source system, operation of the target system is initiated in a read-only mode. Operations of the source system are then ceased by ramping down activities of the source system. Upon cessation of operation of the source system, operation of the target system is initiated in a read-write mode.

Abstract: A zero downtime upgrade of a source system to a target system is initiated. The source system and the target system operate in a first database layer and a second database layer. Thereafter, differences in structure and/or database type are computed between a source table in the source system and a target table in the target system in each of the two different database layers. The data is then migrated, using the computing differences and in the second database layer, from the source table to the target table. The upgrade procedure is later terminated after completion of the migration of the data. Related apparatus, systems, techniques and articles are also described.

Abstract: Continuous access to an application and associated data is provided during a modification (for example, an upgrade) of the application. Shared tables are used to perform parallel changes in databases associated with an original database schema, a temporary database schema, and an upgraded database schema. Aliases are used to access shared tables from some database schemas. The use of shared tables obviates a separate merging of data written by different tools and/or systems during an upgrade of the application. Related methods, apparatuses, systems, techniques and articles are also described.

Abstract: Methods, systems, and computer-readable storage media for deploying upgrade packages during zero downtime upgrade of production systems include actions of receiving an upgrade package, the upgrade package defining one or more changes to be deployed to a system that has already undergone partial deployment during a zero downtime upgrade, and including one or more objects having respective object types, receiving a deployment configuration, the deployment configuration providing a plurality of lists of object types for respective constraints and, for each list of object types, specifying a deployment option for object types in the respective list of object types, determining a set of object types included in the upgrade package, the set of object types comprising one or more object types, and selectively permitting deployment of the upgrade package to execute the one or more changes based on the set of object types and the plurality of lists of object types.

Abstract: The present disclosure describes methods, systems, and computer program products for providing multi-level user interface theming.

Abstract: A zero downtime upgrade procedure is initiated that upgrades a first version of software executing on a source system comprising at least one source server to a second version of software executing on a target system comprising at least one target server. The source system initially starts operating in a read-write mode. Thereafter, concurrent with the operation of the source system, operation of the target system is initiated in a read-only mode. Operations of the source system are then ceased by ramping down activities of the source system. Upon cessation of operation of the source system, operation of the target system is initiated in a read-write mode.

Abstract: Various techniques are described for precisely locking database objects within a database during a system upgrade with the use of database freeze triggers. Some database freeze triggers can be utilized to lock transport requests while other database freeze triggers can be utilized to lock database objects such as exchange tables. For transport requests, techniques describe the use of a whitelist identify transport objects or transport object types which shall remain unblocked. As a result, a database freeze trigger can be generated for transport objects or transport object types that are not included in the whitelist. For database objects, techniques describe the identification of a tool or service which has been allowed during the upgrade. Database objects which can be modified during execution of the tool or service can be identified. Database freeze triggers can be generated for the database objects besides those identified.

Abstract: A temporary system is described to provide, during an upgrade of an application implemented using an original system, a continuous access to the application. A copy of a first data-set characterizing a first version of the application is generated on the temporary system when the upgrade becomes available. A selective access to the copy on the temporary system is enabled while preventing access to the first data-set on an original system. The first data-set on the original system is upgraded to form a second data-set characterizing a second version of the application, and a testing of the second data-set is performed. When a result of the testing indicates that the second data-set should be implemented, an access to the second data-set on the original system is enabled while preventing access to the copy on the temporary system. Related methods, apparatus, systems, techniques and articles are also described.

Abstract: A zero downtime upgrade procedure upgrading a source system to a target system is initiated that prepares software for the target system in parallel to the operation of the source system. As part of the upgrade procedure, source tables of the source system are renamed. Thereafter, the renamed source tables are cloned for the target system. Further, the renamed source tables are equipped with database triggers to transfer data from the renamed source tables to the cloned tables used by the source system according to a source database schema. Next, the target tables are generated that include updated software content for later use by the target system while the source tables are used via a bridge database schema. Tables can then be shared between the source database schema accessed via the bridge database schema and the target system.

Abstract: The subject matter described herein relates to providing a continuous access to a database at times, including when the database is being modified or upgraded. Initially, access to an old version of a table is enabled and provided to a user. A copy of the old version is generated. Access is asynchronously redirected from the old version to the copy of the old version. A new version of the table is generated by modifying the structure of the first version of the table. The copy of the old version is accessible when the database is being modified or upgraded. When the structure is being modified, access is asynchronously redirected from the copy of the old version to the new version.

Abstract: Techniques for migrating data in a database include identifying an update to one or more data entries of a source table; determining that a status of a trigger associated with the source table indicates to update a logging table, and in response: updating, in a first transaction, (i) the one or more data entries of the source table, and (ii) one or more data entries of the logging table based on the user input, and copying content of the source table to a target table; and determining that the status indicates to update the target table, and in response: updating, in a second transaction, (i) the one or more data entries of the source table and (ii) one or more data entries of the target table based on the user input, and updating the content of the target table based on the one or more data entries of the logging table.

Abstract: Revocation of a zero downtime upgrade of an upgrade procedure of a source system to a target system is initiated. Thereafter, upgrade activities are stopped at the target system and production activities are stopped at the source system. At least a portion of the target tables can be subsequently dropped and any associated table structure changes can be revoked. At least a portion of the target tables are then switched from use by the target system to use by the source system. Next, the source system is connected to the source database schema to enable use of the source system in its state prior to the initiation of the upgrade procedure. Related apparatus, systems, techniques and articles are also described.

Abstract: A zero downtime upgrade procedure upgrading a source system to a target system is initiated that prepares software for the target system in parallel to the operation of the source system. As part of the upgrade procedure, source tables of the source system are renamed. Thereafter, the renamed source tables are cloned for the target system. Further, the renamed source tables are equipped with database triggers to transfer data from the renamed source tables to the cloned tables used by the source system according to a source database schema. Next, the target tables are generated that include updated software content for later use by the target system while the source tables are used via a bridge database schema. Tables can then be shared between the source database schema accessed via the bridge database schema and the target system.

Abstract: Revocation of a zero downtime upgrade of an upgrade procedure of a source system to a target system is initiated. Thereafter, upgrade activities are stopped at the target system and production activities are stopped at the source system. At least a portion of the target tables can be subsequently dropped and any associated table structure changes can be revoked. At least a portion of the target tables are then switched from use by the target system to use by the source system. Next, the source system is connected to the source database schema to enable use of the source system in its state prior to the initiation of the upgrade procedure. Related apparatus, systems, techniques and articles are also described.

Abstract: A zero downtime upgrade of a source system to a target system is initiated. The source system and the target system operate in a first database layer and a second database layer. Thereafter, differences in structure and/or database type are computed between a source table in the source system and a target table in the target system in each of the two different database layers. The data is then migrated, using the computing differences and in the second database layer, from the source table to the target table. The upgrade procedure is later terminated after completion of the migration of the data. Related apparatus, systems, techniques and articles are also described.