In this chapter, we will discuss the architecture of the Oracle database. We're talking about storage structures, processes, and files that make up an Oracle database. Knowing how to do Oracle jobs is important because otherwise, it's just a black box sitting on a shelf. Consider a car and its engine. For most people, a car is a black car box. They start him driving. One day, the engine doesn't start anymore. If you don't have one who knows how to repair a car engine, what do you do? You go to a professional field, mechanic. They know how to fix the black box that takes you back and goes to work every day. Some readers of this blog may know a lot about cars. the motor that I have no problem fixing no matter what is broken. Others read that the blog is in the middle and probably knows a little about the combustion engine, just to solve small problems, but not enough to solve the main problem.
As an Oracle database administrator, your organization is counting on you to solve this problem. the black box they use to store their valuable data. As a mechanic, you must have an in-depth knowledge of how engine components fit together to make a car Come on, a database administrator must understand how Oracle components work in conjunction with each other. Your organization hires you as a data protection machine. If you are reading this blog, you are probably not in the category of An expert who knows exactly how Oracle works, but you are not one of those who deal with Oracle yet and not a black box. You're probably in the middle. If so, then this chapter is for you. After all, you are reading this blog because you want to do it journey from entry-level DBA or higher all the way to expert in the field. I recommend you read the Oracle Database Concepts Guide. This blog on Oracle Books provides a lot of information on how to do it The Oracle database is running. Please read this guide. In this chapter, I will discuss a topic from my perspective. I will also look at the areas that are important to me to understand Oracle architecture. This chapter does not replace reading the blog A Guide to Database Concepts. While you are in Oracle books, read the Database Administrator's Guide.
As you work with Oracle Database during your career, you will learn than in this structure. When I started as an Oracle database administrator, trying to understand how Oracle works was the biggest headache to solve, as well as the most fun. Although I have worked with Oracle for over three years, I am I continue to learn new details about Oracle architecture. It's not just that I'm increasing that deep into Oracle internals, but Oracle changes the architecture a little here and there and every new type.
Oracle Database Architecture Overview
There are two terms that are used with Oracle
Database - A collection of physical operating system files.
Instance - A set of Oracle processes and an SGA (allocation of memory).
These two are very closely related but a database can be mounted and opened by many instances. An instance may mount and open only a single database at any one point in time.
Listing 1- 01. Database Vs Instance
Database Vs Instance: In Oracle architecture, there is a big difference between the Oracle database and the Oracle example. They are not the same thing. As a database administrator, you must understand both, what they mean and how they interact. An Oracle database is a collection of files on disk. The following files are included tablespace data files, control files, and online redo logs. What is data protection? live when Oracle is not running. Oracle software is low, but the files were there. The database is still on disk, but no one can access it. To view the database, we can issue requests as shown in Listing 1- 02.
Listing 1- 02. Database Files
The SQL statement above queries data files, control files, online redo logs, and temporary files. This file collection is an Oracle database. You'll hear people say things like "I can't connect to the database. Technical skills In other words, you cannot connect to the Oracle database. The software is running on another machine, perhaps even a web server, which is accessible by A Navigator. The application does not have direct access to the file, so cannot be linked and data protection. This is where DBAs need to know their audience. For the end user, Oracle is a black box and they have to use the word database. When the DBA speaks to end users, they should use the same vocabulary to facilitate conversation, at least although the DBA knows that the statement is not true.
Users and applications connect to the Oracle instance, not the database. An example is a system configuration and allocated memory from Oracle's origin software. When a user spawns a process the server database interacts with allocated memory and database files, as we will see in this chapter. When the DBA starts Oracle, it starts the instance. When the DBA shuts down At the bottom of the example, the database is still on disk. An example is a collection of processes and memory. A database is a file on a virtual disk. When communicating with other Oracles professionals, you'll want to use the right vocabulary. When communicating with others, be sensitive and free to use the word Database.
Oracle Physical Storage Structures
For Oracle databases, there are eight different file types, each of which is described here:
• Data files: Each tablespace contains one or more data files disc. A data file can only be one table space, but a table space can contain multiple data files. These hold the tables, indexes, and all other segments.
• Temporary file: All temporary tablespaces contain one or more files special files called temporary files. Oracle distinguishes between data files containing data to survive instance closure, and temporary files are deleted when the instance starts. This marks the difference between the two file types, Oracle RMAN can save them differently. RMAN will not delay Saving the contents of the file temporarily because the data will not be available there when the instance restarts. Temporary files are used when An SQL statement executes a form or join function that is too large in his memory. The work is broken into pieces and time is stored in the TEMP tablespace.
• Online redo logs: When a transaction occurs, Oracle needs to be able to replay, or redo, that transaction to aid in any recovery efforts. The redo information is written to the online redo logs (ORLs). The ORLs are created in groups. You should have a minimum of three and usually no more than five ORL groups. When redo information is written, it all goes to one ORL group. When that group is filled, Oracle will perform a log switch where a redo is written to the next ORL group. Once the last ORL group is filled, the next log switch will go back to the first ORL group, overwriting what was there. Ideally, the ORL groups should be large enough so that there are only three or four log switches during a peak hour of transactional activity in the instance. The ORLs are vital to database operations. As such, the ORL groups should be multiplexed, which means Oracle maintains a mirror copy of the file. The two copies should not be on the same disk.
• Archived redo logs: As stated above, the ORL groups will eventually be overwritten. If the DBA needs to save the redo records for longer periods, the database must be configured in archive log mode. When a log switch occurs, Oracle will copy the previous ORL to an archive log destination. we turned on archive log mode for our testbed database. Redo log files that have been archived.
• Undo tablespace files: The undo tablespace has its own data files. Technically, Oracle considers the files for the Undo tablespace to be just like regular data files. However, the data in the undo tablespace will not survive instance shutdown, which makes the undo tablespace’s data files more similar to temp files. I classify these files differently than regular files if for no other reason than to know they are different than regular data files. allows a user to roll back a transaction and provides read consistency.
• Control files: The control file is the master pointer for the database. When an Oracle instance starts, the instance has no clue where the database’s files are located. However, the instance does know the location of the control files from the required CONTROL_FILES initialization parameter. The instance reads the data file locations from the control files. The control files also contain any other information Oracle may need before the instance is started. The control files also contain information about RMAN backups and the database’s name and unique identifier. You should create production databases with three control files, all on different disk units. Details the location of data and log files and other relevant information about their state.
Listing 1- 03. Physical Storage Structures
• Parameter file: When the Oracle instance starts, it will first find file management. Examples should also be aware of memory limitations to assign and many other control parameters Various parameters apply to Oracle. These settings are saved in the settings file. Technically, the settings file is not part of the "Database", but it is an important file to know. These files tell Oracle where to find the control files. Also, they detail how big the memory area will be, etc.
• Alert and Trace Log Files: When things go wrong, Oracle can and often does write messages to the alert log and, in the case of background processes or user sessions, trace log files. The alert log file, located in the directory specified by the initialization parameter BACKGROUND_DUMP_DEST, contains both routine status messages as well as error conditions when the database is started up or shut down, a message is recorded in the alert log, along with a list of initialization parameters that are different from their default values. In addition, any alter database or alter system commands issued by the DBA are recorded. Operations involving tablespaces and their data files are recorded here, too, such as adding a tablespace, dropping a tablespace, and adding a data file to a tablespace. Error conditions, such as tablespaces running out of space, corrupted redo logs, and so forth, are also recorded here. The trace files for the Oracle instance background processes are also located in BACKGROUND_DUMP_DEST. For example, the trace files for PMON and SMON contain an entry when an error occurs or when SMON needs to perform instance recovery; the trace files for QMON contain informational messages when it spawns a new process. Trace files are also created for individual user sessions or connections to the database. These trace files are located in the directory specified by the initialization parameter USER_DUMP_DEST. Trace files for user processes are created in two situations: The first is when some type of error occurs in a user session because of a privilege problem, running out of space, and so forth. In the second situation, a trace file can be created explicitly with the command alter session set sql_trace=true. Trace information is generated for each SQL statement that the user executes, which can be helpful when tuning a user’s SQL statement. The alert log file can be deleted or renamed at any time; it is re-created the next time an alert log message is generated. The DBA will often set up a daily batch job (either through an operating system mechanism or using Oracle Enterprise Manager’s scheduler) to rename and archive the alert log daily.
• Backup Files: Backup files can originate from several sources, such as operating system copy commands or Oracle Recovery Manager (RMAN). If the DBA performs a “cold” backup (see the section titled “Backup/Recovery Overview” for more details on backup types), the backup files are simply operating system copies of the data files, redo log files, control files, archived redo log files, and so forth.In addition to bit-for-bit image copies of datafiles (the default in RMAN), RMAN can generate full and incremental backups of datafiles, control files, archived redo log files, and SPFILEs that are in a special format, called backup sets, only readable by RMAN. RMAN backup set backups are generally smaller than the original data files because RMAN does not back up unused blocks.
• Oracle Managed Files: Oracle Managed Files (OMF), introduced in Oracle version 9i, makes the DBA’s job easier by automating the creation and removal of the data files that make up the logical structures in the database. Without OMF, a DBA might drop a tablespace and forget to remove the underlying operating system files. This makes inefficient use of disk resources, and it unnecessarily increases backup time for data files that are no longer needed by the database.OMF is well suited for small databases with a low number of users and a part-time DBA, where the optimal configuration of a production database is not necessary.
• Password file: An Oracle password file is a file within the Oracle administrative or software directory structure on disk used to authenticate Oracle system administrators for tasks such as creating a database or starting up and shutting down the database. The privileges granted through this file are the SYSDBA and SYSOPER privileges. Authenticating any other type of user is done within the database itself; because the database may be shut down or not mounted, another form of administrator authentication is necessary in these cases. The Oracle command-line utility orapwd creates a password file if one does not exist or is damaged. Because of the extremely high privileges granted via this file, it should be stored in a secure directory location that is unavailable to anyone except for DBAs and operating system administrators. Once this file is created, the initialization parameter REMOTE_LOGIN_PASSWORDFILE should be set to EXCLUSIVE to allow users other than SYS to use the password file.
TIP: Create at least one user other than SYS or SYSTEM who has DBA privileges for daily administrative tasks. If more than one DBA is administering a database, each DBA should have its own account with DBA privileges.
