A) Data types.

Each column value and constant in a SQL statement has a datatype, which is associated with a specific storage format, constraints, and a valid range of values. When you create a table, you must specify a datatype for each of its columns. Oracle provides the following categories of built-in datatypes: Character Datatypes Numeric Datatypes DATE Datatype LOB Datatypes RAW and LONG RAW Datatypes ROWID and UROWID Datatypes

B) MACRO. Create or re-create your own Analytic Services calculation macro as your chosen combination of existing calculation functions or macros. This statement registers the new macro with the Analytic Services custom-defined function and macro catalog. Minimum permission required: Application Manager to create a local (application-level) macro. Administrator to create a global (system-level) macro. C) Entity-Relationship Diagram An entity-relationship (ER) diagram is a specialized graphic that illustrates the relationships between entities in a database. ER diagrams often use symbols to represent three different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes. Person (Rectangle) --- Name (Circle) Lives in (Dimand) City (Rectangle) --- Population (Circle) Examples: Consider the example of a database that contains information on the residents of a city. The ER digram shown in the image above contains two entities -- people and cities. There is a single "Lives In" relationship. In our example, due to space constraints, there is only one attribute associated with each entity. People have names and cities have populations. In a real-world example, each one of these would likely have many different attributes. D) Cursor A screen cursor can point to the first row to be processed, then the next row, and so on. In the same way, an explicit cursor "points" to the current row in the active set. This allows your program to process the rows one at a time. E) Normalization Normalization is the process of efficiently organizing data in a database. There are two goals of the normalization process: eliminating redundant data (for example, storing the same data in more than one table) and ensuring data dependencies make sense (only storing related data in a table). Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored. There are several benefits for using Normalization in Database. Benefits : Eliminate data redundancy Improve performance Query optimization Faster update due to less number of columns in one table F) Two Phase Commit A feature of transaction processing systems that enables databases or other transacted resources to be returned to the pretransaction state if some error condition occurs. Sometimes abbreviated 2PC. Under 2PC, a single transaction can update many different databases or resources, and these resources may be distributed across networks, and have independent availability and failure modes. The two-phase commit strategy is designed to ensure that either all the resources are updated or none of them, so that the resources under transactional control remain synchronized. Resources that participate in 2PC agree to be managed by a transaction manager.

In the X/Open model, there are 3 parties: the application, the resource manager (RM), and the transaction manager (TM). An example of an RM might be a database (like Oracle, DB2, SQL Server) or a transactional message queue (like IBM MQSeries or Microsoft Message Queue). An example of an App is, the code that denotes the transaction operation. The TM is often invisible to the app, but plays the role of director when multiple distributed RMs participate in a transaction. The way it works: The app begins a transaction. The TM opens and maintains a context on behalf of the app. The app then contacts an RM and reads or writes within the context of that transaction. The app must communicate to the RM via a client library that is aware of the TM, and the RM itself must be aware of the TM context. The app can then contact other RMs similarly. When the app is finished, it can request a commit. The TM then contacts each RM that was involved in the transaction, and sends the "prepare" command. Essentially the TM is asking the RM, "the changes performed at your resource, on behalf of this transaction - can you make them permanent?" Each RM then must respond "commit" or "abort" . This is sometimes called the "vote". If the RM votes to commit, it implicitly assures the TM that no changes will be lost, even in the face of failure (like power failure, or network failure). This generally means the RM must store its changes to durable media, like a disk. If the TM gets a unanimous "commit" vote, then the TM sends "commit" messages to each RM. If any RM votes to abort, then the TM Sends an abort message to each RM. Each RM receives the direction of the TM, and then either rolls forward or back, and releases locks held on behalf of the transaction. If the network is interrupted and the RM never gets the message, the RM never resolves the transaction. In this case administrator intervention may be required.

1) Organize data in ORACLE Oracle offers the broadest and most integrated portfolio of products to help you acquire and organize these diverse data sources and analyze them alongside your existing data to find new insights and capitalize on hidden relationships. When building an Oracle data warehouse, it is important to properly organize all of the classification information about the facts in the warehouse. In a basic data warehouse, the goal is to capture information about some relevant fact. These facts are commonly kept according to a time dimension. Examples of commonly used facts for a warehouse include: The number of units sold each day. The average sale price per month. The number of widgets manufactured per day.

