1. Trang chủ
  2. » Công Nghệ Thông Tin

Sybex OCA Oracle 10g Administration I Study Guide phần 10 ppsx

78 389 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 78
Dung lượng 2,07 MB

Nội dung

552 Chapter 11  Implementing Database Recovery FIGURE 11.1 Adjusting MTTR for instance recovery Using the SQL*Plus command line, you can accomplish this task by using the ALTER SYSTEM command, as in this example: SQL> alter system set fast_start_mttr_target=60 scope=both; System altered. Using SCOPE=BOTH, the new value of the parameter takes effect immediately and stays in effect the next time the instance is restarted. Recovering from User Errors Earlier in this chapter, in the section “User Error Failures,” we presented a number of scenarios in which a user’s data was inadvertently changed or deleted or a table was dropped. In the fol- lowing sections, we’ll show you how to use Flashback Query to retrieve selected rows from a previous state of a table, how to recover a table using Flashback Drop and a tablespace’s recycle bin, how to bring back an entire table and its dependent objects (such as indexes) back to a point of time in the past using Flashback Table, and query previous transactions in the online and archived redo logs using the LogMiner utility. 4367.book Page 552 Monday, October 4, 2004 2:19 PM Performing Recovery Operations 553 Using Flashback Query One of the features introduced in Oracle9i is called Flashback Query. It allows a user to “go back in time” and view the contents of a table as it existed at some point in the recent past. A Flashback Query looks a lot like a standard SQL SELECT statement, with the addition of the AS OF TIMESTAMP clause. Before users can take advantage of the Flashback Query feature, you, the DBA, must perform two tasks:  Make sure that there is an undo tablespace in the database that is large enough to retain changes made by all users for a specified period of time. This is the same tablespace that is used to support COMMIT and ROLLBACK functionality (discussed in Chapter 8, “Managing Consistency and Concurrency”).  Specify how long the undo information will be retained for use by flashback queries by using the initialization parameter UNDO_RETENTION. This parameter is specified in seconds; therefore, if you specify UNDO_RETENTION=172800, the undo information for flashback queries can be available for up to two days. The key to Flashback Query is using the AS OF TIMESTAMP clause in the SELECT statement; you can specify the time stamp as any valid expression that evaluates to a date or time stamp value. In the following example, you want to query the EMPLOYEES table as it existed 15 minutes ago: SQL> select employee_id, last_name, email 2 from hr.employees 3 as of timestamp (systimestamp - interval '15' minute) 4 where employee_id = 101; EMPLOYEE_ID LAST_NAME EMAIL 101 Kochhar NKOCHHAR 1 row selected. You can just as easily specify an absolute time of day to retrieve the contents of the row at that time, as in this example: SQL> select employee_id, last_name, email 2 from hr.employees 3 as of timestamp 4 (to_timestamp ('01-Sep-04 16:18:57.845993', 5 'DD-Mon-RR HH24:MI:SS.FF')) 6 where employee_id = 101; EMPLOYEE_ID LAST_NAME EMAIL 101 Kochhar NTKOCHHAR 4367.book Page 553 Monday, October 4, 2004 2:19 PM 554 Chapter 11  Implementing Database Recovery If your Flashback Query requires undo data that is no longer available in the undo tablespace, you will receive an error message: SQL> select employee_id, last_name, email 2 from hr.employees 3 as of timestamp (systimestamp - interval '10' month) 4 where employee_id = 101; select employee_id, last_name, email * ERROR at line 1: ORA-08180: no snapshot found based on specified time Using Flashback Query to Investigate a Customer Complaint In your custom widget company, an error in the Accounting Department added $2,000 to two orders placed yesterday: SQL> update orders 2 set order_total = order_total+2000 3 where order_id in (2367,2361); 2 rows updated. SQL> select order_id, customer_id, order_total 2 from orders where order_id in (2367,2361); ORDER_ID CUSTOMER_ID ORDER_TOTAL 2361 108 122131.3 2367 148 146054.8 2 rows selected. Today, the customer with ID 108 called to complain that the bill from his last order (order num- ber 2361) is $2,000 more than expected. Sharon, one of the order-entry clerks, retrieves the row from the ORDERS table with the information for order number 2361: SQL> select order_id, customer_id, order_total 4367.book Page 554 Monday, October 4, 2004 2:19 PM Performing Recovery Operations 555 2 from orders where order_id = 2361; ORDER_ID CUSTOMER_ID ORDER_TOTAL 2361 108 122131.3 1 row selected. Before calling back the customer, Sharon finds out from the Accounting Department that a day ago, two of the orders were incorrectly modified with an additional surcharge. To confirm whether this particular order was affected by the accounting error, she uses a Flashback Query to see if this order had a different order total two days ago: SQL> select order_id, customer_id, order_total from orders 2 as of timestamp (sysdate - 2) 3 where order_id = 2361; ORDER_ID CUSTOMER_ID ORDER_TOTAL 2361 108 120131.3 1 row selected. This Flashback Query confirms that the order total for this order was $2,000 less two days ago. The AS OF TIMESTAMP clause specifies how far back in the past you want to view the contents of this table. In this case, (sysdate - 2) evaluates to today’s date minus two days—in other words, two days ago. Sharon concludes that at some point in the past two days, this was one of the orders that was incorrectly modified. To find all the orders that have the incorrect surcharge, she uses another Flashback Query as a nested query to compare the order totals: SQL> select o.order_id, o.customer_id, 2 o.order_total "CURR_TOTAL", oo.order_total "ORIG_TOTAL" 3 from orders o, 4 (select order_id, order_total from orders 5 as of timestamp (sysdate - 2)) oo 6 where o.order_id = oo.order_id and 7 o.order_total != oo.order_total; ORDER_ID CUSTOMER_ID ORDER_TOTAL ORIG_TOTAL 2361 108 122131.3 120131.3 4367.book Page 555 Monday, October 4, 2004 2:19 PM 556 Chapter 11  Implementing Database Recovery Using Flashback Drop and the Recycle Bin Another user recovery flashback feature, Flashback Drop, lets you restore a dropped table without using tablespace point-in-time recovery, as required in previous versions of Oracle. Although tablespace point-in-time recovery could effectively restore a table and its contents to a point in time before it was dropped, it was potentially time-consuming and had the side effect of losing work from other transactions that occurred within the same tablespace after the table was dropped. In the following two sections, we will talk about the new logical structure available in each tablespace: the recycle bin and how you can query the recycle bin and retrieve dropped objects from it. We will also describe some minor limitations involved in using the recycle bin. Recycle Bin Concepts The recycle bin is a logical structure within each tablespace that holds dropped tables and objects related to the tables, such as indexes. The space associated with the dropped table is not immediately available but shows up in the data dictionary view DBA_FREE_SPACE. When space pressure occurs in the tablespace, objects in the recycle bin are deleted in a first-in first-out (FIFO) fashion, maximizing the amount of time that the most recently dropped object remains in the recycle bin. The recycle bin, new to Oracle 10g, is implemented as a data dictionary table. The dropped object still belongs to the owner and still counts against the quota for the owner in the tablespace; in fact, the table itself is still directly accessible from the recycle bin, as you will see in subsequent examples. Retrieving Dropped Tables from the Recycle Bin You retrieve a dropped table from the recycle bin at the SQL command line by using the FLASHBACK TABLE TO BEFORE DROP command. In the following example, the user GARY retrieves the table ORDER_ITEMS from the recycle bin after discovering that the table was inad- vertently dropped: SQL> select order_id, line_item_id, product_id 2 from order_items 3 where rownum < 5; 2367 148 146054.8 144054.8 2 rows selected. In this query, Sharon is comparing the entire contents of the current ORDERS table to the entire contents of the ORDERS table as it was two days ago and selecting records in which the order totals don’t match. She now knows which records must be updated with the correct order total amount. 4367.book Page 556 Monday, October 4, 2004 2:19 PM Performing Recovery Operations 557 from order_items * ERROR at line 2: ORA-00942: table or view does not exist SQL> flashback table order_items to before drop; Flashback complete. SQL> select order_id, line_item_id, product_id 2 from order_items 3 where rownum < 5; ORDER_ID LINE_ITEM_ID PRODUCT_ID 2355 1 2289 2356 1 2264 2357 1 2211 2358 1 1781 SQL> If the table ORDER_ITEMS was re-created after it was dropped, Gary would add the RENAME TO clause in the FLASHBACK TABLE command to give the restored table a new name, as in the fol- lowing example: SQL> drop table order_items; Table dropped. SQL> flashback table order_items to before drop 2 rename to order_items_old_version; Flashback complete. SQL> select order_id, line_item_id, product_id 2 from order_items_old_version 3 where rownum < 5; ORDER_ID LINE_ITEM_ID PRODUCT_ID 2355 1 2289 4367.book Page 557 Monday, October 4, 2004 2:19 PM 558 Chapter 11  Implementing Database Recovery 2356 1 2264 2357 1 2211 2358 1 1781 SQL> If the table to be retrieved from the recycle bin was dropped more than once, and you want to retrieve an incarnation of the table before the most recent one, you can use the name of the table in the recycle bin; you can query the view RECYCLEBIN or use the SHOW RECYCLEBIN command. Using the EM Database Control, you can retrieve a dropped table from the recycle bin on the Perform Recovery: Dropped Objects Selection screen, as shown in Figure 11.2. The user GARY has one table, ORDER_ITEMS, in the recycle bin that was dropped on June 21, 2004. Subsequent screen in this wizard let you rename the restored tables if a name conflicts with an existing object. Recycle Bin Considerations and Limitations A few limitations are associated with the recycle bin:  Only non-SYSTEM locally managed tablespaces can have a recycle bin. However, dependent objects in a dictionary-managed tablespace are protected if the dropped object is in a locally managed tablespace.  A table’s dependent objects are saved in the recycle bin when the table is dropped, except for bitmap join indexes, referential integrity constraints (foreign key constraints), and materialized view logs.  Indexes are protected only if the table is dropped first; explicitly dropping an index does not place the index into the recycle bin. Using Flashback Table Flashback Table allows you to recover one or more tables to a specific point in time without hav- ing to use more time-consuming recovery operations such as tablespace point-in-time recovery or Flashback Database that can also affect the availability of the rest of the database. Flashback Table works in-place by rolling back only the changes made to the table or tables and their depen- dent objects, such as indexes. Flashback Table is different from Flashback Drop; Flashback Table undoes recent transactions to an existing table, whereas Flashback Drop recovers a dropped table. Flashback Table uses data in the undo tablespace, whereas Flashback Drop uses the recycle bin. The FLASHBACK TABLE command brings one or more tables back to a point in time before any number of logical corruptions have occurred on the tables. To be able to flashback a table, you must enable row movement for the table. Because DML operations are used to bring the table back to its former state, the ROWIDs in the table change. As a result, Flashback Table is not a viable option for applications that depend on the table’s ROWIDs to remain constant. In the following example, you find out that someone in the HR department has accidentally deleted all the employees in department 60, the IT department, along with the row for IT in the DEPARTMENTS table. Because this happened less than 15 minutes ago, you are sure that there is enough undo information to support a Flashback Table operation. 4367.book Page 558 Monday, October 4, 2004 2:19 PM Performing Recovery Operations 559 FIGURE 11.2 The Perform Recovery: Dropped Objects Selection screen Before performing the Flashback Table operation, you first enable row movement in the two affected tables, as in the following example: SQL> alter table hr.employees enable row movement; Table altered. SQL> alter table hr.departments enable row movement; Table altered. Before running the FLASHBACK TABLE command, you confirm that the row in DEPARTMENTS for the IT department is still missing using this query: SQL> select * from hr.departments where 2 department_name = 'IT'; no rows selected Next, you flash back the table to 15 minutes ago, specifying both tables in the same com- mand, as follows: SQL> flashback table hr.employees, hr.departments 2 to timestamp systimestamp - interval '15' minute; Flashback complete. 4367.book Page 559 Monday, October 4, 2004 2:19 PM 560 Chapter 11  Implementing Database Recovery Finally, you check to see if the IT department is truly back in the table: SQL> select * from hr.departments where 2 department_name = 'IT'; DEPARTMENT_ID DEPARTMENT_NAME MANAGER_ID LOCATION_ID 60 IT 103 1400 SQL> If you either flashback too far or not far enough, you can simply rerun the FLASHBACK TABLE command with a different time stamp or SCN, as long as the undo data is still available. Although the rest of the database is unaffected by a Flashback Table operation, the FLASHBACK TABLE command acquires exclusive DML locks on the tables involved in the flashback. This is usually not an availability issue, because the users who would normally use the table are waiting for the flashback operation to complete anyway! Integrity constraints are not violated when one or more tables are flashed back; this is why you typically group tables related by integrity constraints or parent-child relationships in the FLASHBACK TABLE command. Using EM Database Control, you can flashback a table by selecting the Maintenance tab from the EM Database Control home page, and clicking the Perform Recovery link. On the Perform Recovery: Type screen, shown in Figure 11.3, select Tables in the Object Type drop-down box. FIGURE 11.3 Selecting Tables as the object type for recovery 4367.book Page 560 Monday, October 4, 2004 2:19 PM Performing Recovery Operations 561 After clicking the Next button, select either Flashback to a Timestamp or Flashback to a Known SCN, and specify the time stamp or SCN as the desired point in time for the recovered table, as you can see in Figure 11.4. Click Next to skip to step 4 in the recovery dialog, the Perform Recovery: Flashback Tables screen, as shown in Figure 11.5, where you specify the two tables you used in the SQL*Plus command-line example earlier in this section: HR.EMPLOYEES and HR.DEPARTMENTS. At the end of this sequence of steps, you can view the SQL command that will be executed. In the Perform Recovery: Review screen shown in Figure 11.6, you can see the summary pre- sented before the flashback is initiated, and here is the SQL you see when you click the Show SQL button: FLASHBACK TABLE HR.EMPLOYEES, HR.JOBS, HR.DEPARTMENTS, HR.LOCATIONS TO TIMESTAMP TO_TIMESTAMP(‘2004-09-12 01:15:25 PM’, ‘YYYY-MM-DD HH:MI:SS AM’) The EM Database Control version of the command shows two more tables than in your command-line version of this recovery scenario, HR.JOBS and HR.LOCATIONS, because by default the recovery wizard includes all dependent objects. FIGURE 11.4 Selecting a time stamp or an SCN for table recovery 4367.book Page 561 Monday, October 4, 2004 2:19 PM [...]... copy it to another suitable location instead, and update the initialization parameter file to update the control file reference Alternatively, you can temporarily remove the reference from the initialization parameter file until you find a suitable location However, it is highly desirable to maintain at least two, if not more, copies of the control file available in the case of another media failure... the instance with STARTUP In the following example, you use a server parameter file (SPFILE) for initialization parameters, and you decide to temporarily do without a third multiplexed control file until the disk containing the lost control file is repaired The initialization parameter file parameter CONTROL_FILES will be changed using the ALTER SYSTEM … SCOPE=SPFILE command when the instance is started... INVALID B STALE C DELETED D The column contains a NULL value 16 If a datafile is missing when the instance is started, where is the error message recorded? A Only in the alert log B All missing files are returned directly to the administrator in the SQL*Plus session C The first missing file is returned directly to the administrator in the SQL*Plus session, and the rest of the missing files are identified... find in the redo logs, keeping in mind any integrity constraints in place for the tables you are modifying Recovering from Loss of a Control File Losing one of the multiplexed control files immediately aborts the instance Assuming that you have not lost every control file, recovering from this failure is fairly straightforward Recovering from the loss of all control files is covered in OCP: Oracle 10g. .. while minimizing downtime and preventing any loss of committed transactions Exam Essentials Identify the initialization parameters used to tune instance recovery Be able to define the possible values for FAST_START_MTTR_TARGET, FAST_START_IO_TARGET, and LOG_CHECKPOINT_ TIMEOUT Show the relationship between these parameters and in which situations each is most appropriately used List the phases of instance... in Oracle 10g but should only be used together in an advanced tuning scenario or for compatibility with older versions of Oracle MTTR_ TARGET_ADVICE and FAST_START_TARGET_MTTR are not valid initialization parameters 4 D The PMON process periodically polls server processes to make sure that their sessions are still connected 5 C A DBA’s disconnection of a session is an intentional process termination,... STATUS is STALE until the log file member is used to record redo information 16 C In addition to reporting the first missing file to the administrator and listing all the missing files in the dynamic performance view V$RECOVER_FILE, the missing datafile(s) are noted in the DBWR background process trace files 17 B The loss of one or more of a tablespace’s datafiles does not prevent other users from doing... doing their work in other tablespaces Recovering the affected datafiles can continue while the database is still online and available 18 A The dynamic performance view V$RECOVER_FILE contains a list of the datafiles that either need media recovery or are missing when the instance is started 19 B The primary failure in this scenario is instance Subsequently, a network failure will occur when connections... type of failure is considered a(n) _ failure, and the DBA can solve this problem by A User error; providing additional user privileges B User error; increasing the user’s quota C Statement failure; enabling resumable space allocation D Statement failure; changing the application logic 3 Which of the following initialization parameters controls the mean time to recover the database, in seconds,... the control files as defined in the SPFILE or the init.ora file must be identical and available If one of the redo log file groups is missing a member, a warning is recorded in the alert log, but instance startup still proceeds If the instance was previously shut down with SHUTDOWN ABORT, instance recovery automatically occurs during startup Only an SPFILE or an init.ora file is needed to enter the . file, recovering from this failure is fairly straightforward. Recovering from the loss of all control files is covered in OCP: Oracle 10g Administration II Study Guide (Sybex, 2005). Here are. in this wizard let you rename the restored tables if a name conflicts with an existing object. Recycle Bin Considerations and Limitations A few limitations are associated with the recycle bin:  Only. line or via a GUI-based interface within Oracle Enterprise Manager, as shown in Figure 11.7, by choosing Tools  Database Applications  Logminer Viewer. This LogMiner session initiated through

Ngày đăng: 07/08/2014, 11:22

TỪ KHÓA LIÊN QUAN