Bu acctg databases

  • 58 views
Uploaded on

Addresses the subject of Backing up an accounting database

Addresses the subject of Backing up an accounting database

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
58
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
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
  • An obvious question is – “Why do we need to address Accounting Databases specifically?” In my experience this is a much neglected area – I have even been answered, to my concern regarding backups – “It’s OK, we have paper printouts.” An accounting system is basically an ‘Off-the-shelf’ product which the users do not know much about and do not have access to the back-end programs or data. Typically accountants leave it to the IT department (often the IT department has no DBA) not even considering whether the IT department has the internal expertise to restore the database. This is especially true regarding a ‘Point-in-time’ restore. Most network administrators have never performed a PIT restoration. Ostrich management? The bottom line is - Accountants should be involved with their backups and not bury there heads in the sand! There needs to be documented procedures in place and there needs to regular routines that perform restores to test those procedures. Backups may be worthless unless they have been tested and you will not know their worth until you need them. To think outside the usual box, there can be some operational benefits to be gained from the use of backups. For example, we can create copies of our database for taking the load off our OLTP system or use them as the foundation for analysis reporting. We can also use them as Decision Support Systems (DSS) from which we can run those huge reports, we can use restored backups as test or development databases and gain other benefits as well. Some of the techniques discussed here are for use with large systems but smaller companies need to consider the advantages to be gained and learn how they can use some very simple routines to gain the benefits usually only available only to larger companies.
  • DSS (Decision Support System) = a restored backup of the Production OLTP (Online Transaction Processing) database. An Example: If you backup and restore every night then you have a database that you can index extensively without affecting the OLTP database. An advantage is that all reports run against that database will be consistent as of End of Business yesterday. Test Companies can be used for training new staff, testing bulk uploads of data, ‘what-if’ scenarios, testing if the backup restores OK, etc. Development companies may be created from backups and used by developers who need a true example of the database for developing programs and add-ons. Scoreboards are used to hold aggregate totals and denormalized data for easy reference and performance. Lookups and Read-only databases can be comprised of many adaptations so that the production database does not have to carry the load. Examples: Photos of employees could be carried in a separate database. Price lists can be kept separate (Note: the permutations are endless – they may, or may not, be based on backed up databases).
  • DSS (Decision Support System) = a restored backup of the Production OLTP (Online Transaction Processing) database. An Example: If you backup and restore every night then you have a database that you can index extensively without affecting the OLTP database. An advantage is that all reports run against that database will be consistent as of End of Business yesterday. Test Companies can be used for training new staff, testing bulk uploads of data, ‘what-if’ scenarios, testing if the backup restores OK, etc. Development companies may be created from backups and used by developers who need a true example of the database for developing programs and add-ons. Scoreboards are used to hold aggregate totals and denormalized data for easy reference and performance. Lookups and Read-only databases can be comprised of many adaptations so that the production database does not have to carry the load. Examples: Photos of employees could be carried in a separate database. Price lists can be kept separate (Note: the permutations are endless – they may, or may not, be based on backed up databases).
  • This is a development from the previous slide – it shows tempdb (which is important for tuning performance) and the log file which needs to be on a separate drive.
  • As part of the overall Disaster Recovery Plan , overall responsibility lies with the Board of Directors (as with everything else). The Board is responsible to the Shareholders for the continued operations of the company. Typically: The Officers follow the directions of the Board. The Managers implement the instructions of the Officers. Policies are approved at the Officer and then the Board level. Procedures are prepared by the managers for approval by the Officers.
  • 1. Disaster recovery Plans are common sense 2. SOX compliance requires BU & Restore procedures to be in place A question I have for you is – “Is there anyone here who either thinks that backups are unnecessary or that if they are done that they do not have to be done properly?” COBIT standards can be downloaded free from www.isaca.org. COBIT (Control Objectives for Information and Related Technology) was developed by the IT Governance Institute (ITGI) SOX adaptation 2003 – IT Control Objectives for Sarbanes Oxley - detailed 27 IT processes and 136 control objectives that are critical to SOX compliance. Research in 2003 by The Meta Group found that 39% of firms said SOX will eventually make them more competitive. COBIT requires adequate backup and restore procedures and they should be regular, tested and written/recorded. While there is quite a lot of feeling that SOX has gone too far there has not been anyone that says that it was/is completely unnecessary or that it is without any merit.
  • Since 9/11/2001 no one has said “It will never happen to us!” Prudence dictates that we do not leave the fate of the Company to chance - that we establish internal procedures that safeguard the continuity of the company should any of the risk areas become manifest. A complete Backup and restore plan should include the situation where a plane flies into the building (or something equally horrifying) and the company has to get up and running within a certain time, for example, 48 hours. Seriously and practically, and without the theatrics, - most errors are user errors and it should be a routine exercise to restore the database from a disk backup within the hour. This should be a procedure which is tested regularly.
  • Management decisions are often based on a Cost vs. Benefit analysis. If the costs outweigh the benefits we may feel that we should not perform the function. However, there are some results for which we cannot ‘take the chance.’ An often used formula is EMV = %Probability x $Loss – or stated another way - Expected Monetary Value can be defined as Probability times Economic Result. Example: 1% probability of a $1million loss = $10,000. This is sometimes recommended as the amount of money you should spend to avoid the risk and plays a part in the calculation of the basis an Insurance Company uses when setting premiums.
  • ISACA may be thought of as the International flavor of SOX with 50,000 members (worldwide). In Orange County there are approx 500 members. SOX needs no introduction - but I would like to say that a system of Internal Control is just common sense. CISA – Certified Information Systems Auditor. CISM - Certified Information Systems Manager. At present, both CISM and CISA are in high demand. The CITP is a fairly recent extension to AICPA membership for CPA’s specializing in IT and allows the use of CITP in conjunction with the CPA designation as CPA.CITP.
  • DSS (Decision Support System) = a restored backup of the Production OLTP (Online Transaction Processing) database. An Example: If you backup and restore every night then you have a database that you can index extensively without affecting the OLTP database. An advantage is that all reports run against that database will be consistent as of End of Business yesterday. Test Companies can be used for training new staff, testing bulk uploads of data, ‘what-if’ scenarios, testing if the backup restores OK, etc. Development companies may be created from backups and used by developers who need a true example of the database for developing programs and add-ons. Scoreboards are used to hold aggregate totals and denormalized data for easy reference and performance. Lookups and Read-only databases can be comprised of many adaptations so that the production database does not have to carry the load. Examples: Photos of employees could be carried in a separate database. Price lists can be kept separate (Note: the permutations are endless – they may, or may not, be based on backed up databases).
  • Nothing makes sense like backing up to a Hard Drive. It is faster, more reliable and more readily available in case of the need to restore. There has been a period when the predominant opinion was to backup to tape – maybe before hard drives became larger and cheaper. When you need to restore it makes perfect sense to restore from a hard drive copy of the backup.
  • Why don’t companies lose data? One reason is that they do not put the data on the same drive as the operating system. The C: drive is the most vulnerable to corruption, virus attack and is heavily used. I recommend = get 2 drives: Use 1 for the operating system and programs Use the other for data Put your paging file on the second disk (it usually gets used less and will increase performance) Note: Partitions MAY have an effect on the vulnerability of your C: drive but will not fulfill performance issues.
  • Many people seem to be under the impression that there is only one database. There are many systems that include multiple databases into their architecture. An Example is Microsoft Dynamics Great Plains which uses the Dynamics database to store GP system tables. This is in addition to their company databases. In additions to this, SQL Server itself uses the ‘master’ database for its server-wide metadata, the msdb database for job metadata and also backup details and the model database is used as a template for creating new databases. The log file is not a part of the database – it is a separate file. Another word to describe this file using an accounting term is ‘journal.’ This is a chronological record of every transaction that is written to the database. SQL Server does not write directly to the database files, it writes the transactions to the log then an internal process (called Checkpoint) writes the log file to the database tables. You can use this file when restoring a database to a ‘Point-in-time’ by a ‘play it again’ technique to bring the database to the required position. There are so many different scenarios – please allow me to catch-all by merely saying ‘other’ databases.
  • Many people seem to be under the impression that there is only one database. There are many systems that include multiple databases into their architecture. An Example is Microsoft Dynamics Great Plains which uses the Dynamics database to store GP system tables. This is in addition to their company databases. In additions to this, SQL Server itself uses the ‘master’ database for its server-wide metadata, the msdb database for job metadata and also backup details and the model database is used as a template for creating new databases. The log file is not a part of the database – it is a separate file. Another word to describe this file using an accounting term is ‘journal.’ This is a chronological record of every transaction that is written to the database. SQL Server does not write directly to the database files, it writes the transactions to the log then an internal process (called Checkpoint) writes the log file to the database tables. You can use this file when restoring a database to a ‘Point-in-time’ by a ‘play it again’ technique to bring the database to the required position. There are so many different scenarios – please allow me to catch-all by merely saying ‘other’ databases.
  • This is a development from the previous slide – it shows tempdb (which is important for tuning performance) and the log file which needs to be on a separate drive.
  • When designing storage there considerations other than space. The greatest bottleneck to performance is the physical (the speed of electrical signals is about .6 times the speed of light). Therefore, the if we increase the number of I/O heads we increase the speed of I/O. Online duplication is called Redundancy – write to 2 disks at once and we have twice the reliability – less risk of data loss from a problem with the hard drives.
  • When designing storage there considerations other than space. The greatest bottleneck to performance is the physical (the speed of electrical signals is about .6 times the speed of light). Therefore, the if we increase the number of I/O heads we increase the speed of I/O. Online duplication is called Redundancy – write to 2 disks at once and we have twice the reliability – less risk of data loss from a problem with the hard drives.
  • A stripe set is comprised of multiple disks joined in series into one volume. A mirrored set is comprised of multiple disks joined in parallel into one duplicated volume. Thus you will use twice the minimum storage space. A parity set is comprised of a set of hard drives arranged so that every volume has a duplicate of the data, compressed and stored on another disk. You ‘lose’ one disk from the set because of this compressed ‘parity’ copy of the data. The resultant storage space is n-1 disks. Raid 5 arrays enable hot-swop of disks. Raid 10 is a set of stripped disks that are them mirrored. They use twice the minimum storage space. Raid 10 arrays also enable hot-swopping disks.
  • The most susceptible disk is the one that holds the operating system. This is where problems are most likely to occur. Programs can also be installed on the ubiquitous ‘C:’ drive. This drive is capable of being clustered so that the user company can switch over to the another drive which holds the duplicate operating system and programs. OLTP databases are most suitable for storage on redundant systems. If the databases are small enough they could also just use a mirror which, at 2 disks, would be cheaper than even a Raid 5 system and just as advantageous as Raid 10). DSS databases do not need backups or redundancy as they can be recreated from a backup. Tempdb just needs speed since it is recreated each time SQL Server starts. Log files need redundancy and they are written heavily (by definition) but they are usually small enough not to require Raid 10 so a mirror is usually the answer. Backup files do not need backups and are never written to (unless written over) but they should be isolated from the other files unless there is a space problem.
  • This system is shown merely to provide the basis for a discussion of the different types of RAID systems and disk arrangements. Usually you would not design both a RAID 5 and a RAID 10 system – either have one or the other. However, a company usually end up with a compromise system which is driven by the philosophy – “we do not need to have the ultimate in performance as long as the system is fast enough to meet our needs.” Question: When entering data, how fast is fast enough? Answer: You should have sub-second response when entering data, which is the maximum time that passes before a data entry clerk loses momentum. Note: There is a Oracle standard that defines 8 secs as the maximum time that could pass before a person starts to think of something else.
  • DSS (Decision Support System) = a restored backup of the Production OLTP (Online Transaction Processing) database. An Example: If you backup and restore every night then you have a database that you can index extensively without affecting the OLTP database. An advantage is that all reports run against that database will be consistent as of End of Business yesterday. Test Companies can be used for training new staff, testing bulk uploads of data, ‘what-if’ scenarios, testing if the backup restores OK, etc. Development companies may be created from backups and used by developers who need a true example of the database for developing programs and add-ons. Scoreboards are used to hold aggregate totals and denormalized data for easy reference and performance. Lookups and Read-only databases can be comprised of many adaptations so that the production database does not have to carry the load. Examples: Photos of employees could be carried in a separate database. Price lists can be kept separate (Note: the permutations are endless – they may, or may not, be based on backed up databases).
  • OK, let’s answer some FAQs. Firstly -
  • Secondly -
  • Notice that this slide shows that the Cluster has 2 nodes (which hold the Operation system and the programs) but only 1 database!
  • Log-shipping is akin to – let’s copy our journal and post it to 2 copies of the General Ledger, (do it twice). We then have 2 copies, including our mistakes.
  • This is how log-shipping works, in the background.
  • The most common arrangement is to perform a Full backup every night. If this is what you wish this is what you get. Of course, if the database becomes in need of restoration the users will have to re-enter all data from the Full backup all over again. “ Hey, I enjoy doing things twice don’t you?” (sic) The cost of this in a 10 user company when the DB goes down at 4.30PM is 10 average man-days or 2 average man-weeks.
  • We will look at each of these in turn and discuss the restore patterns necessary.
  • Here are the options – that will enable: Restoration to the previous Full backup only Restoration to a Point-in-time. EG. If the database goes down at 4.30 you can restore to the 4.30 point it went down. This aides the restoration time by bypassing the log replays between the Full and the Last Differential BU This is for large DBs (called VLDBs) that need a permanent DBA and a complex routine.
  • ALL restorations must start with a restoration from a Full BU. Only the portion of the log that is needed to complete incomplete transactions that might be pending are backed up. There is no ‘real’ Log replay of transactions that were already ‘Checkpointed.’
  • A FULL backup strategy works like this, for example. You could backup once per week but every night is more common. You can go back to a previous backup but then you would have to re-enter data from that time.
  • By just backing up the log, which is an independent file, you can restore the database to a point-in-time. This means you will not have re-enter all the data since the last Full backup. If you restore from the previous backup you can replay/restore the logs to the same Point-in-time because they are completely sequential. The lsn (log sequence number) is stored in the msdb database. Logs MUST be restored sequentially.
  • Differential backups MAY be faster than FULL backups because they only backup the differences between the last FULL backup and the database at the time of the backup. Differential backups may speed the restoration by short-circuiting the restoration process by allowing the differential to be restored instead of the accumulated Logs.
  • Here is an illustration of a differential BU strategy. A restore still has to start with the FULL BU but you can skip all differential BUs to the LAST differential.
  • A complex arrangement involving filegroups may need an experienced DBA to implement since the planning requires a full understanding of the database and the implications of restoring parts of the database and not others.
  • Finally
  • And Finally stress this -
  • 1. The Application sends modification statements to the Database Engine 2. Modifications are written to the log, they can only be Insert, Update or Delete statements. 3. Data pages are read into RAM 4. the Checkpoint process reads the old data, performs the arithmetic, writes the new data – all in RAM.
  • A Volume made from a striped set consists of a number of disks in series, each disk merely adding to the size of the set.
  • Mirrored drives set consists of 2 drives in parallel. The second drive is a duplicate of the first drive and everything done on the first drive is duolicated on the second drive.
  • A Parity set consists of at least 3 drives. Each drive has an uncompressed area storing data and a compressed area that holds a compressed copy of the data stored on another drive. Drives in the set are hot-swoppable but if this happens, performance is terrible during the outage while the swop is taking place. A RAID 5 array is fast on Reads but a little slower on writing because the Parity data (compressed copy) has to be calculated when writing to the Parity copy.
  • For the last few years most sales have been RAID 10, a mirrored stripe set. That is - a Stripe-set that is then mirrored (Note: Not mirrored then striped). Although called RAID 10 it is actually RAID 0 + 1. There is a 50 % reduction in capacity because of the dupication but the copy is not compressed and there is no slow-down in write-speed. Hot swop is enabled and even when doing this there is no slow down in performance.

