Does Rman Continue to Backup is Session Disconnects
RMAN Backup Errors and Failures Requiring Recovery
While using the Oracle database, you may encounter some failures . As a DBA, it is one of your basic functions to prevent these failures, or if they occur, to define and solve them on time with correct techniques in place. Below, the main types of failures will be described, the way they occur and key solutions.
1. Statement failure: This type of failure may occur when any SQL statement does not finish successfully for some reason. When this failure occurs, Oracle automatically detects it and rolls back the transaction. This type of failure may occur in one of the following events:
- When a user wants to access an object which he/she has no authority to do so
- When a user attempts to insert data in a column with incompatible data type
- Due to huge amount of data, quota of user exceeds or no space can be found in database
- During some logical errors
- Insufficient privileges
If a user does not have access to a table, then he will get an error:
usr2@ORCL>insert into usr1.table1 values(1);
insert into usr1.table1 values(1)
*
ERROR at line 1:
ORA-01031: insufficient privileges
usr2@ORCL>
From the example above, it seems that the user usr2 does not have the insert privilege on the table of user usr1, so he gets an error. Now, imagine that you run a procedure which consists of hundreds of lines and at the end, prior to the commit statement you get this error. It means that your procedure will be rolled back and no changes will be made to the database objects.
2. Invalid data : This error may occur in any operation which causes a constraint violation or while inserting data to a column with a different data type. The application/system should be designed to prevent such errors arising and being presented to users.
sys@ORCL>create table invalid_data (id number); sys@ORCL>alter table invalid_data add constraint unq_invalid_data sys@ORCL>insert into invalid_data values(1); sys@ORCL>insert into invalid_data values(1);
Table created.
unique (id);
Table altered.
1 row created.
insert into invalid_data values(1)
*
ERROR at line 1:
ORA-00001: unique constraint (sys.unq_invalid_data) violated
ssys@ORCL>
In the above example, you were not able to insert data due to constraint violation. Next is another example from the invalid data failure type:
sys@ORCL>insert into invalid_data values('hello');
insert into invalid_data values('hello')
*
ERROR at line 1:
ORA-01722: invalid number
sys@ORCL>
As you see, if a user attempts to insert data with string type to a column with number type, she will get an error. This problem also should be solved in the application level and the datatype should be checked before being sent to the database.
3. Running out of space: When a user makes a change to a database and the users quota or tablespace gets filled, the user gets an error and the statement is rolled back. You can see it from this example:
sys@ORCL>create tablespace tbs_new datafile '/u01/oradata/br/tbs_new' SIZE 100K;
Tablespace created.
sys@ORCL>create table tab1 (id number) tablespace tbs_new;
Table created.
sys@ORCL>begin
2 for i in 1..100000 loop
3 insert into tab1 values(i);
4 end loop;
5 end;
6 /
begin
*
error at line 1:
ORA-01653: unable to extend table SYS.TAB1 by 8 in tablespace tbs_new
ORA-06512: at line 3
sys@ORCL>
It is obvious from this example that if the tablespaces size is small, then any user may face this type of failure at any time. Imagine, you run a nightly job which updates billing information of subscribers and suddenly the script stops running because of a space problem. If you have some commit statements in your code, then part of your data will be committed.
However, another part of your data, after having no space to continue script, will be uncommitted. This situation is unacceptable and you need to recover your database. If you do not have any commit statements except one at the end, then all your data will be rolled back and the job will fail. To avoid such failure, you need to either control the size of the tablespace in your database or quota of the user or use the Resumable Space Allocation feature. Using this feature, your script will be suspended, information about it will be written in the alert.log file, and it will not be interrupted and rolled back. Once the problem is resolved, the operations will automatically resume.
4. Process failure : A connected user disconnects in an unusual way from the database. The reason may be the application that user employs or abnormal termination of the users computer. In this situation, the background process PMON finds disconnected sessions, rolls them back and releases their locks. As a DBA, you do not need to intervene. Oracle will discover this failure automatically and solve it by using the PMON process.
5. User error failure: Dropping a table by accident, updating a table which consists of millions of rows without putting the WHERE clause and committing the statement could be an example of such failures. This problem can be solved only with the assistance of the DBA. As a DBA, when encountering such failure, you need to use Oracle flashback technology immediately and solve this problem without issuing any recovery or disruption in the database. This concept is covered in further detail in Chapter 12 and all necessary steps to solve such user failures will be shown.
Yet sometimes it is not possible to use flashback technology for some reason. In this situation, use the TSPITR technique and recover the database to a time before this error occurred. Read about this concept in Chapter 4 for more details.
6. Instance failure : This type of error occurs on the server where the Oracle database is installed. The main reason for this failure is an unexpected power outage or shutting down of any vital background processes such as DBW, LGWR or CKPT. Shutting down of the server is the same as the shutdown abort mode. After the problem is resolved, on the subsequent startup, Oracle rolls back uncommitted transactions, rolls forward committed transactions to datafiles and opens the database. This is done by the background process SMON automatically and no DBA interference is needed.
7. Network failure : This type of failure occurs when the network card of the server fails or the listener overloads and crashes, and users are unable to connect to the database. To solve this problem, you have to configure both network cards of the server and one listener to each network card. At the same time, you need to configure connect time failover and load balancing features in the listener. By configuring load balancing, your connection will be distributed among the number of listeners. Connect time failover directs clients to connect to another listener if the connection to the first listener fails.
8. Media failure : This type of failure could happen when an administrator accidentally deletes physical files of the database or when these files get corrupted due to media failure such as hard drive failure. By getting media failure, you need to immediately choose the right recovery strategy and recover the database using backups.
To prevent media failure from occurring is not something that depends on the DBA. You cannot prevent the crash of your hard drive or corruption of some datafiles in the hard drive. However, what does depend on you is to implement the correct backup steps to overcome this problem and make your database available as soon as possible. Somehow, there are some prerequisites to protect your main physical files against corruption and your database from abnormally terminating because of media failure. More details on this are found in Chapter 4.
Burleson is the American Team Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals. Feel free to ask questions on our Oracle forum. Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications. Errata? Oracle technology is changing and we strive to update our BC Oracle support information. If you find an error or have a suggestion for improving our content, we would appreciate your feedback. Just e-mail: Copyright © 1996 - 2020 All rights reserved by Burleson Oracle ® is the registered trademark of Oracle Corporation.
Source: http://www.dba-oracle.com/t_rman_3_failure.htm
0 Response to "Does Rman Continue to Backup is Session Disconnects"
Post a Comment