OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P88 pot

OCA/OCP Oracle Database 11g All-in-One Exam Guide 826 10. Tidy up with Database Control: connect as SYSTEM. 11. From the database home page take the Server tab, then the Windows link in the Oracle Scheduler section. Select the DAYTIME window, and click DELETE. Two-Minute Drill Create a Job, Program, and Schedule • A job can specify what to do and when to do it, or it can point to a program and/or a schedule. • A job (or its program) can be an anonymous PL/SQL block, a stored procedure, or an external operating system command or script. • Either Database Control or the DBMS_SCHEDULER API can be used to manage the Scheduler environment. Use a Time-Based or Event-Based Schedule for Executing Scheduler Jobs • A time-based schedule has start and end dates, and a repeat interval. • The repeat interval can be a date expression, or a calendaring expression consisting of a frequency, an interval, and possibly several specifiers. • An event-based schedule uses an agent to query an Advanced Queue, and launches jobs depending on the content of the queued messages. Create Lightweight Jobs • A lightweight job has less overhead in the data dictionary than a regular job, and therefore large numbers of them can be created much faster than an equivalent number of regular jobs. • Lightweight jobs do not have the full range of attributes that regular jobs have. Use Job Chains to Perform a Series of Related Tasks • A chain object consists of a number of steps. • Each step can launch a program. • Simple logic (such as the success or failure of a previous step) can control the flow of execution through a job chain with branching steps. Chapter 22: The Scheduler 827 PART III Create Windows and Job Classes • A window is a defined period during which certain jobs may run, that will itself open according to an embedded schedule or a preexisting schedule object. • A window can activate a Resource Manager plan. • Only one window can be open at once. • If windows overlap, the open window will be determined by which has HIGH or LOW priority. • A job class associates the jobs in the class with a Resource Manager consumer group. Use Advanced Scheduler Concepts to Prioritize Jobs • Jobs can be prioritized at two levels: the Resource Manager will allocate resources via consumer groups to all the jobs in a class, and the class will prioritize the jobs within it according to the job priority set by the Scheduler. • Scheduler priority varies between levels 1 to 5 (highest to lowest). Self Test 1. When a job is due to run, what process will run it? (Choose the best answer.) A. A CJQn process B. A Jnnn process C. A server process D. A background process 2. Which of the following is a requirement if the Scheduler is to work? (Choose the best answer.) A. The instance parameter JOB_QUEUE_PROCESSES must be set. B. A Resource Manager plan must be enabled. C. A schedule must have been created. D. All of the above. E. None of the above. 3. A Scheduler job can be of several types. Choose all that apply: A. An anonymous PL/SQL block B. An executable operating system file C. A PL/SQL stored procedure D. A Java stored procedure E. An operating system command F. An operating system shell script (Unix) or batch file (Windows) OCA/OCP Oracle Database 11g All-in-One Exam Guide 828 4. You create a job with this syntax: exec dbms_scheduler.create_job(- job_name=>'j1',- program_name=>'p1',- schedule_name=>'s1',- job_class=>'c1'); and find that it is not running when expected. What might be a reason for this? (Choose the best answer.) A. The schedule is associated with a window, which has not opened. B. The job has not been enabled. C. The class is part of a Resource Manager consumer group with low priority. D. The permissions on the job are not correct. 5. What are the possible priority levels of a job within a class? (Choose the best answer.) A. 1 to 5 B. 1 to 999 C. HIGH or LOW D. It depends on the Resource Manager plan in effect 6. You want job to run every 30 minutes. Which of the following possibilities for the REPEAT_INTERVAL argument are correct syntactically and will achieve this result? (Choose two answers.) A. 'freq=minutely;interval=30' B. 'freq=hourly;interval=1/2' C. '0 00:30:00' D. 'freq=minutely;byminute=30' E. 'freq=byminute;interval=30' 7. You create a job class, and you set the LOGGING_LEVEL argument to LOGGING_RUNS. What will be the result? (Choose the best answer.) A. There will be a log entry for each run of each job in the class, but no information on whether the job was successful. B. There will be a log entry for each run of each job in the class, and information on whether the job was successful. C. There will be a single log entry for the class whenever it is run. D. You cannot set logging per class, only per job. 8. Which of the following statements (if any) are correct regarding how Scheduler components can be used together? (Choose all that apply.) A. A schedule can be used by many jobs. B. A job can use many programs. Chapter 22: The Scheduler 829 PART III C. A class can have many programs. D. Job priorities can be set within a class. E. Consumer groups control priorities within a class. F. A Resource Manager plan can be activated by a schedule. 9. Which view will tell you about jobs configured with the Scheduler? (Choose the best answer.) A. DBA_JOBS B. DBA_SCHEDULER C. DBA_SCHEDULED_JOBS D. DBA_SCHEDULER_JOBS 10. If two windows are overlapping and have equal priority, which window(s) will be open? (Choose the best answer.) A. Both windows will be open. B. Windows cannot overlap. C. Whichever window opened first will remain open; the other will remain closed. D. Whichever window opened first will be closed, and the other will open. E. It will depend on which window has the longest to run. Self Test Answers 1. þ B. Jobs are run by job queue processes. ý A, C, and D. The job queue coordinator does not run jobs; it assigns them to job queue processes. These are not classed as background processes, and they are not server processes. 2. þ E. The Scheduler is available, by default, with no preconfiguration steps needed. ý A, B, C, and D. A is wrong because (in release 11g) the JOB_QUEUE_ PROCESSES instance parameter defaults to 1000; therefore, it does not need to be set. B and C are wrong because the Resource Manager is not required, and neither is a schedule. 3. þ A, B, C, D, E, and F. The JOB_TYPE can be PLSQL_BLOCK, or STORED_ PROCEDURE (which can be PL/SQL or Java), or EXECUTABLE (which includes executable files, OS commands, or shell scripts). ý All the answers are correct. OCA/OCP Oracle Database 11g All-in-One Exam Guide 830 4. þ B. The job will, by default, not be enabled and therefore cannot run. ý A, C, and D. A is wrong because the job is not controlled by a window, but by a schedule. C is wrong because while the Resource Manager can control job priority, it would not in most circumstances block a job completely. D is wrong because while permissions might cause a job to fail, they would not stop it from running. 5. þ A. Job priorities are 1 to 5 (highest to lowest). ý B, C, and D. B is wrong because it is the incorrect range. C is the choice for window priority, not job priority. D is wrong because the Resource Manager controls priorities between classes, not within them. 6. þ A and B. Both will provide a half-hour repeat interval. ý C, D, and E. C is the syntax for a window’s duration, not a repeat interval. D and E are syntactically wrong: there is no such specifier as BYMINUTE (though such a specifier might be useful). 7. þ B. With logging set to LOGGING_RUNS, you will get records of each run of each job, including the success or failure. ý A, C, and D. A is wrong because LOGGING_RUNS will include the success or failure. C and D are wrong because even though logging is set at the class level, it is applied at the job level. Note that logging can also be set at the job level. 8. þ A and D. Many jobs can be controlled by one schedule, and Scheduler priorities are applied to jobs within classes. ý B, C, E, and F. B and C both misunderstand the many-to-one relationships of Scheduler objects. E is wrong because consumer groups control priorities between classes, not within them. F is wrong because plans are activated by windows, not schedules. 9. þ D. The DBA_SCHEDULER_JOBS view externalizes the data dictionary jobs table, with one row per scheduled job. ý A, B, and C. A is wrong because DBA_JOBS describes the jobs scheduled through the old DBMS_JOB system. B and C refer to views that do not exist. 10. þ E. Other things being equal, the window with the longest to run will open (or remain open). ý A, B, C, and D. Only one window can be open at once, and windows can overlap. The algorithms that manage overlapping windows are not well documented, but neither C nor D is definitively correct. CHAPTER 23 Moving and Reorganizing Data Exam Objectives In this chapter you will learn to • 052.17.1 Describe and Use Methods to Move Data (Directory Objects, SQL*Loader, External Tables) • 052.17.2 Explain the General Architecture of Oracle Data Pump • 052.17.3 Use Data Pump Export and Import to Move Data Between Oracle Databases • 053.16.2 Describe the Concepts of Transportable Tablespaces and Databases • 053.16.1 Manage Resumable Space Allocation • 053.16.3 Reclaim Wasted Space from Tables and Indexes by Using the Segment Shrink Functionality 831 OCA/OCP Oracle Database 11g All-in-One Exam Guide 83 2 There are many situations where bulk transfers of data into a database or between databases are necessary. Common cases include populating a data warehouse with data extracted from transaction processing systems, or copying data from live systems to test or development environments. As entering data with standard INSERT statements is not always the best way to do large-scale operations, the Oracle database comes with facilities designed for bulk operations. These are SQL*Loader and Data Pump. There is also the option of reading data without ever actually inserting it into the database; this is accomplished through the use of external tables. Data loading operations, as well as DML, may fail because of space problems. This can be an appalling waste of time. The resumable space allocation mechanism can provide a way to ameliorate the effect of space problems. There are also techniques to reclaim space that is inappropriately assigned to objects and make it available for reuse. SQL*Loader In many cases you will be faced with a need to do a bulk upload of datasets generated from some third-party system. This is the purpose of SQL*Loader. The input files may be generated by anything, but as long as the layout conforms to something that SQL*Loader can understand, it will upload the data successfully. Your task as DBA is to configure a SQL*Loader controlfile that can interpret the contents of the input datafiles; SQL*Loader will then insert the data. Architecturally, SQL*Loader is a user process like any other: it connects to the database via a server process. To insert rows, it can use two techniques: conventional or direct path. A conventional insert uses absolutely ordinary INSERT statements. The SQL*Loader user process constructs an INSERT statement with bind variables in the VALUES clause and then reads the source datafile to execute the INSERT once for each row to be inserted. This method uses the database buffer cache and generates undo and redo data: these are INSERT statements like any others, and normal commit processing makes them permanent. The direct path load bypasses the database buffer cache. SQL*Loader reads the source datafile and sends its contents to the server process. The server process then assembles blocks of table data in its PGA and writes them directly to the datafiles. The write is above the high water mark of the table and is known as a data save. The high water mark is a marker in the table segment above which no data has ever been written: the space above the high water mark is space allocated to the table that has not yet been used. Once the load is complete, SQL*Loader shifts the high water mark up to include the newly written blocks, and the rows within them are then immediately visible to other users. This is the equivalent of a COMMIT. No undo is generated, and if you wish, you can switch off the generation of redo as well. For these reasons, direct path loading is extremely fast, and furthermore it should not impact on your end users, because interaction with the SGA is kept to a minimum. Direct path loads are very fast, but they do have drawbacks: • Referential integrity constraints must be dropped or disabled for the duration of the operation. • INSERT triggers do not fire. Chapter 23: Moving and Reorganizing Data 833 PART III • The table will be locked against DML from other sessions. • It is not possible to use direct path for clustered tables. These limitations are a result of the lack of interaction with the SGA while the load is in progress. EXAM TIP Only UNIQUE, PRIMARY KEY, and NOT NULL constraints are enforced during a direct path load; INSERT triggers do not fire; the table is locked for DML. SQL*Loader uses a number of files. The input datafiles are the source data that it will upload into the database. The controlfile is a text file with directives telling SQL*Loader how to interpret the contents of the input files, and what to do with the rows it extracts from them. Log files summarize the success (or otherwise) of the job, with detail of any errors. Rows extracted from the input files may be rejected by SQL*Loader (perhaps because they do not conform to the format expected by the controlfile) or by the database (for instance, insertion might violate an integrity constraint); in either case they are written out to a bad file. If rows are successfully extracted from the input but rejected because they did not match some record selection criterion, they are written out to a reject file. The controlfile is a text file instructing SQL*Loader on how to process the input datafiles. It is possible to include the actual data to be loaded on the controlfile, but you would not normally do this; usually, you will create one controlfile and reuse it, on a regular basis, with different input datafiles. The variety of input formats that SQL*Loader can understand is limited only by your ingenuity in constructing a controlfile. Consider this table: SQL> desc dept; Name Null? Type DEPTNO NOT NULL NUMBER(2) DNAME VARCHAR2(14) LOC VARCHAR2(13) And this source datafile, named DEPTS.TXT: 60,CONSULTING,TORONTO 70,HR,OXFORD 80,EDUCATION, A SQL*Loader controlfile to load this data is DEPTS.CTL: 1 load data 2 infile 'depts.txt' 3 badfile 'depts.bad' 4 discardfile 'depts.dsc' 5 append 6 into table dept 7 fields terminated by ',' 8 trailing nullcols 9 (deptno integer external(2), 10 dname, 11 loc) OCA/OCP Oracle Database 11g All-in-One Exam Guide 834 To perform the load, from an operating system prompt run this command: sqlldr userid=scott/tiger control=depts.ctl direct=true This command launches the SQL*Loader user process, connects to the local database as user SCOTT password TIGER, and then performs the actions specified in the controlfile DEPTS.CTL. The DIRECT=TRUE argument instructs SQL*Loader to use the direct path rather than conventional insert (which is the default). Taking the controlfile line by line: Line Purpose 1 Start a new load operation. 2 Nominate the source of the data. 3 Nominate the file to write out any badly formatted records. 4 Nominate the file to write out any unselected records. 5 Add rows to the table (rather than, for example, truncating it first). 6 Nominate the table for insertion. 7 Specify the field delimiter in the source file. 8 If there are missing fields, insert NULL values. 9, 10, 11 The columns into which to insert the data. This is a very simple example. The syntax of the controlfile can handle a wide range of formats with intelligent parsing to fix any deviations in format such as length or data types. In general you can assume that it is possible to construct a controlfile that will understand just about any input datafile. However, do not think that it is always easy. TIP It may be very difficult to get a controlfile right, but once you have it, you can use it repeatedly, with different input datafiles for each run. It is then the responsibility of the feeder system to produce input datafiles that match your controlfile, rather than the other way around. External Tables An external table is visible to SELECT statements as any other table, but you cannot perform DML against it. This is because it does not exist as a segment in the database: it exists only as a data dictionary construct, pointing toward one or more operating system files. Using external files is an alternative to using SQL*Loader, and is often much more convenient. The operating system files of external tables are located through Oracle directory objects. Directories are also a requirement for Data Pump, discussed later in this chapter. Chapter 23: Moving and Reorganizing Data 835 PART III Directories Oracle directories provide a layer of abstraction between the user and the operating system: you as DBA create a directory object within the database, which points to a physical path on the file system. Permissions on these Oracle directories can then be granted to individual database users. At the operating system level, the Oracle user will need permissions against the operating system directories to which the Oracle directories refer. Directories can be created either from a SQL*Plus prompt or from within Database Control. To see information about directories, query the view DBA_DIRECTORIES. Each directory has a name, an owner, and the physical path to which it refers. Note that Oracle does not verify whether the path exists when you create the directory—if it does not, or if the operating system user who owns the Oracle software does not have permission to read and write to it, you will only get an error when you actually use the directory. Having created a directory, you must give the Oracle database user(s) who will be making use of the directory permission to read from and write to it, just as your system administrators must give the operating system user permission to read from and write to the physical path. EXAM TIP Directories are always owned by user SYS, but any user to whom you have granted the CREATE ANY DIRECTORY privilege can create them. Figure 23-1 demonstrates how to create directories, using SQL*Plus. In the figure, user SCOTT attempts to create a directory pointing to his operating system home directory on the database server machine. This fails because, by default, users do not have permission to do this. After being granted permission, he tries again. As the directory creator, he will have full privileges on the directory. He then grants read permission on the directory (and therefore any files within it) to all users, and read and write permission to one user. The query against ALL_DIRECTORIES shows that the directory (like all directories) is owned by SYS: directories are not schema objects. This is why SCOTT cannot drop the directory, even though he created it. Using External Tables A common use of external tables is to avoid the necessity to use SQL*Loader to read data into the database. This can give huge savings in the ETL (extract-transform-load) cycle typically used to update a DSS system with data from a feeder system. Consider the case where a feeder system regularly generates a dataset as a flat ASCII file, which should be merged into existing database tables. One approach would be to use SQL*Loader to load the data into a staging table, and then a separate routine to merge the rows from the staging table into the DSS tables. This second routine cannot start until the load is finished. Using external tables, the merge routine can read the source data from the operating system file(s) without having to wait for it to be loaded. . Use Data Pump Export and Import to Move Data Between Oracle Databases • 053.16.2 Describe the Concepts of Transportable Tablespaces and Databases • 053.16.1 Manage Resumable Space Allocation •. OCA/ OCP Oracle Database 11g All-in-One Exam Guide 826 10. Tidy up with Database Control: connect as SYSTEM. 11. From the database home page take the Server tab, then the Windows. transfers of data into a database or between databases are necessary. Common cases include populating a data warehouse with data extracted from transaction processing systems, or copying data from