In addition to the basic facts and dates, the data warehouse will also collect information about attributes of the facts. It is these attributes that make the data warehouse function to provide end users with insights about patterns in the warehouse. A fact table is created with the basic fact and all keys relating to the classification of the fact. From this fact table, we see the basic fact is number_of_units_sold. In addition, we see keys to other information about the sale, namely the date, the key to the store where the sales were made, and the SKU (stock keeping unit) number of the items. By itself, the fact table does not provide much useful information about the sale. However, when combined with additional attributes, we can see a great deal of information about a sale. Handling attribute classification One of the foremost problems in a data warehouse is the creation and maintenance of the nonfact data attributes. A nonfact attribute is a table column that serves to describe the fact. In all cases, attributes will either be choose-one, finite value, or hierarchical. Let's discuss each of these data attributes and the design techniques you can use to implement them within a data warehouse. Choose-one attribute You implement a choose-one attribute in the case of mutually exclusive attributes, such as gender, level of education, category of income, and so on. In most cases, a flag column is used to represent these data attributes, and Oracle check constraints are used to enforce the valid values for the flag. The check constraint validates incoming columns at row insert

time. For example, rather than having an application verify that all occurrences of region are North, South, East, or West, you can add a check constraint to the table definition to ensure the validity of the region column. Finite value attributes Finite value attributes contain specific values that can't be categorized by range values. Examples include last_name, street_address, and phone_number. Hierarchical attributes Hierarchical attributes are the most challenging to represent in a data warehouse. Within a classification tree, each branch may have many levels, and once an entity has been classified, it should automatically participate in all other classes it participates in. 2) Data Definition Language The Data Definition Language (DDL) is used to create and destroy databases and database objects. These commands will primarily be used by database administrators during the setup and removal phases of a database project. Let's take a look at the structure and usage of four basic DDL commands: The Data Definition Language (DDL) is used to create and destroy databases and database objects. These commands will primarily be used by database administrators during the setup and removal phases of a database project. Let's take a look at the structure and usage of four basic DDL commands: Data Definition Language (DDL) statements are used to define the database structure or schema. Some examples: CREATE - to create objects in the database ALTER - alters the structure of the database DROP - delete objects from the database TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed COMMENT - add comments to the data dictionary RENAME - rename an object CREATE Installing a database management system (DBMS) on a computer allows you to create and manage many independent databases. For example, you may want to maintain a database of customer contacts for your sales department and a personnel database for your HR department. The CREATE command can be used to establish each of these databases on your platform. For example, the command: CREATE DATABASE employees creates an empty database named "employees" on your DBMS. After creating the database, your next step is to create tables that will contain data. (If this doesn't make sense, you might want to read the article Microsoft Access Fundamentals for an overview of tables and databases.) Another variant of the CREATE command can be used for this purpose. The command: CREATE TABLE personal_info (first_name char(20) not null, last_name char(20) not null, employee_id int not null) establishes a table titled "personal_info" in the current database. In our example, the table contains three attributes: first_name, last_name and employee_id. Don't worry about the other information included in the command -- we'll cover that in a future article. USE The USE command allows you to specify the database you wish to work with within your DBMS. For example, if we're currently working in the sales database and want to issue some commands that will affect the employees database, we would preface them with the following SQL command: USE employees It's important to always be conscious of the database you are working in before issuing SQL commands that manipulate data. ALTER Once you've created a table within a database, you may wish to modify the definition of it. The ALTER command allows you to make changes to the structure of a table without deleting and recreating it. Take a look at the following command: ALTER TABLE personal_info ADD salary money null

This example adds a new attribute to the personal_info table -- an employee's salary. The "money" argument specifies that an employee's salary will be stored using a dollars and cents format. Finally, the "null" keyword tells the database that it's OK for this field to contain no value for any given employee. DROP The final command of the Data Definition Language, DROP, allows us to remove entire database objects from our DBMS. For example, if we want to permanently remove the personal_info table that we created, we'd use the following command: DROP TABLE personal_info Similarly, the command below would be used to remove the entire employees database: DROP DATABASE employees Use this command with care! Remember that the DROP command removes entire data structures from your database. If you want to remove individual records, use the DELETE command of the Data Manipulation Language. That's the Data Definition Language in a nutshell. In the next section of this article, we'll take a look at how the Data Manipulation Language is used to manipulate the information contained within a database 3) Data Manipulation Language The Data Manipulation Language (DML) is used to retrieve, insert and modify database information. These commands will be used by all database users during the routine operation of the database. Let's take a brief look at the basic DML commands: The Data Manipulation Language (DML) is used to retrieve, insert and modify database information. These commands will be used by all database users during the routine operation of the database. Let's take a brief look at the basic DML commands: Data Manipulation Language (DML) statements are used for managing data within schema objects. Some examples: SELECT - retrieve data from the a database INSERT - insert data into a table UPDATE - updates existing data within a table DELETE - deletes all records from a table, the space for the records remain MERGE - UPSERT operation (insert or update) CALL - call a PL/SQL or Java subprogram EXPLAIN PLAN - explain access path to data LOCK TABLE - control concurrency INSERT The INSERT command in SQL is used to add records to an existing table. Returning to the personal_info example from the previous section, let's imagine that our HR department needs to add a new employee to their database. They could use a command similar to the one shown below: INSERT INTO personal_info values('bart','simpson',12345,$45000) Note that there are four values specified for the record. These correspond to the table attributes in the order they were defined: first_name, last_name, employee_id, and salary. SELECT The SELECT command is the most commonly used command in SQL. It allows database users to retrieve the specific information they desire from an operational database. Let's take a look at a few examples, again using the personal_info table from our employees database. The command shown below retrieves all of the information contained within the personal_info table. Note that the asterisk is used as a wildcard in SQL. This literally means "Select everything from the personal_info table." SELECT * FROM personal_info Alternatively, users may want to limit the attributes that are retrieved from the database. For example, the Human Resources department may require a list of the last names of all employees in the company. The following SQL command would retrieve only that information: SELECT last_name FROM personal_info