Transcript

  • 1. More than Backups for Accounting Databases Configuring disks can aid performance. Backups may be the last line of defense against data loss but they can also provide operational benefits. Cliff Beacham MBA, MCDBA, CPA.CITP
  • 2. Contents: 1. From the Company point of view 2. What are we hoping to achieve? 3. Technical – hardware - methods 4. Technical Questions (FAQs) 5. Conclusion & Recommendations2 © Cliff Beacham 2007
  • 3. Part 1: 1. Whose responsibility is it? 2. Why do it at all? 3. What Risks do we face? 4. Is it just a Management Decision? 5. Emerging Trends 6. Operational advantages 7. Consequences of downtime3 © Cliff Beacham 2007
  • 4. ERP Architecture (SQL Server) ERP Client ERP Server ERP Server ERP Client Application Application MasterDB ERP Database ERP Database msdbDB Server Server E.g. SQL Server E.g. SQL Server ERPSystemDB ERP Client ERP Client AccountingDB4 © Cliff Beacham 2007
  • 5. 1a. Whose Responsibility?: Shareholders Directors CFO CIO Controller IT Manager5 © Cliff Beacham 2007
  • 6. 1b. Why do it (SOX etc) Sarbanes Oxley has requirements that are: 1. law to public companies 2. common sense to others6 © Cliff Beacham 2007
  • 7. 1c. Risks – 5 main areas  Loss or failure of Hardware  Natural Disasters/Catastrophes  Theft or Destruction  Malicious/deliberate  Inadvertent error7 © Cliff Beacham 2007
  • 8. 1d. Management Decision 1. Compare Cost with Benefits 2. BUT remember there are decisions where cost vs. benefits are not applicable 3. Economic justification can be calculated by: Anything x Infinity = Infinity8 © Cliff Beacham 2007
  • 9. 1e. Emerging trends: 1. ISACA – Information Systems Audit and Control Association (50,000 members) CISA & CISM 2. CPA/CITP specialist designation 3. SOX applicability to smaller companies9 © Cliff Beacham 2007
  • 10. 1f. Operational uses of Backups: 1. DSS’s 2. Test Companies 3. Development Companies 4. Scoreboards 5. Lookups 6. Read-only databases10 © Cliff Beacham 2007
  • 11. 1g. Likely downtime “I’ll call the company that has the tape backup and see when they can get it back to us.” Most error is caused by users – if we have the backup we can restore immediately with minimum loss of productivity11 © Cliff Beacham 2007
  • 12. An aside (to be personal) Never, never, NEVER mix data and operating systems on the same drive Operating System Data12 © Cliff Beacham 2007
  • 13. Part 2: What are we trying to do?  2a. What databases need backing up  2b. Log file  2c. Other applicable DBs13 © Cliff Beacham 2007
  • 14. 2a. What databases need backing up?  Production  System databases – Master, msdb, Model  Log file  Other applicable DBs14 © Cliff Beacham 2007
  • 15. 2b. ERP Architecture (SQL Server) tempDB ERP Client ERP Server ERP Server ERP Client Application Application MasterDB ERP Database ERP Database msdbDB Server Server E.g. SQL Server E.g. SQL Server ERPSystemDB ERP Client ERP Client Log file AccountingDB15 © Cliff Beacham 2007
  • 16. 2c. Disk arrangements - Objectives: 1. Speed / Performance 2. Reliability / Redundancy 3. Vulnerability / Risk16 © Cliff Beacham 2007
  • 17. Part 3: Disks 1. RAID arrays 2. Appropriate use 3. Typical arrangement17 © Cliff Beacham 2007
  • 18. 3a. RAID (Redundant Array of Independent/Inexpensive Disks) RAID # Description 0 Striped set 1 Mirrored set 5 Parity set 10 Striped then Mirrored18 © Cliff Beacham 2007
  • 19. 3b. Appropriate use O/S + Programs Cluster OLTP db 5 or 10 DSS db Stripe Tempdb Stripe Log file Mirror Backup Isolated19 © Cliff Beacham 2007
  • 20. 3c. Optimizing the Database Using Filegroups with Hardware-based RAID RAID 10 RAID 10 Disk Disk Filegroup 11 Filegroup Controller Controller RAID 5 RAID 5 Disk Disk Controller Filegroup 22 Filegroup Controller Disk Disk RAID 0 RAID 0 Filegroup 33 Filegroup Controller Controller Disk Disk Controller Controller TempDB TempDB RAID 1 RAID 1 Operating System Disk Transaction Log Transaction Log Operating System Disk & Programs & Programs Controller Controller20 © Cliff Beacham 2007
  • 21. Part 4. FAQs 1. RAID 2. Cluster 3. Log Shipping 4. Full Backups 5. Backup Methods21 © Cliff Beacham 2007
  • 22. 4a. Why backup when I have a RAID system?  Because RAID does not deal with user error  RAID deals with Disc Hardware error and performance issues22 © Cliff Beacham 2007
  • 23. 4b. Why backup when I have a Clustered system?  Because Clusters do not deal with user error  Clusters are designed to deal with O/S and certain Program errors23 © Cliff Beacham 2007
  • 24. Typical Clustered System  Single subnet Web Web Host 1 Node 1  No routers Host 1  No Internet ethernet access to DB Web Web Host 2 Host 2 Web Web SQL Server Database SQL Server Database Host 3 Host 3 Clients Clients 2-node Cluster Service 2-node Cluster Service Network Load Balancing Network Load Balancing Web Web Node 2 Component Load Balancing Host 6 Host 6 Component Load Balancing24 © Cliff Beacham 2007
  • 25. 4c. Why backup when I have a Log- shipping system?  Because Log shipping does not deal with user error  Log shipping will faithfully replicate the error25 © Cliff Beacham 2007
  • 26. 4d. Log Shipping  Providesa Baseline  Backs Up Original Files, Objects, and Data  Backs Up Portions of the Transaction Log ProdDB ProdLS Log Ship Log Ship Log Log Data Data26 © Cliff Beacham 2007
  • 27. 4e. Why backup the Log when I have Full database backups?  Because Full backups do not enable Point-in- time recovery  A Full backup plan means you have to re- enter everything from the last Full backup27 © Cliff Beacham 2007
  • 28. 4f. Backup Methods Full Database Backup Differential Database Backup Transaction Log Backup Piecemeal Filegroup Backup plan28 © Cliff Beacham 2007
  • 29. Part 5: Strategies A. Full Database Backup Strategy B. Full Database and Transaction Log Backup Strategy C. Differential Backup Strategy D. Database File or Filegroup Backup Strategy29 © Cliff Beacham 2007
  • 30. 5a. Full Database Backup  Providesa Baseline  Backs Up Original Files, Objects, and Data  Backs Up Portions of the Transaction Log Northwind D: Log Backup Backup NwindBU Dat a30 © Cliff Beacham 2007
  • 31. Full Database Backup Strategy Created Database Full Database Backup Full Database Backup and Performed Full Database Backup Log Log Log Data Data Data Sunday Monday Tuesday31 © Cliff Beacham 2007
  • 32. 5b. Full Database and Transaction Log Backup Strategy Full Database Full Database Backup Backup Log Log Log Log Log Data Log Data Sunday Monday32 © Cliff Beacham 2007
  • 33. 5c. Differential Backup  Use on Frequently Modified Databases  Requires a Full Database Backup  Backs Up Database Changes Since the Last Full Database Backup  Saves Time in Both Backup and Restore Process33 © Cliff Beacham 2007
  • 34. Differential Backup Strategy Full Database Differential Differential Backup Backup Backup Data Log Log Log Log Data∆ Log Log Log Log ∆ ... ... Monday Tuesday34 © Cliff Beacham 2007
  • 35. 5d. Database File or Filegroup Backup Strategy Full Database Backup Backup Backup File3 Backup File1 File2 Log Log Data Log Log Data Log Log Data Log Log Log Data File 1 File 2 File 3 Monday Tuesday Wednesday Thursday35 © Cliff Beacham 2007
  • 36. 5e. Plan Database Files and Logs  Manage Disk Storage for: – Performance – Fault tolerance  Place Transaction Logs on Separate Disks  Place the tempdb Database separately  Adopt a coherent Backup policy36 © Cliff Beacham 2007
  • 37. Backup Strategy  Plan (and Document the procedure)  Implement  Test regularly  Document effectiveness of Internal Controls37 © Cliff Beacham 2007
  • 38. THE END Thank you for listening: Cliff Beacham (949) 813-1349
  • 39. How the Transaction Log Works 1 Data modification is 1 Data modification is sent by application sent by application 3 Modification is recorded 3 Modification is recorded in transaction log on disk in transaction log on disk Buffer Cache Disk Disk 2 Data pages are located in, 2 Data pages are located in, or read into, RAM and or read into, RAM and modified modified 4 Checkpoint writes 4 Checkpoint writes committed committed transactions transactions to database to database39 © Cliff Beacham 2007
  • 40. Optimizing a Database Using Hardware RAID  Using Hardware-based RAID – Better performance than O/S-based RAID – Enables hot replacement failed drive  Applying Types of RAID (Examples) – Disk mirroring (RAID 1) for redundancy of the log – Disk striping with parity (RAID 5) for performance and redundancy for data files and transaction logs – Disk mirroring with striping (RAID 10) for maximum performance for data files40 © Cliff Beacham 2007
  • 41. Example of User-defined Filegroups Production Database sys… sys… …… sys… sys… Orders Orders sysusers sysusers Customers Customers OrdHistYear2 OrdHistYear2 sysobjects sysobjects Products Products OrdHistYear1 OrdHistYear1 C: D: E: ProdOLTP.mdf OrdHist1.ndf OrdHist2.ndf ProdLog.ldf Primary Filegroup User-defined Filegroup Transaction Log41 © Cliff Beacham 2007
  • 42. RAID 0 – Striped drives Disk 1 Disk 2 Disk 3 100GB 100 GB 100GB Total Volume = 300GB42 © Cliff Beacham 2007
  • 43. RAID 1- Mirrored drives Disk 1 100GB Disk 2 100GB Total Volume = 100GB43 © Cliff Beacham 2007
  • 44. RAID 5 – Compressed copy on another disk Disk 1 Disk 2 Disk 3 100GB 100GB 100GB Parity Parity Parity Volume = 200GB (n-1 x 100)44 © Cliff Beacham 2007
  • 45. RAID 10 – A mirrored stripe set Disk 1 Disk 2 Disk 3 100GB 100 GB 100GB Disk 4 Disk 5 Disk 6 100GB 100 GB 100GB Volume = 300GB45 © Cliff Beacham 2007