How do Custom Objects and Custom Field Deployments work?
Custom Objects, Custom Fields
November 2010 and newer
Quick Overview of Custom Object & Custom Field Deployments
In order to create a new Custom Object or Custom Field (CO, CF), or to update an existing one, there must be changes made to the schema of the database. Ordinarily, this would require taking a site down so that each affected row can be updated in order to prevent massive deadlocks, and other major issues.
We have a system where there are multiple servers that work in tandem, allowing changes to be made on one server, while the other can continue to be live. Once all the updates have been made to the 2nd server, the system can "failover" (move to) to it. This is to prevent the downtime your site would otherwise experience every time a schema change is made.
While this setup has significant advantages -such as allowing database schema changes on a live site with no down time- there are some sacrifices that have to be made in order for this to work. One drawback is that our replication servers must also be completely updated with the changes before failover can occur. The reason for this is that if the underlying schema on the replication database differs from the production database, it is impossible for replication to accurately reflect production. See the following link for Information on different database types used for reporting.
If you make numerous changes to custom objects that you later choose not to deploy, you can roll back the changes and the custom objects will revert to the state they were in at the time of the previous deployment (if the custom objects have never been deployed, all custom objects are removed). Once an object is deployed there is not an option to rollback the deployment, instead you must manually revert those modifications and redeploy. The rollback option only refers to changes made within the editor that have yet to be deployed.
The exact amount of time that a given deployment will take is not possible to predict and it can be normal for the changes to take anywhere from a few hours to a few days depending on the processes currently on the server. A few factors that impact deployment times are listed below (Note this is not a comprehensive list):
- Size of your database
- Number of changes being deployed
- Amount of traffic to your Oracle Service Cloud support site during deployment
- Type of changes being deployed
The best practice for planning your Custom Object deployments is to schedule it for off hours, i.e. when your site is experiencing less traffic than peak times. If you believe a deployment is taking abnormally long, please submit a service request to Technical Support for review.
The size of the database and traffic to your site can be found by logging into the Oracle Service Cloud VCIO Cloud Service, Answer ID 4192: Oracle Service Cloud VCIO Cloud Service.
For more information on Custom Objects, see:
- Creating Custom Objects
- Creating Indexes on a custom object
- Custom Object deployment error: Deployments are currently disabled ...
Depending on the size of the table you are modifying (e.g.: number of incidents and/or contacts on your site), adding custom fields can take some time to complete. However, after several hours, if the CX console still says that the custom field is stuck in creation, then you may wish to submit a service request to Ask Technical Support.
For more information on Custom Fields, see:
- Adding custom fields
- Error adding/editing custom fields or custom objects: The following table(s) have exceeded the maximum row size.
The best practice for planning your Custom Field deployments is to schedule it for off hours, i.e. when your site is experiencing less traffic than peak times as it can cause table locks which can interfere with site operation.