Classification database operations
-
DDL: database schema definition language, keyword: create
-
DML: Data Manipulation Language, keyword: Insert, delete, update
-
DCL: Database control language, keyword: grant, remove
-
DQL: database query language, keyword: select
Lock table
Why lock table?
It can be divided into DML locks, row locks, table locks, deadlocks
Row lock: When the transaction to perform database insert, update, delete operation, the transaction automatically operating table in the operating line exclusive lock.
Table lock: When the transaction row lock is obtained, the transaction table will also automatically lock the line (shared lock), to prevent other transactions for DDL statements affect the update of rows. Transactions can also be obtained during the course of a shared lock or exclusive lock, only when the transaction is displayed using the LOCK TABLE statement displays the definition of an exclusive lock, the transaction will acquire an exclusive lock on the table, can also be used to display the LOCK TABLE define a shared table-level lock (lOCK tABLE specific usage, please refer to the documentation).
Deadlock: When two transactions require a set of lock conflict, affairs can not continue, then it is a deadlock.
The transaction 1 has an exclusive lock on the table A rows # 3, and wait for transaction 2 # 4 in the exclusive lock release reported in Table A, whereas transaction 2 has an exclusive lock in Table A rows # 4, 1 and # 3 are waiting for a transaction releases its lock rows are recorded in table a, transaction 1 and transaction 2 waiting for each other, thus causing a deadlock. Deadlock is generally due to poor transaction design and production.
Deadlock can only use SQL under: alter system kill session "sid, serial #"; or use the command kill processes related to the operating system, such as under UNIX kill -9 sid, or use other tools to kill the process deadlock.
DDL lock can be divided into: exclusive DDL locks, share DDL lock, lock analysis
Exclusive DDL lock: create, modify, delete a database object DDL statements get exclusive lock operation objects. Such as the use alter table statements, in order to maintain complete data, consistency, legality, the transaction to obtain a DDL exclusive lock.
Share DDL lock: the need to establish a relationship of interdependence between the database objects DDL DDL statements usually required to obtain a shared lock. Such as creating a package, the package process and function references a different database tables when compiling this package, the transaction will share DDL lock referenced table.
Analysis of Lock: ORACLE using a shared pool of storage analysis and optimized SQL statements and PL / SQL program, so applications run the same statement faster speed. A shared pool in the object cache analysis to obtain the lock database objects it references. Analysis of lock is a unique type of DDL lock, ORACLE shared pool object to use it to track and it refers to dependencies between database objects. When a transaction to modify or delete a shared pool of locks held by a database object analysis, ORACLE shared pool set aside the target, the next in reference to this SQL / PLSQL statement, ORACLE re-analysis to compile this statement.
Tables involved
SELECT FROM v$lock;
SELECT FROM v$sqlarea;
SELECT FROM v$session;
SELECT FROM v$process ;
SELECT FROM v$locked_object;
SELECT FROM all_objects;
SELECT * FROM v$session_wait;
--查看被锁的表
select b.owner,b.object_name,a.session_id,a.locked_mode from v$locked_object a,dba_objects b where b.object_id = a.object_id;
- Check that the user that the process according to the deadlock
select b.username, b.sid, b.serial #, logon_time from v $ locked_object a, v $ session b where a.session_id = b.sid order by b.logon_time;
- Check the connection process of
the SELECT sid, Serial #, username, OSUSER the FROM v $ session;
- SQL statement to a beautiful woman session is being executed, so you can quickly navigate to what actions or code that causes the transaction has been carried out is not over and so on.
SELECT
sql_text
FROM v$sqltext a
WHERE (a.hash_value, a.address) IN
(SELECT DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value),
DECODE(sql_hash_value, 0, prev_sql_addr, sql_address)
FROM v$session b
WHERE b.sid = '321') / 此处为SID/
ORDER BY piece ASC;
--查出锁定表的sid, serial#,os_user_name, machine_name, terminal，锁的type,mode
SELECT s.sid, s.serial#, s.username, s.schemaname, s.osuser, s.process, s.machine,
s.terminal, s.logon_time, l.type
FROM v$session s, v$lock l
WHERE s.sid = l.sid
AND s.username IS NOT NULL
ORDER BY sid;
This statement will look to lock the database of all the DML statements generated, can also be found,
any DML statements actually had two locks, one lock table, a row lock.
- kill the process sid, Serial #
the ALTER System session'111,12305 the kill ';
Mistakenly deleted data recovery
deleted table data in three ways: delete, drop and truncate
Solution delete accidentally deleted
principle:
Flashback method using oracle provided, if the number of operations do not delete the data (data to be deleted as long as no blocks are overwritten), it can be used to retrieve data directly flashback delete
the specific steps:
for example:
100 data deleted by mistake
delete statement is:
the delete from table name where kid = '5';
determine the time to delete the data (in the time before deleting data on the line, but the best time is to delete data)
can be used to find what statement a delete statement time
the SELECT r.FIRST_LOAD_TIME, r. from $ SQLAREA v r the Order by r.FIRST_LOAD_TIME desc;
find deleted data with the following statement:
the SELECT from the table name as of timestamp to_timestamp ( 'deletion point in time,' ' HH24-mm-dd YYYY: mi the: SS ') = WHERE Kid'. 5 '
SELECT from table as of timestamp sysdate - 3/1440 where kid =' 5 '; data --3 minutes before
the deleted data reinserted the original table:
Note to ensure that the primary key is not repeated.
insert into table (SELECT from table as of timestamp to_timestamp ( 'deletion time point', 'yyyy-mm-dd hh24: mi: ss') where kid = '5');
insert into table (select * from table as of timestamp sysdate - 3/1440 where kid = '5');
if no change table structure may be used directly Flashback entire table used to restore the data.
Specific steps:
TABLE flash back requires a user must have permission to flash any table
- Enable row movement
· alter table table name enable row movement
- recover table data
· flashback table table name to timestamp to_timestamp (deleting time ',' yyyy-mm-dd HH24: mi: SS ')
- closed row movement (do not forget)
· the ALTER TABLE name disable the Table Movement NC Joining Module Row
drop, the solution trancate accidentally deleted
principle: As the oracle when you delete a table, the table is not empty the share of direct block, oracle deleted the information in these tables into a virtual container "Recycle Bin", but only the data block table can be overwritten made a sign, it can also be restored before the block is not reused.
Specific steps:
Query the "Recycle Bin" or query user_table views to the lookup table has been removed:
· the SELECT table_name, dropped Total from USER_TABLES
· the SELECT object_name, original_name, of the type, droptime from USER_RECYCLEBIN
in the above information, the table names are being re named before, or table_name field object_name is the table name after deleting stored in the Recycle Bin
if you could remember the name of the table, it can be recovered directly with the following statement:
the Flashback the table original table to before drop
If you can not remember, but also It can be used as table name to restore the Recycle Bin, and then rename the reference to the following statements:
the Flashback the table "recycle bin table names (such as: Bin $ DSbdfd4rdfdfdfegdfsf == $ 0) " to before drop rename to new table name
oracle flashback function in addition to the above basic functions, you can also flash back an entire database:
use the database Flashback feature, you can make a return to the past state of the database, the syntax is as follows:
SQL>alter database flashback on
SQL>flashback database to scn SCNNO;
SQL>flashback database to timestamp to_timestamp('2007-2-12 12:00:00','yyyy-mm-dd hh24:mi:ss');
Update error recovery
can be used to find out about the statement delete statement time
the SELECT r.FIRST_LOAD_TIME, r. From $ SQLAREA v r the Order by r.FIRST_LOAD_TIME desc;
create a table holds out the backup data
create table table name _BAK
AS
the SELECT from table name as of timestamp sysdate -5/1440;
the operation is successful you look at the new data table which is not before you, if that is the case then the new data table to get the original table just fine.
Reproduced in: https: //blog.51cto.com/13032607/2402184