Your SlideShare is downloading. ×

Database Administration

249

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
249
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Database Administration Alan Schneider
  • 2. Overview
    • Implementing a Relational Database
      • Instance
      • Tablespaces, Redo logs, Control Files
      • Object Owner (Schema)
      • Table and Views
      • Indexes
      • Public/Private Synonyms
      • Database Security
    • Concurrency Control / Locking
    • Database Recovery
    • Triggers
    • Stored Procedures/Functions
    • Application Security
  • 3. Implementing a Relational Database
    • Instance - Logical In Memory
    • Tablespaces (data files), Redo Logs, Control Files – Physical on disk drives
      • I/O Performance --The more physical disks and disk controllers there are, the better
      • Data Recovery -- Having your data spread over may disks, the easier it will be to recover data when failures occur
      • RDBMS Crashes -- Redo Log and control file redundancy over multiple disks ensures you can recover from a DB crash or disk failures.
  • 4. Implementing a Relational Database
    • Object Owner (Schema)
      • create user app_owner identified by app_owner;
        • normally you would also assign the users default user and temporary tablespace used when creating objects and when interacting with the data.  The assignment of the tablespace can also be done when creating the objects individually
  • 5. Implementing a Relational Database
    • Tables and Views
    Create table employee (  emp_id number primary key,  fname varchar2(30) NOT NULL,  lname varchar2(30) NOT NULL,  emp_mi varchar2(1),  emp_city varchar2(25),  emp_state varchar2(2),  emp_zip varchar2(9),  dept_no number references department(dept_no));
  • 6. Implementing a Relational Database
    • Indexes
      • Indexes allow rows to be quickly accessed when searching by sorting the data and reducing the number of database blocks that need to be read to find the data
        • For example when searching on a table the does not contain an index the entire table will need to be accessed.  This will require several database block reads if it is a very large table containing many records
        • However, if an index is used which only holds the indexed column and a pointer back to all of the data for that row, fewer database block will need to be read and results in the rows returning much faster
  • 7. Data Index Example
    • The ROW ID is maintained internally by the database and is NOT part of the table or index when created
    • create index last_name_ndx on employee(lname);
    12348 Yeager 12347 Smith 12346 Smith 12345 Jones ROWID lname 1 76309 CA Modesto V Mark Smith 12346 3 23873 FL Miami C Kathy Smith 12347 2 34823 AL Birmingham G Charles Yeager 12348 2 60601 IL Chicago A Jennifer Jones 12345 dept_no ip state city MI fname lname ROWID *
  • 8. Implementing a Relational Database
    • Synonyms
      • Private
        • Must be prefixed with schema name to be seen
      • Public
        • Do not need to prefix with schema name
          • Location Transparency
        • Can only be created by a Database Administrator
    • create public synonym department
    • for department;
  • 9. Implementing a Relational Database
    • Database Security
      • Limits certain actions on certain objects to certain users
        • User Type
          • Connect
          • Resource
          • Database Administrator
        • Roles/Groups and Privileges/Permissions
        • Users => Roles/Groups => privileges/Permissions on objects
  • 10. Implementing a Relational Database
    • Database Security
    • grant select, insert, update, delete
    • on department to app_user;
    • grant <custom_role> to app_user
    • grant execute on pkg_emp_mgmt to app_user;
  • 11. Concurrency Control / Locking
    • Concurrency control measures are take to ensure that one user's work does not inappropriately influence another user's work.
    • No concurrency control technique or mechanism is ideal for all circumstances. 
      • For example, a user can obtain very strict concurrency control by locking the entire database, but while he or she is processing, no other user will be able to do anything.
  • 12. Concurrency Control / Locking
    • Disallows changing a value if another user is already using the data
    • Implicit locks are issues by the database system or by the application
    • Explicit locks are placed by command
    • Lock Granularity refers to whether the lock is at the page, table or database level
    • Exclusive Lock locks access of any type. No other transaction can read or change the data
    • Shared Lock locks access from change, but not from read
    • Deadlock
  • 13. Concurrency Control / Locking
    • Optimistic Locking
      • Assumes that no conflicts will occur. 
      • Is accomplished after an attempt to change
      • Better for Internet applications
    • Pessimistic Locking
      • Assumes that that conflict will occur. 
      • Is accomplished before an attempt to change
      • Better for OLTP and maybe some Intranet Applications
    Always Until Released Pessimistic Sometimes Update Only Optimistic Success Rate Length of Lock
  • 14. Database Recovery
    • Reprocessing
      • Go back to a know good point and reprocess workload using the application
      • This may mean that the records are processed out of order
    • Recovery via Rollback/Roll forward
      • Data is stored in a Log to maintain a record of the changes
      • Roll forward:  Go back to know good point, and based on the logged changes since the save, reapply the changes based on the log files
      • Rollback:  Undo changes made by erroneous or partially processed transactions
      • &quot;Before Image&quot; holds the initial value of the column
      • &quot;After Image&quot; holds the changed value of the column
      • The &quot;Before Image&quot; logically goes away once a COMMIT is issued that writes the &quot;After Image&quot;  value to the physical database
  • 15. Triggers
    • A special type of stored procedure
      • Invoked when a special condition occurs, such as Before or After inserting, updating or deleting from a table
    • create or replace trigger check_inventory_trg After update of inv_quantity on store_inventory for each row when new.inv_quantity < 25
    • DECLARE
    • BEGIN
    •    Add code here ...
    • such as update the items_to_order table
    • END;
  • 16. Stored Procedures and Functions
    • Compilation of Query Language statements used to process complex operations.
    • Normally requires input of variables.
  • 17. Stored Procedures and Functions
    • create or replace procedure adjust_salary(p_emp_no IN integer
    •                 ,p_raise IN integer)
    • AS
    • BEGIN
    • update employee   Set salary = salary + (salary * (p_raise/l00)) where emp_raise_date < (sysdate - 18)   and emp_no = p_emp_no;
    • END;
    • Execution of program would only require the user to type the following
      • Exec adjust_salary (23, 3) ;
        • 23 = employee number 3 = the percentage of raise being applied
  • 18. Application Security
    • Controlled by the developer and based on Procedural business Rules. 
      • For example an employee is allowed to enter orders but they cannot approve orders for release to shipping.

×