Skip to end of metadata
Go to start of metadata

General

  • Ensure that the database(s) are supported per Oracle's supported environments matrix
  • Check that the tablespaces have plenty of available disk space. The tablespace behind the CA schema in particular needs plenty of extra space because the data is versioned
  • Ensure that there are database-level alerts in place to warn of problems, like blocking sessions
  • Verify that the schema owner/app user passwords have been changed. A password that's the same as the login (schema name) is not sufficient!
  • Ensure that there are frequent backups taken of all schemas. It's best to do continual backups to an off-site database
  • Ensure that all constraints are named. A constraint with a name of "SYS_C0025223" doesn't make for very fun debugging
  • Verify that the database can handle all of the connections that the application could create to it. Look at the max size of each connection pool
  • Ensure that no indexes are missing that could lead to deadlocks. Deadlocks can be caused by the absence of an index on a table that references another table. All databases require that a table have an index on a column that references another table by way of a foreign key
  • Make sure to clean up any remaining test data. For instance, test users/orders are often created during load testing
  • Ensure that the character encoding is the same across all databases, preferably a flavor of UTF-8 (AL32UTF8 in the case of Oracle)
  • Verify that failover testing has been performed - both within a single clustered database (e.g. killing specific nodes), and across databases (in the case of Data Guard or GoldenGate)
  • If you're using MSSQL, verify that you are using read commited snapshot isolation. See product documentation. This is not just for performance - it's actually required to prevent deadlocks 

Oracle Database

  • Verify that NLS_LENGTH_SEMANTICS is 'char' across all databases. If it's 'byte' you never know exactly how many characters a given column can handle. If it's 'char,' you know
  • Ensure that all ConText indexes in the catalog schemas are created in the following manner: CREATE INDEX SCHEMA.INDEX_NAME ON SCHEMA.TABLE (COLUMN) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS('SYNC (every "sysdate+(1/24)")');. Note the sync parameter. That prevents these indexes from rebuilt after every commit
  • If using logical standby in Oracle, make sure that the versioned schema is in its own database and that logical standby isn't being used on that database

Oracle RAC Database

  • Consider using SCAN for the read-only data
  • Consider binding core schema connections to one RAC node as described in this article. Always best to cut down on the interconnect traffic
  • In the JDBC URL aka "Connection String" ensure all nodes are listed or a properly configured SCAN address is in use
  • If using WebLogic, use GridLink data sources
  • Be very very careful when setting up RAC Extended Distance Clusters. It requires special expertise, a lot of time for testing, and patience. Try an active/passive database tier with Data Guard instead

Oracle JDBC Driver

  • Ensure that the JDBC drivers are supported per Oracle's supported environments matrix. Manually open the manifest files of the JDBC driver JAR file to verify
  • If deploying to Exalogic and Exadata, make sure to use the JDBC drivers that ship with WebLogic in order to use SDP
  • Verify that the proper class name is being used. The proper class name is oracle.jdbc.xa.client.OracleXADataSource
  • Be sure to set -Doracle.jdbc.V8Compatible=true when using Oracle 10g databases. This ensures that dates are mapped to timestamps in the database and it helps OOTB indexes (like all of the ones on CHECKIN_DATE in CA) actually are used. See http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html#08_01

 

  • No labels