1. Turning Practice into Perfect Implementing Fathom 2.0 Adam Backman White Star Software adam@wss.com

2. Notes ä All of the information covered in this presentation is covered in a new portion of the Progress documentation called: OpenEdge Revealed Mastering the Progress Database with Fathom ä A system works as a whole and not as a sum of its parts so the presentation is written the same way. With this in mind please hold your questions until the end

3. Presentation Goal ä Explain how to use Fathom ä Implementing best practices ä Not here to teach in-depth System Administration ä Point you to other presentations for more in- depth information

4. The Operation’s Challenge ä Constant reactive mode ä Manual processes ä Poor reporting ä Unplanned downtime ä Cannot plan for growth ä Poor System Performance Resulting In: n n Unpredictable Operations n n Exposure to Errors n n Incomplete Information n n Frustrated End Users n n Frustrated Administrators

5. Goals of a Well Maintained System ä Resiliency – The ability to recover ä Availability – Provide maximum uptime ä Performance – Consistency despite system load Fathom can help achieve these goals

6. Roadmap ä What are best practices? ä What is Fathom? ä Providing a resilient system ä Making your system highly available ä Providing consistent performance

7. What are Best Practices? ä Defined processes to follow ä Consistent verifiable outcome ä End result – well maintained system

8. Defined Process to Follow ä Must have clear goals ä Functional ä Business ä Document where you are now and how you are going to achieve your goals Munich Paris London Amsterdam Prague Paris

9. Defined Verifiable Outcome ä Know what you expect ä Know what you are getting ä Test completely prior to implementation ä Unit testing ä End-to-end testing

10. Well Maintained System ä Ability to support 24 hour operations with only scheduled outages for upgrades and maintenance ä Ability to recover from disaster with little or no data loss and minimal interruption to operations ä Ability to support the changing needs of the business with little or no performance degradation during times of heavy processing

11. Roadmap ä What are best practices? ä What is Fathom? ä Providing a resilient system ä Making your system highly available ä Providing consistent performance

12. What is Fathom? ä Java-based management console and agent ä Management console ä Provides interface to the agent ä Provides an interface to the Fathom Database ä Allows for definition of alerts ä Fathom agent ä Collector of operating system resource information ä Collector of Progress database management information

13. Dictionary ä Resource – Anything Fathom can monitor or trend ä Schedule – A defined timeframe when a resource is available for monitoring, alerting, and trending ä Poll – The process of gathering information about a resource ä Rule – a performance requirement that can be evaluated ä Alert – A response to a rule being broken ä Action – A process to be performed in response to an alert ä Trending – The process of storing performance and audit data in the Fathom Trend Database ä Monitoring – Performing polling, evaluating rules, generating alerts, executing actions, and trending of a resource within a scheduled timeframe.

14. Progress Fathom Architecture Fathom DB Fathom DB ProductionDBProductionDB Memory Disk CP U Net* Log File System

15. Fathom Architecture Multiple Sites Fathom DB Fathom DB Fathom DB Fathom DB

16. Fathom Architecture Monitor Locally\Trend Remotely Fathom DB Fathom DB

17. Fathom Architecture 2.0 Monitor/Trend Database Remotely DB Agent Fathom DB Fathom DB Fathom DB Fathom DB

18. DB Agent Fathom Architecture 2.0 Monitor & Trend Anywhere Fathom DB Fathom DB Fathom

19. Fathom Architecture Manage from One Browser Fathom DB Fathom DB DB Agent Fathom DB Fathom DB Fathom DB Fathom DB

20. Roadmap ä What are best practices? ä What is Fathom and how does it work? ä Providing a resilient system ä Making your system highly available ä Providing consistent performance

21. Resiliency ä Redundancy ä Developing an effective recovery plan ä Monitoring for problem avoidance

22. Redundancy ä Disk ä RAID ä Raid Levels ä Dos and Don’ts ä After imaging ä Memory

23. RAID ä Redundant Array of Inexpensive Disks Patterson, Gibson and Katz at the University of California Berkeley (1987) ä Common RAID Levels ä RAID 0 – striping ä RAID 1 – mirroring ä RAID 10 or 0+1 – Striped with mirrors ä RAID 5 – Striped with calculated parity

24. RAID: Dos and Don’ts ä Do: ä Use RAID 10 for randomized storage ä Use RAID 1 for sequential storage ä Use RAID 5 for READ-ONLY data ä Don’t ä Use RAID 5 for OLTP ä Use RAID 0 for data storage

25. Memory Interleaving Memory interleaving works like RAID 0 for memory. While there are significant potential performance gains from interleaving memory you run the risk of having one faulty memory chip bring down your application.

