| 1: | You have two undo tablespaces defined for your database, undo01 and undo02. The instance is currently using undo01. You issue this command to switch to undo02 while transactions are still active in the database: ALTER SYSTEM SET UNDO_TABLESPACE = undo02
Which result occurs? A. New transactions will be assigned to the undo02 tablespace. B. Current transactions are switched to the undo02 tablespace. C. The switch to undo02 fails, and an error message is returned because transactions are using undo01. D. The switch to undo02 does not take place until all transactions in undo01 are completed.
|
| A1: | Answer A is correct; new transactions will be assigned to the undo02 undo tablespace. Answer B is incorrect; current transactions will continue to use undo01. Answer C is incorrect; the switch of the undo tablespace will complete without error. Answer D is incorrect; the switch will be immediate, and new transactions will use the new undo tablespace. |
| 2: | What structure does Oracle provide to ensure read consistency in the database? A. Redo log files B. Control files C. Data dictionary D. Data files E. Undo segments
|
| A2: | Answer E is correct. Undo segments provide read consistency for queries. Answer A is incorrect; redo log files provide a mechanism to store data changes before they are written to disk. Answer B is incorrect; control files record changes to the database's structure. Answer C is incorrect; the data dictionary stores the system's objects. Answer D is incorrect; data files store the database's data. |
| 3: | You set UNDO_RETENTION to 500 seconds. What is one possible reason that you may not have 500 seconds worth of undo information in the undo tablespace? A. 500 seconds is an invalid value for UNDO_RETENTION. B. Your undo tablespace is too small to hold that much undo information. C. Your system is extremely quiet that day, and the users aren't generating 500 seconds worth of undo information. D. The rollback segments are full.
|
| A3: | Answer B is correct; your undo tablespace is likely too small to hold 500 seconds worth of undo information. Answer A is incorrect; 500 seconds is a valid setting for UNDO_RETENTION. Answer C is incorrect; 500 seconds doesn't depend on any transactions taking place. In fact, fewer transactions means your retention is even longer than required. Answer D is incorrect; with automatic undo you don't have rollback segments. |
| 4: | You have one undo tablespace in your database. You try to take the undo tablespace offline. What is the effect of this action? A. The undo tablespace is offlined. B. The undo tablespace is put into pending offline mode. C. The database reverts to manual undo retention. D. You receive an error because you cannot offline the only undo tablespace in the database.
|
| A4: | Answer D is correct, you cannot offline the only undo tablespace in the database, and an attempt to do so causes an error. Answers A and B are incorrect; you cannot offline the only undo tablespace in a database. Answer C is incorrect. You can only deliberately revert back to manual undo management mode; the database won't do it for you. |
| 5: | Your database is running in automatic undo management mode and you are trying to determine whether you need to resize your undo tablespace. You have queried the V$ROLLSTAT view to find out how many blocks of undo are generated on average in your database. Will this method provide the information that you need? A. Yes, in the extents column. B. No, V$ROLLSTAT does not provide you with the blocks used in automatic undo management mode. C. Yes, but only averaged at every 10 minutes. D. Yes, but you will have to multiply to determine the number of megabytes because the information is stored in blocks.
|
| A5: | Answer B is correct; V$UNDOSTAT provides the desired information when you are running in automatic undo management mode. Answer A is incorrect; the extents column tells you the number of extents in the rollback segments for manual undo managed rollback. Answer C is incorrect; however, V$UNDOSTAT provides the information required at 10-minute intervals, which will not meet your requirements, but may meet others. Answer D is incorrect because the information is not available in any way from V$ROLLSTAT. |
| 6: | You have set UNDO_RETENTION for 900 seconds. Your users have started to complain about getting snapshot too old errors. What can you infer about your undo tablespace from this? A. That your undo tablespace is too large, and you have too much undo information available. B. That your undo tablespace must be offline, and users are seeing the results. C. That your undo tablespace is too small to maintain enough undo information to provide read-consistent information. D. Your undo tablespace is fine, but your users are using the SYSTEM rollback segment.
|
| A6: | Answer C is correct; you can infer that your tablespace is too small to provide sufficient space for the undo. Answer A is incorrect because a too large tablespace will only provide extra room to maintain more undo information. Answer B is incorrect; you will not get snapshot too old errors just because your undo tablespace is offline. If it is the only undo tablespace, it can't be offline. Answer D is incorrect; if there is an undo tablespace and you are using automatic undo, you will not be using the SYSTEM rollback segment. |
| 7: | Your UNDO_SUPPRESS_ERRORS parameter is set to TRUE. What are the ramifications to your applications because of this setting? A. Your applications won't be able to suppress errors any more. B. Your application won't generate errors any more. C. You will get errors connected to automatic undo segments. D. You won't get errors if your application attempts to online or offline rollback segments.
|
| A7: | Answer D is correct; errors connected to use of manual undo will be suppressed if you are using automatic undo management and manual undo commands. Answer A is incorrect; your application will suppress manual undo command errors. Answer B is incorrect; your application will generate application errors but not manual undo errors. Answer C is incorrect; you are running automatic undo management, and you will get automatic undo errors if they are generated. |
| 8: | If you need to retain undo information for 20 minutes, to what do you need to set UNDO_RETENTION? |
| A8: | Answer A is correct; you need to set the UNDO_RETENTION parameter to 1200 for 1200 seconds. Answer B is incorrect; UNDO_RETENTION is in seconds, not in minutes. Answer C is incorrect; there is no math needed past the number of minutes * 60 seconds. Answer D is incorrect; UNDO_RETENTION is in seconds not in megabytes. |
| 9: | What is the effect of the following statement on an instance using an SPFILE? ALTER SYSTEM SET UNDO_MANAGEMENT AUTO;
A. The system will immediately be in automatic undo management mode. B. The system will be in automatic undo management mode after you define an undo tablespace. C. You will be in automatic undo management mode after you restart the instance. D. Nothing, all databases run in automatic undo mode in Oracle 9i.
|
| A9: | Answer C is correct; you need to restart the database to change undo management mode. Answer A is incorrect; UNDO_MANAGEMENT is not a dynamic parameter. Answer B is incorrect; you do have to have an undo tablespace defined, but you still need to restart the database. Answer D is incorrect; manual undo is still the default method in Oracle 9i. Automatic undo is the suggested method. |
| 10: | What is not a purpose of undo segments? [select all that apply] A. To enable transaction rollback B. To enable read consistency C. To enable transaction read consistency D. To enable instance recovery
|
| A10: | Answer D is correct. The only answer that is not a purpose of undo segments is to enable instance recoverythat is, redo log files. Answers A, B, and C are all purposes of undo segments. |
