Common Oracle Operational Issues – DBA should verify the following:
From the legitimate servers and/or subnets:
Can you ping the db host? Can the db host ping it’s client machines?
Is the db host in DNS?
Is your host listener port open?
Are SSH keys between servers set up correctly?
Common issue: oracle binary owner, user(s) and groups need to match the very same UIDs as previously set on other servers/NAS/Arrays for accounts with the same names. Otherwise… volume management becomes evil…
Are the correct permissions set on directories, mounts, shares?
Environment variables set per install guide?
Does the PATH reference necessary o/s libraries and binaries?
Oracle binary installation or patching:
First step: back up your Oracle Inventory directory and subdirectories – you will be glad you did.
Verify the prerequisite o/s version and required packages and versions have been installed.
Verify minimum RAM, Oracle Home disk space, swap space, java version.
Read – thoroughly – the binary release notes.
For patching – make sure you have updated OPatch to the minimum version cited in release notes.
Use DBCA (the GUI) for a “first cut”.
Does this even have to be said? – maybe it does. Multiplex your control files and redo logs and groups. This means use at lease 3 files and 3 groups or 3 files.
Upgrading: Read the Oracle Upgrade Guide and check the compatibility matrix for the upgrade path. If there is not a direct upgrade, consider alternatives, export/import (legacy) and datapump.
Endian changes: TTS RMAN conversion.
Monitoring: Set up host and database through OEM Agents or Nagios Agents.
Understand your database prerequisites if a COTS product. If custom, understand the application user base and performance requirements.
Installation defaults are just that, default and not necessarily appropriate for what you are doing. Parameters with names such as: files, processes, sessions, parallel.
Memory Management: Use AMM – DBCA uses this by default. Yes, there are reasons not to, but if you don’t know why you wouldn’t, “laissez faire”.
Read/study Oracle’s 2-day Performance DBA document from your version’s doc library – then start with the biggest “wait events”. OEM is great if you have purchased the Performance pack ($$$$ per cpu). If not, you can still run ASH and ADDM reports from the $OH/rdbms/admin directory.
If you have the option, put your redo log groups on your fastest disk groups/volumes. SSD is perfect for this.
#1 Most Important thing: Before you open the database to other people – create, run and test (restore and recover elsewhere) Backups. Then schedule them, manage them, maintain them.
The poster was asking about Oracle Operational problems so I am not sure the below is relevant to the question.
Most common Java performance issue is DB communication. This can be optimized by following measures –
1. Query Optimization ( Query Rewriting , Prepared Statements )
2. Restructuring Indexes.
3. DB Caching Tuning ( if using ORM )
4. Identifying the problems ( if any ) with the ORM Strategy ( If using ORM )