Bordoloi and Bock Copyright 2004 Prentice Hall, Inc.


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Bordoloi and Bock Copyright 2004 Prentice Hall, Inc.

  2. 2. <ul><li>Database administration is a specialized area within a large information systems department that is separate from the application development area. </li></ul><ul><li>Application development includes systems analysis, systems design, programming, and systems testing. </li></ul><ul><li>Database administration is concerned with administrative tasks that must be accomplished in order for application developers and information system users to access an organization's databases. </li></ul><ul><li>A database administrator (DBA) is neither superior to nor inferior to an application developer. </li></ul><ul><li>Contd. </li></ul>DATABASE ADMINISTRATION OVERVIEW
  3. 3. <ul><li>DBAs and application developers must be both technically competent and capable of working closely with other professionals in a support type of relationship. </li></ul><ul><li>One of the primary roles of a DBA is to provide the support needed by an application developer so that the application developer can accomplish the task of building and maintaining information systems. </li></ul>DATABASE ADMINISTRATION OVERVIEW
  4. 4. <ul><li>Install relational database management system software and upgrades. </li></ul><ul><li>Design and create a database including the allocation of system disk storage for current and future database storage requirements. </li></ul><ul><li>Start up and shut down a database. </li></ul><ul><li>Create user accounts and monitor user activities. </li></ul><ul><li>Grant database privileges to control data security and data access. </li></ul>DBA Duties
  5. 5. <ul><li>Backup and recover a database in the event of system failure. </li></ul><ul><li>Tune a database to optimize database performance. </li></ul><ul><li>Manage database network connectivity. </li></ul><ul><li>Migrate a database to a new version of the DBMS software. </li></ul>DBA Duties
  6. 6. ORGANIZATION OF AN ORACLE DATABASE <ul><li>An Oracle relational database is typical of databases running on larger relational database management systems, and includes both memory and disk storage components. </li></ul><ul><li>Figure 12.1 provides a fairly detailed conceptual model of what is termed an Oracle Instance . </li></ul>
  7. 7. <ul><li>The large rectangle in the figure labeled Memory Allocated to the Instance represents part of a server computer's random access memory (RAM). </li></ul><ul><li>This part of RAM is strictly allocated to a running instance of an Oracle database. </li></ul><ul><li>The instance includes the system global area (SGA) , and the SGA is divided into the database buffer cache , redo log buffer , shared pool , large pool , and JAVA pool . </li></ul><ul><li>The instance also includes memory allocated for computer programs called background processes . </li></ul><ul><li>The background processes are part of the Oracle instance , and are actually computer programs. </li></ul>Oracle Instance
  8. 8. <ul><li>These programs provide the services needed to enable system developers and system users to save database objects such as data tables and data rows in tables. </li></ul><ul><li>The background processes also enable database recovery, database backup, data archiving, and other data management tasks as necessary. </li></ul><ul><li>An Oracle database does not normally run on a personal computer, although there is a version of Oracle called Personal Oracle that will do just that. </li></ul><ul><li>An Oracle database is very large and resides on a powerful server computer. </li></ul>Oracle Instance
  9. 9. <ul><li>A server computer is typically connected to many disk drives. </li></ul><ul><li>The database files shown in the figure typically include many different physical files stored on many disk drives. </li></ul><ul><li>Database files provide the primary storage for all objects stored in a database. This is where user tables and data are stored. </li></ul><ul><li>The redo log files in the figure store information that is used to recover a database if some type of database failure occurs. </li></ul><ul><li>The control files store information about the actual physical organization of an Oracle database. </li></ul>Oracle Instance
  10. 10. <ul><li>The parameter file stores information that Oracle needs in order to operate the database as specified by the DBA. </li></ul><ul><li>When a system user logs onto an Oracle database or when an application program executes, Oracle allocates a memory object called a server process as shown in the figure. </li></ul><ul><li>The dedicated server version of Oracle allocates one server process to each system user process. </li></ul><ul><li>The multi-threaded server version of Oracle allows server processes to be shared by more than one system user process. </li></ul>Oracle Instance
  11. 11. <ul><li>A server process communicates with a user process in order to service the data requests from the connected user process.  </li></ul><ul><li>The server process actually interprets the SQL commands passed from the user process through the server process to Oracle, and moves the requested data from the database files into the database buffer cache. </li></ul><ul><li>Suppose that a system user executes an SQL command that will modify an existing data row stored in an Oracle database, the data row is moved from a database file to the server process allocated to the system user, and then to the database buffer cache in the system global area . </li></ul>Oracle Instance
  12. 12. <ul><li>The database buffer cache is a memory object that is shared by all system users. </li></ul><ul><li>This sharing improves system performance because more than one user process may need to access the same data row. </li></ul><ul><li>Data inside the database buffer cache are constantly being modified as data rows are added, deleted, and updated. </li></ul><ul><li>Modified data blocks (a single data block typically contains many rows of data) are written from the database buffer cache by a background process called the database writer (DBWn) back to the appropriate disk data file, thereby saving the data to the magnetic hard disk. </li></ul>Oracle Instance
  13. 13. <ul><li>As existing data rows in the database buffer cache are modified or new data rows are created, memory images of these modifications and new rows are stored to the redo log buffer in the system global area. </li></ul><ul><li>As the redo log buffer in memory fills up, the modified row images are written to the redo log files on disk by a different background process called the log writer (LGWR) . </li></ul><ul><li>The redo log files are magnetic hard disk objects; thus, their data are not lost if electrical power fails. </li></ul><ul><li>Over time, the redo log files can be archived to provide a more permanent record of database changes. </li></ul>Oracle Instance
  14. 14. <ul><li>The data in redo log buffers and in redo log files are used to recover a database in the event of some type of system failure. </li></ul><ul><li>In addition to the database writer and log writer background processes, there are other background processes that perform additional database administration tasks such as managing memory space allocated to Oracle by the operating system, archiving data, and performing backup and recovery. </li></ul><ul><li>Some of these processes manage the shared pool, large pool, and JAVA pool. </li></ul>Oracle Instance
  15. 15. <ul><li>The shared pool is shared by all server processes in order to improve performance efficiency of an Oracle database. </li></ul><ul><li>The large pool is memory that can be used to store variables and other memory values that would be part of an individual system user's allocated server process. </li></ul><ul><li>The Java Pool is used for memory allocation in support of the execution of Java commands for Internet-based applications accessing an Oracle database. </li></ul>Oracle Instance
  16. 16. <ul><li>An Oracle database is normally divided into logical components termed tablespaces . </li></ul><ul><li>Most tablespaces are created by a DBA when a database is initially created. </li></ul><ul><li>As the term implies, a tablespace is used to store tables. </li></ul><ul><li>But, tablespaces are actually used to store all types of database objects. </li></ul><ul><li>These objects include indexes, sequences, procedures, views, and other database objects. </li></ul>TABLESPACES AND FILES
  17. 17. <ul><li>A typical Oracle database will have most of the tablespaces listed here. </li></ul><ul><ul><li>SYSTEM </li></ul></ul><ul><ul><li>USER </li></ul></ul><ul><ul><li>DATA </li></ul></ul><ul><ul><li>INDEXES </li></ul></ul><ul><ul><li>TEMP </li></ul></ul><ul><ul><li>UNDO </li></ul></ul><ul><ul><li>IDS </li></ul></ul><ul><ul><li>SPECIAL_APPS </li></ul></ul>TABLESPACES AND FILES
  18. 18. <ul><li>Tablespaces are logical , not physical objects. </li></ul><ul><li>Tablespaces are actually stored in data files . </li></ul><ul><li>Data files are the corresponding physical objects. </li></ul><ul><li>A very large tablespace may require more than one data file in order to store all of its objects. </li></ul><ul><li>A data file can only store data for a single tablespace. </li></ul><ul><li>Tablespaces are created with the CREATE TABLESPACE command. </li></ul>TABLESPACES AND FILES
  19. 19. <ul><li>The Oracle data dictionary consists of read-only, base tables that store information about the database. </li></ul><ul><li>The data dictionary is stored in the system tablespace. </li></ul><ul><li>Information stored in the data dictionary is termed metadata ; that is, data about data. </li></ul><ul><li>The read-only, base tables that comprise the data dictionary are rarely ever accessed by system developers or system users. </li></ul><ul><li>Usually only the various Oracle processes will access these tables. </li></ul>DATA DICTIONARY
  20. 20. <ul><li>In order to make it easier to access information and manage a database, the tables of the data dictionary are organized into various user-accessible views . </li></ul><ul><li>These views are also part of the data dictionary. </li></ul>DATA DICTIONARY
  21. 21. <ul><li>Some of the information stored in the data dictionary includes: </li></ul><ul><ul><li>all schema object definitions – the definitions of the tables, indexes, sequences, views, and other database objects. </li></ul></ul><ul><ul><li>the amount of space allocated for each object, and the amount of space currently used by each object. </li></ul></ul><ul><ul><li>the names of the Oracle user accounts, and the privileges and roles granted to each account. </li></ul></ul><ul><ul><li>information needed to enforce integrity constraints. </li></ul></ul><ul><ul><li>other database information. </li></ul></ul>DATA DICTIONARY
  22. 22. <ul><li>When an Oracle database is created, two special user accounts named SYS and SYSTEM are created. </li></ul><ul><li>The user account SYS is the owner of all base tables and user-accessible views in the data dictionary. </li></ul><ul><li>The security of the SYS account is quite tight and only DBAs can access this account. </li></ul><ul><li>During database operation, Oracle accesses the base tables through the SYS account. </li></ul><ul><li>For this reason, only Oracle can write new data or modify existing data in the base tables. </li></ul><ul><li>Individual system users should never be given privileges to UPDATE, INSERT, or DELETE rows for these data dictionary tables. </li></ul>THE SYSTEM AND SYS ACCOUNTS
  23. 23. <ul><li>When Oracle software or third-party software adds new tables and views to the data dictionary, the owner of these new objects is the user SYSTEM. </li></ul><ul><li>Again, access to the SYSTEM account is also tight and is typically restricted to DBAs. </li></ul>THE SYSTEM AND SYS ACCOUNTS
  24. 24. <ul><li>There are many different types of data dictionary views. </li></ul><ul><li>In order to assist system users in using the data dictionary, the views are divided into three different categories: USER, ALL, and DBA. </li></ul><ul><ul><li>USER – The user prefix is added to all views that display information about objects that belong to an individual user. We term this the user's schema of the database. </li></ul></ul><ul><ul><li>ALL – The all prefix is added to all views that display information about all objects in the global database schema. This expands on an individual user's perspective of the database. </li></ul></ul><ul><ul><li>DBA – The dba prefix is added to all views that fall within the database administrator's schema of the database. </li></ul></ul>TYPES OF VIEWS –USER, ALL, and DBA
  25. 25. <ul><li>Individual accounts, including those that belong to DBAs must be created. </li></ul><ul><li>When a database is initially created, a DBA will logon to the database as the user SYS or SYSTEM, and create a personal DBA account. </li></ul><ul><li>The DBA account will be granted all of the privileges needed to administer the database. </li></ul>USER ACCOUNTS AND PRIVILEGES
  26. 26. <ul><li>The DBA creates individual accounts for each system user. </li></ul><ul><li>A simple form of the CREATE USER command is shown here: </li></ul><ul><ul><ul><li>CREATE USER bock IDENTIFIED BY secret_password; </li></ul></ul></ul><ul><li>A DBA or other system administrator must have the CREATE USER system privilege in order to create a user account. </li></ul><ul><li>Even though bock now has an account, bock still cannot connect to the database until the DBA grants bock the CREATE SESSION system privilege. </li></ul>Creating, Altering, and Dropping User Accounts
  27. 27. <ul><li>The following SQL Example gives a more complete form of the CREATE USER command. </li></ul><ul><li>This CREATE USER command creates a user account and also allocates space for the storage of objects in various tablespaces. </li></ul><ul><li>This command will only execute if your database has the tablespaces named here. </li></ul><ul><ul><ul><ul><li>CREATE USER bock IDENTIFIED BY secret_password </li></ul></ul></ul></ul><ul><ul><ul><ul><li>DEFAULT TABLESPACE users </li></ul></ul></ul></ul><ul><ul><ul><ul><li>TEMPORARY TABLESPACE temp </li></ul></ul></ul></ul><ul><ul><ul><ul><li>QUOTA 10M ON users </li></ul></ul></ul></ul><ul><ul><ul><ul><li>QUOTA UNLIMITED ON temp </li></ul></ul></ul></ul><ul><ul><ul><ul><li>QUOTA 5M ON data </li></ul></ul></ul></ul><ul><ul><ul><ul><li>PASSWORD EXPIRE; </li></ul></ul></ul></ul>Creating, Altering, and Dropping User Accounts
  28. 28. <ul><li>Suppose that we suspect bock is doing something with the database that is unauthorized! We can stop bock from creating additional objects by altering the bock account. </li></ul><ul><li>The commands shown in the following SQL Example will alter bock's quota on the users and data tablespaces. </li></ul><ul><li>Existing objects bock has created will not be modified, but he will be unable to create new objects. </li></ul><ul><ul><ul><li>ALTER USER bock QUOTA 0 ON users; </li></ul></ul></ul><ul><ul><ul><li>ALTER USER bock QUOTA 0 ON data; </li></ul></ul></ul><ul><li>You can also use the ALTER USER command to allocate additional space and to restore quota allocations. </li></ul>Altering User Accounts
  29. 29. <ul><li>The DROP USER command will delete a user account. </li></ul><ul><li>It is necessary to use the CASCADE option if the user has created any objects. </li></ul><ul><ul><ul><li>DROP USER bock; </li></ul></ul></ul><ul><ul><ul><li>DROP USER bock CASCADE; </li></ul></ul></ul><ul><li>If you fail to specify CASCADE, then the DROP USER command will fail if the user has created objects. </li></ul><ul><li>We need to EXERCISE CAUTION while dropping user accounts! </li></ul><ul><li>What if bock is a system developer who has created some critical objects such as tables that our organization uses to store inventory and payroll information? </li></ul>Dropping User Accounts
  30. 30. <ul><li>If we drop bock with a CASCADE, the applications will fail because the tables and indexes that bock created will be destroyed. </li></ul><ul><li>A better alternative is to lock bock out of his account because his employment has terminated. </li></ul><ul><li>We can do this by revoking his privilege to connect to the system. </li></ul>Dropping User Accounts
  31. 31. <ul><li>The GRANT command in the following SQL Example will grant user bock the CREATE SESSION privilege need to logon to the SQL*PLUS or any of the Oracle’s tools. </li></ul><ul><ul><ul><li>GRANT PRIVILEGE create session TO bock; </li></ul></ul></ul><ul><li>There are many different privileges. </li></ul><ul><li>They are divided into two categories: system privileges and object privileges . </li></ul><ul><li>System privileges allow a system user to perform specific types of operations such as creating, dropping, and altering objects. </li></ul><ul><li>Object privileges allow a system user to perform a specific operation on a specific object such as a view, table, or index. </li></ul>Granting and Revoking Privileges
  32. 32. <ul><li>System privileges are also termed system-wide privileges, and include privileges that focus on managing objects that you own, and privileges that focus on managing objects that any system user may own. </li></ul><ul><li>Here are example system privileges: </li></ul><ul><ul><li>CREATE SESSION; ALTER SESSION </li></ul></ul><ul><ul><li>CREATE TABLE </li></ul></ul><ul><ul><li>CREATE ANY TABLE; ALTER ANY TABLE </li></ul></ul><ul><ul><li>CREATE ANY INDEX </li></ul></ul><ul><ul><li>UNLIMITED TABLESPACE </li></ul></ul>System Privileges
  33. 33. <ul><li>Basically, if you can create an object, you can also drop the object. </li></ul><ul><li>The CREATE TABLE privilege also includes the privilege to create indexes for a table and to subsequently drop those indexes as necessary. </li></ul><ul><li>Some example GRANT commands are shown here. </li></ul><ul><li>Note that the privileges being granted are separated by a comma as are the user account names: </li></ul><ul><ul><li>GRANT create session TO bock, bordoloi, user001; </li></ul></ul><ul><ul><li>GRANT create table, unlimited tablespace TO bock; </li></ul></ul><ul><ul><li>GRANT create table, create any table TO bock, bordoloi; </li></ul></ul>System Privileges
  34. 34. <ul><li>Once a DBA has created a user account, a system privilege may be granted to the user account with the WITH ADMIN OPTION. </li></ul><ul><li>In fact, this option may be used in any GRANT command that grants a system privilege. </li></ul><ul><li>The WITH ADMIN OPTION enables the grantee (the account receiving the privilege) to, in turn, grant the privilege to other user accounts. </li></ul><ul><li>Following SQL Example grants CREATE SESSION and CREATE TABLE to bock, and also gives bock the authority to grant these two privileges to other system user accounts. </li></ul><ul><ul><ul><li>GRANT create session, create table TO bock WITH ADMIN OPTION; </li></ul></ul></ul>System Privileges
  35. 35. <ul><li>Object privileges work on a specific object, so the form of the GRANT command is a bit different. The general form is: </li></ul><ul><ul><li>GRANT privilege1, privilege2, . . . </li></ul></ul><ul><ul><li>ON object_name TO user1, user2, . . . | public; </li></ul></ul><ul><li>For example, if bock has created a table named employee and wants to give the user named bordoloi the privilege to select rows from the table, the GRANT command in the following example enables bordoloi to select from the table. </li></ul><ul><ul><ul><li>GRANT select ON bock.employee TO bordoloi; </li></ul></ul></ul><ul><li>Suppose that bock also wants bordoloi to be able to insert rows into the employee table so as to relieve bock of some of the workload associated with loading new data. </li></ul><ul><li>The revised GRANT command in the following SQL Example includes the INSERT privilege. </li></ul><ul><ul><ul><li>GRANT select, insert ON bock.employee TO bordoloi; </li></ul></ul></ul>Object Privileges
  36. 36. <ul><li>System privileges may be revoked with the REVOKE command. </li></ul><ul><li>You can only revoke a privilege that was specifically granted previously with a GRANT command. </li></ul><ul><li>There are no cascading effects of revoking privileges. </li></ul><ul><li>This means that if DBA1 grants system privileges WITH ADMIN OPTION to DBA2, and then DBA1 subsequently changes jobs and is no longer authorized DBA privileges, all privileges granted to DBA1 can be revoked without worrying about privileges that DBA1 might have granted to DBA2 or to any system user account, for that matter. </li></ul><ul><li>Following SQL Example shows the revocation of the SELECT ANY TABLE privilege from the user account bordoloi . </li></ul><ul><ul><ul><li>REVOKE select any table FROM bordoloi; </li></ul></ul></ul>Revoking Privileges
  37. 37. <ul><li>Object privileges are revoked in a similar fashion, except that the object for which privileges are revoked must be named in the REVOKE command. </li></ul><ul><li>The keyword ALL can be used to revoke all privileges for an object from a user account. </li></ul><ul><ul><li>REVOKE select ON bock.employee FROM bordoloi; </li></ul></ul><ul><ul><li>REVOKE ALL ON bock.employee FROM bordoloi; </li></ul></ul>Revoking Privileges
  38. 38. <ul><li>The concept of a role is a simple one, and its purpose is to make it easier for a DBA to manage privileges. </li></ul><ul><li>A role is like a container of a group of privileges for a specific type of system user, such as an inventory manager. </li></ul><ul><li>Each time we hire an inventory manager, we would assign the manager a new system user account and authorize that account all of the privileges contained in the role called inventory_mgr .   </li></ul><ul><li>Further, we can simplify the management of privileges because we can allocate a role to another role! </li></ul>ROLES
  39. 39. ROLES <ul><li>The following figure depicts privileges being allocated to roles, and the roles being allocated to system users. </li></ul>
  40. 40. <ul><li>From studying the figure, it should be obvious that if you add a new system user who works as an Account Manager, then you can allocate almost all of the privileges this user will need by simply allocating the role named account_mgr to the system user. </li></ul><ul><li>Further, if it is determined that all account managers need an additional privilege, such as DELETE ON ORDERS, that privilege can be granted to the account_mgr role, and all of the system users who are granted the role named account_mgr will inherit the new privilege! This considerably simplifies user account management. </li></ul>ROLES
  41. 41. <ul><li>A role name must be unique within the database. </li></ul><ul><li>A role can be allocated both system and object privileges. </li></ul><ul><li>Roles are not owned by anyone so they do not appear in any user account schema. </li></ul><ul><li>You allocate privileges to roles the same way that you allocate them to a system user account; however, you must first create the role by using the CREATE ROLE command. </li></ul><ul><li>The following example commands create the role named inventory_mgr and grant several privileges to the role. </li></ul><ul><li>Next the role is allocated to the system user account for bordoloi . </li></ul><ul><li>The system user bock is granted the inventory_mgr role with the privilege to grant the role to other system users through the WITH ADMIN OPTION. </li></ul>ROLES
  42. 42. <ul><ul><ul><li>CREATE ROLE inventory_mgr; </li></ul></ul></ul><ul><ul><ul><li>GRANT select ON bock.employee TO inventory_mgr; </li></ul></ul></ul><ul><ul><ul><li>GRANT select, unlimited tablespace TO inventory_mgr; </li></ul></ul></ul><ul><ul><ul><li>GRANT inventory_mgr TO bordoloi; </li></ul></ul></ul><ul><ul><ul><li>GRANT inventory_mgr TO bock WITH ADMIN OPTION; </li></ul></ul></ul><ul><li>There are several predefined roles that are created as part of the task of creating a new database. </li></ul><ul><li>The CONNECT role is provided for backward compatibility with earlier versions of Oracle. </li></ul><ul><li>Anyone granted the DBA role will be granted all system privileges needed to function as a DBA and these privileges will include the WITH ADMIN OPTION. </li></ul>ROLES
  43. 43. <ul><li>When a role is dropped, Oracle revokes the role and all privileges granted through the role from all system users and from other roles. </li></ul><ul><li>If you wish to alter a role, the best approach is to create a new role with the desired privileges, grant that role to the system users/roles that possess the role to be dropped; then, you can drop the first role. </li></ul><ul><li>If you were granted a role with the ADMIN OPTION, then you can drop the role. </li></ul><ul><li>You may also drop a role if you have the DROP ANY ROLE system privilege. </li></ul><ul><li>The DROP ROLE command is very simple. </li></ul><ul><li>Following SQL Example shows the command used to drop the account_mgr role. </li></ul><ul><ul><ul><ul><ul><li>DROP ROLE account_mgr; </li></ul></ul></ul></ul></ul>ROLES
  44. 44. <ul><li>There are a number of data dictionary views that will interest you and further your understanding of database administration. </li></ul><ul><li>There is also a special set of views named dynamic performance views that are used to accumulate information and statistics about the performance of the database. </li></ul><ul><li>Each dynamic performance view begins with a prefix of v$ . </li></ul>DATA DICTIONARY TABLES AND VIEWS
  45. 45. <ul><li>v$fixed_table – lists all x$ tables that underline and store the dynamic performance information that can be displayed in v$ views. </li></ul><ul><li>v$session – lists information about the current sessions. You can use this information to &quot;kill&quot; a session if necessary where a session may be hung up or where the system user may no longer be authorized database access. </li></ul><ul><li>v$sysstat – this view gives information about system performance that is used by a DBA to perform database tuning. </li></ul><ul><li>v$sga – lists summary information about the system global area. </li></ul>Dynamic Performance Views
  46. 46. <ul><li>dba_tab_privs – lists all object privileges granted to a user. </li></ul><ul><li>dba_col_privs – lists all privileges granted on specific columns of a table. </li></ul><ul><li>session_privs – lists the privileges held by a user for the current logon session. </li></ul><ul><li>table_privileges – this lists information on object grants for which you are the grantor, grantee, or owner, or where PUBLIC is the grantee. </li></ul>Object Privilege Views
  47. 47. <ul><li>dba_roles – lists all roles in the database. </li></ul><ul><li>dba_role_privs – lists roles granted to system users and to other roles. </li></ul><ul><li>dba_sys_privs – lists system privileges granted to users and roles. </li></ul><ul><li>role_role_privs – lists roles granted to roles. </li></ul><ul><li>role_sys_privs – lists all system privileges granted to roles. </li></ul><ul><li>role_tab_privs – lists table privileges granted to roles. </li></ul>Role and Privilege Views
  48. 48. <ul><li>all_all_tables – lists information about all object tables and relational tables that you can access as a system user. </li></ul><ul><li>all_users – simply lists all users that are visible to you as a system user, but this view does not describe the users. </li></ul><ul><li>sys.dba_tablespaces – lists information about tablespaces that exist in the system. </li></ul><ul><li>sys.dba_data_files – lists information about data files including which tablespaces are allocated to which data files. </li></ul><ul><li>user_constraints – lists constraint definitions for tables in your schema. </li></ul><ul><li>user_indexes – lists information about your indexes for tables. </li></ul><ul><li>user_sequences – lists information about sequences you have created. </li></ul><ul><li>user_tables – lists information about your tables. </li></ul>Other Data Dictionary Views