Finally, the WHERE clause can be used to limit the records that are retrieved to those that meet specified criteria. The CEO might be interested in reviewing the personnel records of all highly paid employees. The following command retrieves all of the data contained within personal_info for records that have a salary value greater than $50,000: SELECT * FROM personal_info WHERE salary > $50000 UPDATE The UPDATE command can be used to modify information contained within a table, either in bulk or individually. Each year, our company gives all employees a 3% cost-of-living increase in their salary. The following SQL command could be used to quickly apply this to all of the employees stored in the database: UPDATE personal_info SET salary = salary * 1.03 On the other hand, our new employee Bart Simpson has demonstrated performance above and beyond the call of duty. Management wishes to recognize his stellar accomplishments with a $5,000 raise. The WHERE clause could be used to single out Bart for this raise: UPDATE personal_info SET salary = salary + $5000 WHERE employee_id = 12345 DELETE Finally, let's take a look at the DELETE command. You'll find that the syntax of this command is similar to that of the other DML commands. Unfortunately, our latest corporate earnings report didn't quite meet expectations and poor Bart has been laid off. The DELETE command with a WHERE clause can be used to remove his record from the personal_info table: DELETE FROM personal_info WHERE employee_id = 12345 On the next page of this article, we'll begin exploring the power of JOINs. 4) Reports Oracle Reports is a tool for developing reports against data stored in an Oracle database. Oracle Reports consists of Oracle Reports Developer (a component of the Oracle Developer Suite) and Oracle Application Server Reports Services (a component of the Oracle Application Server). Oracle Reports Layout Components and Types of Layouts After defining Data model the reports layout must be specified. Several important concepts and properties apply to layout objects: 1. The frequency with which you want the object to appear in the report, specified by the Print Object On property 2. How Reports Builder fetches and formats data for instances of repeating frames, specified by the Column Mode property 3. Whether to keep an object and the object to which it is anchored on the same logical page, specified by the Keep with Anchoring Object property 4. Whether to try to keep the entire object and its contents on the same logical page, specified by the Page Protect property 5. Format triggers, which are PL/SQL functions executed before an object is formatted that can dynamically change the formatting attributes of objects 6. Report layout, generated by defaulting applied by Reports Builder, modified in the Paper Layout view, or created from scratch. The following are the Layout Components: Frames Frames surround other objects and protect them from being overwritten or pushed by other objects. For example, a frame might be used to surround all objects owned by a group, to surround column headings, or to surround summaries. When you default the layout for a report, Reports Builder creates frames around report objects as needed; you can also create a frame manually in the Paper Layout view.

Create frames when you want to: Group together objects to ensure they maintain their relative positions during printing. Delineate sections in your report. Protect other objects from being overwritten.

Example: You want the top of each page to have a tabular format, but the bottom of each page to have a matrix format. Example: A summary is centered under two repeating frames. Defaulting rules state that the summary must remain at a fixed distance from only the first object that can overwrite it; therefore, the summary is in danger of being overwritten by the second repeating frame. Enclosing both repeating frames with a frame will force the summary to maintain a fixed distance from both of them, and it will not be overwritten. Prevent an object from printing until other objects finish printing. Example: A summary is centered under two repeating frames. According to defaulting rules, the summary will print as soon as the first repeating frame finishes printing. Create a frame around the two repeating frames to ensure the summary prints after both repeating frames have finished printing. Repeating Frames Repeating frames surround all of the fields that are created for a group's columns. The repeating frame prints (is fired) once for each record of the group. When you default the layout for a report, Reports Builder generates one repeating frame for each group in the data model, and places one field inside it for each of the group's columns. Repeating frames can enclose any layout object, including other repeating frames. Nested repeating frames are typically used to produce master/detail and break reports. For each record of the outer repeating frame, Reports Builder will format all related records of the enclosed repeating frame. Fields Fields are placeholders for parameters, columns, and such values as the page number, current date, and so on. If a parameter or column does not have an associated field, its values will not appear in the report output. A field is owned by the object surrounding it, which is the first enclosing object (either a frame or repeating frame). When you default the layout for a report, Reports Builder generates one field for each column, and places each field inside of a repeating frame. You can also create a field manually in the Paper Design view, Paper Layout view or Paper Parameter Form view. Boilerplate A boilerplate object is any text, lines, or graphics that appear in a report every time it is run. Reports Builder creates one boilerplate object for each label selected in the Report Wizard (it is named B_columnname). For example, if a column is named ENAME, a boilerplate object containing ENAME is generated for the column. For some report types, Reports Builder also generates lines under the labels. Different Page Selection in Report Layout Report sectioning enables you to define multiple layouts in the same report, each with a different target audience, output format, page layout, page size, or orientation. we can define up to three report sections, each with a body area and a margin area: the names of the sections are : Header, Main, and Trailer. Trailer Section Creating a header page or trailer page object With report sectioning, Header and Trailer pages are identical to Body pages. In effect, this means that the Header, Trailer, and Body are three sections of a report. The names of the sections are exposed under the Paper Design node in the Object Navigator as Header Section, Main Section, and Trailer Section. You can use the margin and body of the Header and Trailer sections to create a Header and Trailer "page" as in earlier releases of Oracle Reports. 5) BCNF Normal form BoyceCodd normal form (or BCNF or 3.5NF) is a normal form used in database normalization. It is a slightly stronger version of the third normal form (3NF). BCNF was developed in 1974 by Raymond F. Boyce and Edgar F. Codd to address certain types of anomaly not dealt with by 3NF as originally defined.

