The dr overnight dba


Published on

For MEDITECH system administrators that are new to the Data Repository (DR), you may have found yourself scratching your head if you haven’t supported Microsoft SQL Server before. Database backups? Index maintenance? Transaction log files? We’ve got you covered in this session, where we’ll teach you the basics of database administration, especially as they apply to the unique database design of MEDITECH’s DR. We’ll look at routine DBA best practices, including how to manage security and basic database maintenance. We’ll also review optimal DR server configuration according to MEDITECH guidelines , as well as ways to intelligently manage routine tasks like index defragmentation and disk space and database capacity planning. If you’re a DR system administrator and want to learn more about managing your SQL Server databases, come to this informative session.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

No notes for slide

The dr overnight dba

  1. 1. DR 101 – The Overnight DBA 2013 MUSE International Educational Session #1093 May 30 10:00am Presenter: Ian Proffer
  2. 2. Today’s Agenda • What is a DBA? • SQL Server & Management Studio • MEDITECH’s expectations for you • Administration: database maintenance, managing growth, user access and security • Analysis: getting data efficiently, monitoring and optimizing performance
  3. 3. What is a “DBA?” A. A database administrator B. A database analyst C. A database architect D. An FTE that hasn’t been filled yet E. A and B (or maybe D)
  4. 4. Microsoft SQL Server
  5. 5. SQL Server & Data Repository • DR is not a typical database (it’s a relational database without relationships) • The DR has 6,500+ tables as of 5.6x and over 35,000+ data fields • Security is managed through SQL Server or Windows Active Directory (no connection to MEDITECH security mechanisms) • DR databases include SQL tables with primary key clustered indexes and stored procedures
  6. 6. MEDITECH Wants You! To take care of your Data Repository
  7. 7. Server and Database Administration • Server Monitoring & Maintenance  Check the Windows Server and SQL Server logs regularly or when you see symptoms of possible problems  Perform regular database maintenance, including backups and data integrity checking  Monitor overall disk space and usage
  8. 8. Backups and Data Integrity • Database backups  Ideally every database has a full backup done daily during non-business hours  Older hardware with very large databases may use differential backups  Do I need to back up the transaction log?  The “Simple” recovery model  In the event of a system failure, how quickly can the database be brought back to a given point in time? • Data integrity checking (DBCC)  Check data integrity regularly (weekly, monthly)  DBCC, SQL Maintenance Wizard  Analyze and address index fragmentation
  9. 9. glass = database water = your data coaster = disk drive Managing Disk and Database Space
  10. 10. How to Check Database & File Space 1. Management Studio Report
  11. 11. How to Check Database & File Space 2. Database Properties
  12. 12. How to Check Database & File Space 3. T-SQL sp_spaceused
  13. 13. Managing Disk and Database Space • Disk space vs. database space  Make sure primary data drive has plenty of capacity for livedb growth  MT recommends you keep 25% free space for the livedb (typically the E: drive)  Database auto-growth options  Percentage vs. amount of space  Unrestricted vs. restricted space • What happens when the drive is full?  Transfers stop (crash) until the db can grow  Avoid this at all costs!
  14. 14. Using DR Manager to Plan for Growth
  15. 15. Managing Security & Access • Create your own database for report objects (stored procedures, functions, views, etc.)  This avoids co-mingling your code and objects with Meditech’s  This allows you to limit direct access to livedb • Use Active Directory groups for easier administration  e.g. ReportAdmins group, ReportViewer group • For those that need access to livedb data consider:  Using views in your database to selectively expose livedb data  Using SQL database-level roles for direct table access  ReportAdmins: db_owner, db_denydatawriter (read all data from livedb, ability to create indexes but no INSERT, UPDATE or DELETE)  ReportViewers: db_datareader (SELECT from tables)  ReportViewers_NoPP: db_datareader with further DENY SELECT permissions*
  16. 16. USE livedb GO SELECT 'DENY SELECT ON ' + name + ' TO ReportViewers_NoPP' FROM livedb.dbo.sysobjects WHERE xtype = 'U' AND name LIKE 'Pp%' ORDER BY name
  17. 17. Database Analysis • Optimizing queries  Query execution plans • Creating your own indexes • Handling index fragmentation • Other performance tools
  18. 18. Optimizing Queries • Viewing the query execution plan
  19. 19. Creating Your Own Indexes • Clustered vs. non-clustered  All DR tables already have a primary key clustered index. Don’t change them!  Non-clustered indexes can be added wherever you like • Document and save scripts for your indexes • General guidelines for new non-clustered indexes  SourceID, VisitID in any non-ADM (or EDM) top-level table  AbstractData, BarVisits, LabSpecimens, PhaRx, OeOrders  DateTime columns (AdmitDateTime, BatchDateTime, CollectedDateTime) • Multi-column (“covering”) vs. single column indexes
  20. 20. Index Fragmentation • The SQL Maintenance Wizard can address this, but…  Every table in the database is analyzed and acted upon  Indexes may be dropped and recreated (REBUILD vs. REORGANIZE) • Doing your own, targeted index maintenance is better  Assemble a list of tables you use regularly for reports  If maintenance hasn’t been done, address tables selectively on a series of first passes, then on a regular schedule (weekly, monthly, after initial loads)  After important tables are done, address the others • Limit amount of work done based on a fragmentation threshold or set number of tables (based on size) per session
  21. 21. Analyzing Index Fragmentation (Old School) Logical Scan Fragmentation – lower is better, anything above 25-30% would be a candidate to defragment. Avg. Page Density – higher is better, ideally 90-95%. The fuller each page is, the denser (less fragmented) the data are. -- Analyze fragmentation DBCC SHOWCONTIG ('dbo.AdmVisits') -- Defragment index if necessary DBCC INDEXDEFRAG ( DBNAME, TABLENAME, INDEXNAME)
  22. 22. Analyzing Index Fragmentation (New School) • Use SQL System Management Views • ALTER INDEX with REORGANIZE  Replaces DBCC INDEXDEFRAG • ALTER INDEX with REBUILD  Replaces DBCC DBREINDEX • You can use Management Studio or use T-SQL commands
  23. 23. Other Performance & Monitoring Tools • Activity Monitor
  24. 24. Other Performance & Monitoring Tools • SQL Profiler
  25. 25. Other Performance & Monitoring Tools • Database Engine Tuning Advisor
  26. 26. Discussion, Questions & Answers
  27. 27. Come see our MUSE sessions and visit us at Booth #603 in the Exhibit Hall! • Today at 1:30  1149 - Data Repository: The Journey to 6.0 and Beyond • Fri 5/31 3:30  1179- EHR Meaningful Use 2014 (Stage 2) DR Reporting Strategies Thank you.