26. Resiliency: Recovery Planning ä Who in involved in the process? ä What gets backed up? ä Where do we backup up our data ä Where do we store the physical backup? ä When do we do a backup? ä Why do a backup at all? ä How can Fathom help?

27. Who is Involved in Recovery Planning? ä Technical people ä They understand what is possible ä Business people ä They understand what is needed and the cost of downtime ä Management ä They understand where the business is headed and what can be afforded

28. What is Included on the Backup? ä More than just a database backup ä Database ä Application ä Other Files ä Physical backup ä Secondary machine room ä Additional Hardware ä Infrastructure

29. Where Do We Backup To? ä Capacity – How much do you need to store? ä Removable – To allow off-site archival ä Reliable – It must work every time ä Compatible – Keeps your options open

30. Where to Store your Backup? ä Formal service ä 24 hour access ä Secure ä Highly disaster resistant ä Separate location (different building) ä Inexpensive ä Greater need for planning (access, security, disaster, etc.)

31. When to do a Backup? ä As often as practical ä A once a day backup will cause you to loose up to 24 hour of processing in the worst case ä Fill in with after imaging ä Store AI on different disk ä Archive AI files throughout the day ä Keep warm standby to reduce downtime

32. Why do a Backup? ä Reduce data loss ä Build user confidence ä Keep your job

33. How Can Fathom Help? Scheduling ä Consistent schedule that is not forgotten ä Pro-active notification if there is a problem ä Fathom 2.0 Job Templates

34. How Can Fathom Help? Reporting ä Processing time is captured ä Historical trend report of backup ä Audit trail

35. Resiliency: Problem Avoidance ä Common problem areas: ä Disk full problems ä Database extents filling fast

36. Fathom: Disk Monitoring ä Disk view ä Monitoring disks other than database ä Graphical view of what disks look like

37. Roadmap ä What are best practices? ä What is Fathom and how does it work? ä Providing a resilient system ä Making your system highly available ä Providing consistent performance

38. Availability ä Reducing the impact of unplanned events ä Planning for system growth ä Reducing impact of change to the user ä Scheduling Online Utilities

39. Planning for System Growth ä Trending allows for patterns to be viewed and acted upon ä Trending allows for operational thresholds to be established ä Trending allows for advanced planning so maintenance can be scheduled when convenient for the business

40. Fathom: Disk Trending ä Correlating database and disk trends ä Month by Month, Week by Week or Day by Day it is your choice ä Fill rates and activity of each disk

41. Fathom: Storage Area Trending ä Fill rate ä Activity by area ä This information can show a need to spread data even further

42. Fathom: Table and Index Trending – database analysis ä Predicting table growth ä Predicting Index growth ä Index compaction rates can be monitored and actions can be taken if the compaction drops below a certain level ä Utilization of each table and index can also be tracked and viewed in other areas of fathom

43. Fathom: Memory Trending ä Focus on paging and swapping rather than utilization ä This is currently a weak area within the Fathom product

44. Fathom: CPU Trending ä Look at Idle ä Look at the ratio between User and System ä High system time can indicate an incorrect value for –spin or High paging or swapping

45. Roadmap ä What are best practices? ä What is Fathom and how does it work? ä Providing a resilient system ä Making your system highly available ä Providing consistent performance

46. Performance ä Performance is relative ä Fast is overrated ä Fathom can help find tough problems

47. Performance is Relative ä What is a baseline? ä Determining your baselines ä How Fathom can help ä Important indicators ä Who is your canary?

48. Determining your baseline ä Good baseline guidelines ä Often accessed portions on the application ä High customer impact ä End to End (Time to enter an order) ä Bad baseline ä Year-end process ä Management reporting (in most cases) ä Little used portions of the application

49. Components of Performance ä Network ä Disk ä Memory ä CPU

50. Issues: Network ä Check your network capacity BEFORE adding any additional applications ä Baseline response times with Fathom ä Routed vs. switched networks ä Location of Progress files ä Program Libraries

51. Issues: Disk ä Storage capacity vs. throughput capacity ä Remember your RAID levels ä Location of data

52. Issues: Memory ä Memory acts as a buffer between the user processes and disk ä Use memory for the common good ä Increase broker memory first ä Increase client memory (-Bt, …) ä Then get creative

53. Issues: CPU ä Good CPU usage vs. Bad CPU Usage ä The –spin parameter ä Have a CPU problem? Look at your disks

54. Monitoring Performance ä Spot checks ä My Fathom Views ä Trend reporting ä Getting out of the Forest

55. Conclusion ä Start slow ä Remember your goals ä Resiliency ä Availability ä Performance ä Consider the cost/benefit before adding monitoring or trending to a resource

56. Questions