Chris Date has pointed out that a definition of what we now know as BCNF appeared in a paper by Ian Heath in 1971. Date writes: "Since that definition predated Boyce and Codd's own definition by some three years, it seems to me that BCNF ought by rights to be called Heath normal form. But it isn't." If a relational scheme is in BCNF then all redundancy based on functional dependency has been removed, although other types of redundancy may still exist. A relational schema R is in BoyceCodd normal form if and only if for every one of its dependencies X Y, at least one of the following conditions holds: In some cases, a non-BCNF table cannot be decomposed into tables that satisfy BCNF and preserve the dependencies that held in the original table. Beeri and Bernstein showed in 1979 that, for example, a set of functional dependencies {AB C, C B} cannot be represented by a BCNF schema.[6] Thus, unlike the first three normal forms, BCNF is not always achievable. Consider the following non-BCNF table whose functional dependencies follow the {AB C, C B} pattern: Nearest Shops Person Shop Type Nearest Shop Eagle Eye Merlin Books Doughy's Eagle Eye Davidson Optician Wright Fuller Fuller Fuller Bookshop Bakery Optician

Davidson Hairdresser Snippets

Hairdresser Sweeney Todd's

For each Person / Shop Type combination, the table tells us which shop of this type is geographically nearest to the person's home. We assume for simplicity that a single shop cannot be of more than one type. The candidate keys of the table are: {Person, Shop Type} {Person, Nearest Shop}

Because all three attributes are prime attributes (i.e. belong to candidate keys), the table is in 3NF. The table is not in BCNF, however, as the Shop Type attribute is functionally dependent on a non-superkey: Nearest Shop. The violation of BCNF means that the table is subject to anomalies. For example, Eagle Eye might have its Shop Type changed to "Optometrist" on its "Fuller" record while retaining the Shop Type "Optician" on its "Davidson" record. This would imply contradictory answers to the question: "What is Eagle Eye's Shop Type?" Holding each shop's Shop Type only once would seem preferable, as doing so would prevent such anomalies from occurring: Shop Near Person Person Shop Davidson Eagle Eye Davidson Snippets Wright Fuller Fuller Fuller Shop Shop Eagle Eye Snippets Merlin Books Shop Type Optician Hairdresser Bookshop Merlin Books Doughy's Sweeney Todd's Eagle Eye

Doughy's

Bakery

Sweeney Todd's Hairdresser In this revised design, the "Shop Near Person" table has a candidate key of {Person, Shop}, and the "Shop" table has a candidate key of {Shop}. Unfortunately, although this design adheres to BCNF, it is unacceptable on different grounds: it allows us to record multiple shops of the same type against the same person. In other words, its candidate keys do not guarantee that the functional dependency {Person, Shop Type} {Shop} will be respected. A design that eliminates all of these anomalies (but does not conform to BCNF) is possible. [7] This design consists of the original "Nearest Shops" table supplemented by the "Shop" table described above. Nearest Shops Person Shop Type Nearest Shop Eagle Eye Merlin Books Doughy's Eagle Eye Davidson Optician Wright Fuller Fuller Fuller Bookshop Bakery Optician

Davidson Hairdresser Snippets

Hairdresser Sweeney Todd's

