By setting FORCE LOGGING to TRUE, all transactions will generate REDO. This is used for Data Guard, so no data will be missed (i.e. transactions that were run with NOLOGGING option) in Standby database
By turning MONITORING ON that index and querying into INDEX_USAGE table
1. Modify init.ora parameter START_ARCHIVE=TRUE
2. SQL> SHUTDOWN IMMEDIATE;
3. STARTUP MOUNT;
4. ALTER DATAVASE ARCHIVELOG;
5. ALTER DATABASE OPEN;
4. If you had a tablespace, TEST_TABLESPACE, which consists of three files:
TEST01.dbf, TEST02.dbf, and TEST03.dbf, and someone accidentally used the Unix command
"rm" to delete the file TEST02.dbf, what else would you need in order to recover all the data that
was present in TEST_TABLESPACE at the time that TEST02.dbf was deleted?
Can't change CHARACTERSET of a database, you will need to re-create the database with
Wait is due to Data Guard Broker.
DBMS_STATS.GATHER_TABLE_STATS with GRANULARITY => 'PARTITION' OPTION
This parameter controls the maximum amount of memory PGA which can be used by the queries when WORKAREA_SIZE_POLICY is set to Auto.
The value you can be set in Bytes, kilobytes (K), megabytes (M) or gigabytes (G). The default value is 0
This parameter also has an effect on the execution plans of the cost based optimizer. The optimizer uses the value of the parameter PGA_AGGREGATE_TARGET to derive an estimate
for the minimum and maximum amount of memory which should be available at run-time for each sort, hash-join and bitmap operator in the query. Based on this minimum and maximum value, the
optimizer selects the best plan.
DB_16K_CACHE_SIZE, DB_8K_CACHE_SIZE, DB_2K_CACHE_SIZE
DB SCATTERED READ - FULL TABLE SCAN
DB SEQUENTIAL REAL - IO
ENQUEUE - LOCKING
11. Process you follow to start looking into Performance issue at database level
(If the application is running very slow, at what points do you need to go about the database in
order to improve the performance?)
► Run a TOP command in Unix to see CPU usage (identify CPU killer processes)
► Run VMSTAT, SAR, and PRSTAT command to get more information on CPU and memory usage and possible blocking
► Run STATSPACK report to identify:
1. TOP 5 WAIT EVENTS
2. RESOURCE intensive SQL statements
► See if STATISTICS on affected tables needs to be re-generated
► IF poorly written statements are culprit, run a EXPLAIN PLAN on these statements and see whether new index or use of HINT brings the cost of SQL down.
By running $ORACLE_HOME/rdbms/admin/spcreate.sql script
14. A DBA had to remove some Archivelogs to free up space in filesystem. Now
when the RMAN job starts to backup Archivelogs, it complains about missing Archivelogs that
were deleted by DBA. To resolve the issue and continue backing up remainder of Archivelogs,
which RMAN command can be used so it wo not complain about missing Archivelogs.
group by is used when we use aggregate functions on the columns in a query the other columns
should be in group by query
select empno,ename,sum(sal) from emp
group by empno,ename
Order by is used to sort values either in ascending or descending order
USING COMMENT LINES WITH (+) SIGN YOU CAN PASS THE HINTS TO SQL ENGINE
/* +PARALLEL( ) */
DDL IS A AUTO COMMIT, YOU DONT NEED TO COMMIT AGAIN
Rolling forward to recover data that has not been recorded in data files, yet has been recorded
in the on-line redo log, including the contents of rollback segments.
Rolling back transactions that have been explicitly rolled back or have not been committed as
indicated by the rollback segments regenerated in step a.
Releasing any resources (locks) held by transactions in process at the time of the failure.
Resolving any pending distributed transactions undergoing a two-phase commit at the time of
the instance failure.
The point at which ORACLE ends writing to one online redo log file and begins writing to another
is called a log switch.
Complete database recovery from disk failure is possible only in ARCHIVELOG mode.
Online database backup is possible only in ARCHIVELOG mode.
Archived Redo Log consists of Redo Log files that have archived before being reused.
A Partial Backup is any operating system backup short of a full backup, taken while the
database is open or shut down.
A full backup is an operating system backup of all data files, on-line redo log files and control
file that constitute ORACLE database and the parameter.
Exclusive Mode If the first instance that mounts a database does so in exclusive mode, only
that Instance can mount the database.
Parallel Mode If the first instance that mounts a database is started in parallel mode, other
instances that are started in parallel mode can also mount the database.
Start an instance, Mount the Database and Open the Database.
IS NULL operator
The privilege receiver can further grant the privileges he/she has obtained from the owner to any
It is used to drop constraints specified on the table.
Use DBMS_JOB for scheduling a cron job and DBMS_MAIL to send the results through email.
Co-related sub query is one in which inner query is evaluated only once and from that result outer
query is evaluated.
Nested query is one in which Inner query is evaluated for multiple times for getting one row of that
ex. Query used with IN() clause is Co-related query.
Query used with = operator is Nested query
RAID 5 is striping with an extra disk for parity. If we lose a disk we can reconstruct from that parity disk.
RAID 10 is mirroring pairs of disks, and then striping across those sets.
RAID 5 was created when disks were expensive. Its purpose was to provide RAID on the cheap. If a disk fails, the IO subsystem will perform VERY slowly during the rebuild process. What's more your liklihood of failure increases dramatically during this period, with all the added weight of the rebuild. Even when it is operating normally RAID 5 is slow for everything but reading. Given that and knowing databases (especially Oracle's redo logs) continue to experience write activity all the time, we should avoid RAID5 in all but the rare database that is MOSTLY read activity. Don't put redologs on RAID5.
RAID10 is just all around goodness. If you lose one disk in a set of 10 for example, you could lose any one of eight other disks and have no troubles. What's more rebuilding does not impact performance at all since you're simply making a mirror copy. Lastly RAID10 perform exceedingly well in all types of databases.
Fewer indexes on a table mean faster inserts/updates. More indexes mean faster, more specific WHERE clauses possibly without index merges.
SQL*Loader with direct path option can load data ABOVE the high water mark of a table, and DIRECTLY into the datafiles, without going through the SQL engine at all. This avoids all the locking, latching, and so on, and doesn't impact the db (except possibly the I/O subsystem) at all.
Oracle's SQL and PL/SQL engines are separate parts of the kernel which require context switching, like between unix processes. This is slow, and uses up resources. If we loop on an SQL statement, we are implicitely flipping between these two engines. We can minimize this by loading our data into an array, and using PL/SQL bulk binding operation to do it all in one go!
With bind variables in SQL, Oracle can cache related queries a single time in the SQL cache (area). This avoids a hard parse each time, which saves on various locking and latching resources we use to check objects existence and so on. BONUS: For rarely run queries, especially BATCH queries, we explicitely DO NOT want to use bind variables, as they hide information from the Cost Based Opitmizer.
BONUS BONUS: For batch queries from 3rd party apps like peoplesoft, if we can't remove bind variables, we can use bind variable peeking!
RMAN is faster, can do incremental (changes only) backups, and does not place tablespaces into hotbackup mode.
Standby databases allow us to create a copy of our production db, for disaster recovery. We merely switch mode on the target db, and bring it up as read/write. Can setup as master->slave or master->master. The latter allows the former prod db to become the standby, once the failure cause is remedied. Watch out for NO LOGGING!! Be sure we're in archivelog mode.
It disables the logging of changes to the redologs. It does not disable ALL LOGGING, however as Oracle continues to use a base of changes, for recovery if you pull the plug on the box, for instance. However it will cause problems if you are using standby database. Use it to speed up operations, like an index rebuild, or partition maintenance operations.
Fast refresh maintains a change log table, which records change vectors, not unlike how the redo logs work. There is overhead to this, as with a table that has a LOT of indexes on it, and inserts and updates will be slower. However if you are performing refreshes often, like every few minutes, you want to do fast refresh so you don't have to full-table-scan the source table. Complete refresh is good if you're going to refresh once a day. Does a full table scan on the source table, and recreats the snapshot/mview. Also inserts/updates on the source table are NOT impacted on tables where complete refresh snapshots have been created.
Truncate is nearly instantaenous, cannot be rolled back, and is fast because Oracle simply resets the HWM. When a full table scan is performed on a table, such as for a sort operation, Oracle reads to the HWM. So if you delete every single solitary row in 10 million row table so it is now empty, sorting on that table of 0 rows would still be extremely slow.
Hopefully we hear some use of command line as the answer!
a. CREATE INDEX
c. GROUP BY
d. ORDER BY
i. UNINDEXED TABLE JOIN
a. EXISTS can be better than IN under various conditions
b. UNION ALL is faster than UNION (not sorting)
Set the WORKAREA_SIZE_POLICY parameter to AUTO and set PGA_AGGREGATE_TARGET
Be sure to set NLS_LANG for example to "AMERCIAN_AMERICA.WE8ISO8859P1". If your source database is US7ASCII, beware of 8-bit characters. Also be wary of multi-byte characters sets as those may require extra attention. Also watch export/import for messages about any "character set conversions" which may occur.