If a referential integrity constraint is defined to the effect that {Shop Type, Nearest Shop} from the first table must refer to a {Shop Type, Shop} from the second table, then the data anomalies described previously are prevented. 6) Trigger Command A trigger is a pl/sql block structure which is fired when a DML statements like Insert, Delete, Update is executed on a database table. A trigger is triggered automatically when an associated DML statement is executed. Syntax of Triggers The Syntax for creating a trigger is: CREATE [OR REPLACE ] TRIGGER trigger_name {BEFORE | AFTER | INSTEAD OF } {INSERT [OR] | UPDATE [OR] | DELETE} [OF col_name] ON table_name [REFERENCING OLD AS o NEW AS n] [FOR EACH ROW] WHEN (condition) BEGIN --- sql statements END;

CREATE [OR REPLACE ] TRIGGER trigger_name - This clause creates a trigger with the given name or overwrites an existing trigger with the same name. {BEFORE | AFTER | INSTEAD OF } - This clause indicates at what time should the trigger get fired. i.e for example: before or after updating a table. INSTEAD OF is used to create a trigger on a view. before and after cannot be used to create a trigger on a view. {INSERT [OR] | UPDATE [OR] | DELETE} - This clause determines the triggering event. More than one triggering events can be used together separated by OR keyword. The trigger gets fired at all the specified triggering event. [OF col_name] - This clause is used with update triggers. This clause is used when you want to trigger an event only when a specific column is updated. CREATE [OR REPLACE ] TRIGGER trigger_name - This clause creates a trigger with the given name or overwrites an existing trigger with the same name. [ON table_name] - This clause identifies the name of the table or view to which the trigger is associated. [REFERENCING OLD AS o NEW AS n] - This clause is used to reference the old and new values of the data being changed. By default, you reference the values as :old.column_name or :new.column_name. The reference names can also be changed from old (or new) to any other user-defined name. You cannot reference old values when inserting a record, or new values when deleting a record, because they do not exist. [FOR EACH ROW] - This clause is used to determine whether a trigger must fire when each row gets affected ( i.e. a Row Level Trigger) or just once when the entire sql statement is executed(i.e.statement level Trigger). WHEN (condition) - This clause is valid only for row level triggers. The trigger is fired only for rows that satisfy the condition specified.

For Example: The price of a product changes constantly. It is important to maintain the history of the prices of the products. We can create a trigger to update the 'product_price_history' table when the price of the product is updated in the 'product' table. 1) Create the 'product' table and 'product_price_history' table CREATE TABLE product_price_history (product_id number(5), product_name varchar2(32), supplier_name varchar2(32), unit_price number(7,2) ); CREATE TABLE product (product_id number(5), product_name varchar2(32), supplier_name varchar2(32), unit_price number(7,2) ); 2) Create the price_history_trigger and execute it. CREATE or REPLACE TRIGGER price_history_trigger BEFORE UPDATE OF unit_price ON product FOR EACH ROW BEGIN INSERT INTO product_price_history VALUES

(:old.product_id, :old.product_name, :old.supplier_name, :old.unit_price); END; / 3) Lets update the price of a product. UPDATE PRODUCT SET unit_price = 800 WHERE product_id = 100 Once the above update query is executed, the trigger fires and updates the 'product_price_history' table.S 7) Managerial applications of RDBMS Product Lifecycle Management Customer Relationship Management Enterprise Performance Management Strategy Management Solutions Business Intelligence System Enterprise Asset Management Enterprise Content Management ERM (Enterprise Risk Management) Profitability Management System Financial Management System Fraud Management System Portal System Integration Solutions Governance, Risk, and Compliance Management Human Capital Management IT Service Management Master Data Management Supply Chain Management

Product Lifecycle Management Oracle's complete Agile PLM solutions help companies solve one of today's most complex challenges: how to innovate profitably. As product needs grow increasingly complex on a global scale, old methods of collaboration like manual or point systems - even email - are growing obsolete. Business leaders aiming to optimize all aspects of designing, developing, launching, servicing, and disposing of products in an integrated, best-in-class model are choosing to partner with Oracle to leverage our deep expertise, broad portfolio, and strong community commitment. Oracle's Agile PLM is the industry's most comprehensive enterprise PLM solution, and a key building block required to manage product value chains. Customer Relationship Management The world's most complete customer relationship management (CRM). Oracle offers the broadest and deepest portfolio of CRM solutions that address all customer touch-points and provide rich functionality to support the specific business needs for organizations of every size to deliver a superior customer experience. Enterprise Performance Management Plan and forecast with greater precision using Oracle's business planning solutions that align finance and operations. Accelerate your financial close and reporting process while providing greater transparency and confidence in your numbers. Oracle's EPM applications support strategic planning and goal setting, financial and operational planning, the end-to-end financial close and reporting process, and profitability management in a comprehensive and fully integrated suite. Strategy Management Solutions Creating value, whether in stakeholder returns or public sector services, is best achieved when strategic intent flows uninterrupted from the senior management to all employees. Oracle's Strategy Management solutions enable this flow by helping senior management to develop realistic strategic plans, define a methodology-based strategy, measure performance against goals and monitor progress on a regular basis, and then communicate this information across their entire enterprise. Business Intelligence

Business Intelligence (BI) solutions are based on the process of multi-aspect information retrieval, using special technologies, methods, and automation tools. They help to make decisions supported by thorough and objective analysis of business areas and provide responsible individuals with reliable reports, both on current conditions and existing and future opportunities. Enterprise Asset Management Enterprise Asset Management (EAM) System is a comprehensive solution that allows reducing expenses on equipment maintenance and repairs, logistics and procurement while ensuring compliance with the required level of resilience. Enterprise Content Management Enterprise Content Management (ECM) systems transform the entire company document workflow into electronic form, which allows for a significant reduction of expenses and time required for the creation and signing of documents. ERM (Enterprise Risk Management) ERM (Enterprise Risk Management) is an integrated system for risk management. Today, assessment of the number and quality of risks and their management is important for companies to increase share prices and competitive ability in the long term. 8) Developing a Database Security Plan Data is any company's greatest asset and the only "safe" database is one that has nothing in it. A lot of people think that hackers are all outside the firewall which is false. The greatest threat to your database is the person in the cube next to you who has access to it. For this reason databases should be secured to ensure its data is properly protected. There are many steps to securing your system and its data. But one of the first--and one that too few organizations take--is the development of a security policy that outlines and maps out the enforcement of a security plan. We've included this chapter as the first one in the "Implementing Security" part of this book because we believe that the creation of security policies and the implementation of a security plan must precede the more operational steps of securing your system and database. About the Security Policy and Security Plan Why does a company need a security policy and plan? What's the point of having them? A security policy, included within a security plan, helps to ensure that everyone is in sync with the company's needs and requirements. With a firm policy in place, every employee knows what is expected -- what the rules are--and how the requirements are to be implemented. The limits are clearly defined and consistent guidance is provided for everyone. Statements within a security plan can help to ensure that each employee knows the boundaries and what the penalties of overstepping those boundaries will be. For example, here are clear, concise rules employees can easily understand and follow: Always log off the system before going to lunch. Never share a password with anyone else. Never bring software from home to put on your machine at work.

In order to have a truly solid and meaningful policy defined, the highest level of management needs to be committed to ensuring that the security policy will be enforceable. The security policy might state: Any employee leaving a computer unsecured will be formally reprimanded. Any employee found sharing a password will be suspended for one day. Unlicensed software found on a personal computer will be removed and the personal computer user will be shot at sunrise. Survivors will be prosecuted.

Under certain circumstances, the requirement to have and enforce a security policy may come from an agency outside the company. In the case of banks, external agencies control and define what constitutes security for the databases within the bank. The company, however, might decide that even more rigid standards are necessary or that further definitions are required to ensure that no financial transactions become compromised and that confidentiality is maintained. The bank may implement a security plan that further defines exactly how the standards will be implemented, maintained, and audited. Management Considerations Once you've determined that a security plan is required for a company, a person or team of people will be needed to begin to define the policy. This chapter assumes a team of people. Who's on the team? Members of the team might include the person or people who will be administering the system, one or more application owners, and at least one management person who is high enough in the corporate structure to ensure that the policy--as written--will be enforceable. Establishing overall requirements

After the team is assembled, you'll first need to identify the overall requirements of the organization in regard to system and database security. The requirements might include (but are not limited to) the following: A uniform approach to security across computer systems and databases Identification of the form and style of authorization required to initiate the creation of an account A determination of who will create user accounts on the operating system, within each application if necessary, and within the databases How those accounts will be created Whether a standard convention for usernames and passwords should be imposed and what it should be Whether password aging will be enabled and in what time frame A determination of access requirements on an application-by-application basis Identification of how users will be tracked to ensure that as an employee's job description or location changes, the access to applications remains correct Identification of sensitive information and an outline of steps to take for data protection A determination of penalties to be enforced as a result of different levels of security breaches

Identifying Key Components We recommend that you use a spreadsheet approach to identify the components within your company that the security plan must encompass--for example: Each division within the corporation to be included in the policy Each platform within the division Each database housed on each platform along with its function (development, test, pre-production, or production) Each application supported within each database The "owner" of the application, or person responsible for authorization of users within the application Required security controls for each application, such as roles or grants required Username and password composition Type(s) of accessibility (Telnet, client server, external identification) What form of authorization will be accepted for that application (electronic authorization, verbal, email, hard-copy form, World Wide Web) Person authorized to create accounts for each application Forms of backup to be implemented Recovery procedures to be used Database availability Type of auditing required Who will perform the auditing How auditing will be performed

Types of Accounts From the earliest releases of the Oracle database, a mechanism has been provided to let users connect to the database in order to perform tasks via user accounts. There are several different types of Oracle user accounts--both operating system and database--that a company might implement: Although they are created with the CREATE USER command, some accounts are used to house application schemas. These accounts own objects like tables, views, indexes, triggers, procedures, etc. Another type of account is used by Oracle itself to enable the database engine work to be performed; these accounts are sys and system. In later versions of the RDBMS, an account to enable the intelligent agent to connect to each database is automatically created during database creation. This account is dbsnmp and carries full DBA privileges. Each application might need one or more accounts to enable work to be performed. Each user in your system may require an individual Oracle account with specific privileges to enable the user to work with an application. One or more accounts may be needed to enable one or more DBAs to perform database maintenance and duties.

Each account type must be considered and a decision reached on whether that account type will be used and how it will be set up and administered. In smaller organizations, there may be little need for some types of accounts discussed in this section. In very large organizations, there may be a need for more extensive divisions of database account types. Administrator Accounts The most obvious account type is the one used for database administration. A small company might have one person acting as system administrator, database administrator, and network administrator, while a larger company might have several people acting as administrators for specific areas. At your site, who will have access to the code area for installation and maintenance of the Oracle software? There may be one or more accounts that will need to be established for various administrative tasks as well as privilege sets--both operating system and database privileges--to perform the required tasks. Security Manager Who will serve as the security manager at your site? This person will be responsible for creating user accounts and monitoring user access and database security. In smaller organizations, the DBA will probably handle these tasks. Application Manager For each application, there will be developer accounts, application user accounts, and, possibly, application coordinator accounts. An application developer will need the ability to create objects and to code triggers, procedures, etc., while an application user might need only CREATE SESSION access. In larger companies, people are sometimes designated as "application coordinators." Their job is often to handle the administrative tasks for the specific database in which their

application is housed. They may need all of the rights and privileges of a DBA--both at the operating system level and at the database level. Network Manager There may be a need for a network manager whose job is to administer the network products and oversee Names Servers and network configurations for Oracle databases. Will a separate person or people be needed for this task at your site? Again, in a small company, the individual DBA may be responsible for all Oracle database networking tasks. Application Schema (User) Accounts Oracle's mechanism for creating schemas in which application objects are stored is to actually create a form of "user" account, generally referred to as a "schema," which will probably require more privileges than a general user account. The security policy might state what specific system privileges an application account may or may not be permitted to have. In an Oracle version 8.0.3 database, there are 89 distinct system privileges available; these privileges are listed in Chapter 5, Oracle Default Roles and User Accounts. Few, if any, applications have a need to hold all 89 privileges. A security plan might list the privileges that are never to be given to any application. Almost all of the privileges that grant ANY should be carefully examined and evaluated for listing in the security plan. Here are a few very good examples of privileges that should never be granted to an application (without a really strong business case): ALTER/CREATE/DROP ANY INDEX/PROCEDURE /TABLE /TRIGGER, etc. BECOME USER GRANT ANY PRIVILEGE /ROLE EXECUTE ANY PROCEDURE UNLIMITED TABLESPACE Possible Account Requests The policy team or higher-level management must decide whether access to the database can be granted through an electronic request, or whether some level of management must physically sign a form acknowledging that the employee seeking entry into the system is a valid employee with a proven need to interact with a specific application area. The authorization required might even be as casual as a user picking up a telephone or walking into a designated person's office and saying, "I need access to xyz system" and receiving an account on that system. Thus, we see that account requests might be generated through a number of different venues (or a combination of several of the approaches listed here): Electronic requests via a web site or email Telephone Hardcopy form--with or without a signature of authorization Personal interaction with a verbal request Personal interaction with a hardcopy form

Contents of the Form If a physical record must be made available for future auditing of the system, you need to create a form for that purpose. The security plan would include a copy of the form. A form might include the following information: The requester's full name Physical location Telephone number Employee number Username and initial password Access required Platform to access Database to access Type of work to be performed Signature of person authorized to approve the request Date by which the account is needed

9) Performance Tuning Performance Planning Instance Tuning SQL Tuning Performance Planning Before you start on the instance or SQL tuning sections of this guide, make sure you have read Part II, "Performance Planning". Based on years of designing and performance experience, Oracle has designed a performance methodology. This brief section explains clear and simple activities that can dramatically improve system performance. It discusses the following topics: Investment Options Scalability System Architecture Application Design Principles Workload Testing, Modeling, and Implementation Deploying New Applications Instance Tuning Part III, "Optimizing Instance Performance" of this guide discusses the factors involved with the tuning and optimizing of an Oracle database instance. When considering instance tuning, care must be taken in the initial design of the database system to avoid bottlenecks that could lead to performance problems. In addition, you need to consider: Allocating memory to database structures Determining I/O requirements of different parts of the database Tuning the operating system for optimal performance of the database After the database instance has been installed and configured, you need to monitor the database as it is running to check for performance-related problems. Performance Principles Performance tuning requires a different, although related, method to the initial configuration of a system. Configuring a system involves allocating resources in an ordered manner so that the initial system configuration is functional. Tuning is driven by identifying the most significant bottleneck and making the appropriate changes to reduce or eliminate the effect of that bottleneck. Usually, tuning is performed reactively, either while the system is preproduction or after it is live. Baselines The most effective way to tune is to have an established performance baseline that can be used for comparison if a performance issue arises. Most database administrators (DBAs) know their system well and can easily identify peak usage periods. For example, the peak periods could be between 10.00am and 12.00pm and also between 1.30pm and 3.00pm. This could include a batch window of 12.00am midnight to 6am. It is important to identify these high-load times at the site and install a monitoring tool that gathers performance data for those times. Optimally, data gathering should be configured from when the application is in its initial trial phase during the QA cycle. Otherwise, this should be configured when the system is first in production. Ideally, baseline data gathered should include the following: Application statistics (transaction volumes, response time) Database statistics Operating system statistics Disk I/O statistics Network statistics In the Automatic Workload Repository, baselines are identified by a range of snapshots that are preserved for future comparisons. See "Automatic Workload Repository". Introduction to Performance Tuning Features and Tools Effective data collection and analysis is essential for identifying and correcting performance problems. Oracle provides a number of tools that allow a performance engineer to gather information regarding database performance. In addition to gathering data, Oracle provides tools to monitor performance, diagnose problems, and tune applications. The Oracle gathering and monitoring features are mainly automatic, managed by an Oracle background processes. To enable automatic statistics collection and automatic performance features, the STATISTICS_LEVEL initialization parameter must be set to TYPICAL or ALL. You can administer and display the output of the gathering and tuning tools with Oracle Enterprise Manager or with APIs and views. Oracle Enterprise Manager Database Control is recommended for ease of use.

10) Oracle Spread Sheet OracleBI Spreadsheet Add-In enables end users to display and navigate Oracle OLAP data from within Excel. Users can treat the Oracle OLAP data as regular Excel data. For example, they can create formulas and graphs, which enables them to combine the powerful analytic capabilities of Oracle OLAP with standard Excel functionality. Using a wizard-driven interface, users can select data from Oracle OLAP simply by choosing from a list of values or by creating advanced selections, such as those based on exceptions, top/bottom analysis, or hierarchies. In addition, users can create Oracle OLAPbased calculations using a wizard. The built-in Query Wizard and Calculation Wizard are similar to the wizards used in other OracleBI products, such as Discoverer, thus ensuring a consistent interface. Easy-to-use front end in which users create queries using business terms. User interface that is shared with other Oracle Business Intelligence products. User access to the latest data and to a shared data model. Scalability because queries run in the Oracle database. Oracle Express Spreadsheet Add-In is an add-in to Microsoft Excel. The add-in allows you to fetch data from one or more Express databases and work with the data in a familiar spreadsheet environment. Retrieving data from Express databases You can use the add-in to retrieve data from the following types of Express databases: Local databases that are accessed using Personal Express release 6.x Remote databases that are accessed using Oracle Express Server (hereinafter referred to as "Express Server") release 6.x Databases that are configured to accept data from a relational database management system (RDBMS) using Oracle Express Relational Access Manager Basic features Using the add-in with Excel, you can: Query one or more Express databases and import the data directly into a spreadsheet using an intuitive wizard. Perform powerful OLAP analysis operations on the data, such as drilling, rotation, and data selection, without leaving the spreadsheet. Format the data using familiar spreadsheet tools. Use drill icons and indentation to work easily with hierarchical data in the spreadsheet. Specify the default presentation of data values that are not available. The add-in represents those values with the value NA by default, but you can specify an alternative default value. Remove rows or columns of data from query results to create an "asymmetric" layout for your data. This is useful if you want to pare down the results of your query to display only the necessary information. Create multiple queries across multiple spreadsheet files during one session. Write data back to the database (provided that you have the appropriate database privileges). Use the right mouse button to display a popup menu that contains options for performing various functions on a query. Display as many as 8 dimensions on the page edge. Use the add-in's API to create scripting hooks (for example, VBA within Microsoft Excel) that enable the spreadsheet power-user to manipulate Express data programmatically. Basic Steps for Working with Queries Two-phase process Express Spreadsheet Add-In allows you to display queries of data from one or more Express databases in a spreadsheet environment. Before working with queries, you should understand the basic steps in the process for using the add-in. This process has two phases: an installation phase and a querying phase. Procedure: Querying Express data Once you have installed the appropriate components, you can begin querying Express data in the spreadsheet. The following procedure describes how to query Express data with the add-in. 1. Start Excel. Result: The add-in should load automatically. You should see an Express menu in the menu bar. 2. From the Express menu, choose Run Express Wizard and create a query. 3. Use the options on the Express menu to affect the data in the query. For example, you can rotate and drill in the data, display the Selector, or work with custom measures. 4. If you have the proper access, then write changes to the database. 5. From the File menu, choose Save to save the query.