150 likes | 269 Views
Lessons Learned From The SNS Relational Database. Presented by David Purcell For David Purcell, Jeff Patton, and Katia Danilova. Oracle Server. XML, .db, HTML. 1. Design information: names, locations, .db, .cmd, …. 6. Applications. 4. Web-based reports, Initialization Files.
E N D
Lessons Learned From The SNS Relational Database Presented by David Purcell For David Purcell, Jeff Patton, and Katia Danilova
Oracle Server XML,.db,HTML 1. Design information:names, locations, .db, .cmd, … 6. Applications 4. Web-based reports, Initialization Files 5. Software in Network Attached Devices 2. Equipment receiving, acceptance test data:tracked by barcode 3. Calibration/Maintenance of installed devices:tracked by barcode Future Plans - Central Role of Database From 2003 ICALEPCS (Gyeongju (Korea)) Weekly Highlights
And A Quick Look At The Numbers Weekly Highlights
Let’s Compare 2007 • Database Applications 2003 • Database Applications • LabVIEW • XAL • Rack Profile • Web PV Data Applications • Electronic Logbook • JERI (Java EPICS RDB Interface) • Bypass Request System • Equipment Tracking System • Web Reports (Discoverer) • Commercial Products (ProjectWise, DataStream) • DB 2 XAL • DB Browser • Data Queries • From Alarm Log To Oracle • From Error Log To Oracle • IOC Health to RDB • PS Report • PV Log Browser • SS Loader • Spline Fit • Trip Monitor • Trip Viewer • IOC Report Tab • Diagnostics IOC configuration • Bypass Request • Data search and archive • DataStream • Datastream Reports • Document Number Reservation • Electronic Logbook • Equipment Tracking • Equipment Receiving • ICS NetReg • JACoW SPMS (ICALEPCS07) • Jeri • MPS Trips • MPS Audits • ODBC users • Operations Administration • Power Outage Report • Power Updates • Primavera • Projectwise • PSSO Wireless Meter Entry • PSSO Meter readings Report • Certain Physics applications • Power Supply configuration generation • PV Crawler • PV Logger • RF Cavity trips • SCORE • SNS channels 22,32,96,97,98 • SNS Service Request Web Interface • SNS Work Order Closeout • Web reports including ROCS Weekly Highlights
Who are “We” • Band of merry database professionals. Weekly Highlights
Lost Opportunities? • SNS has been successful • Many good things done without using the SNS RDB. • “We” have learned a lot. • Lost opportunities caused disappointment but increased ability to produce later on. Weekly Highlights
Lost Opportunities What Did We Learn. • Deadlines • User/Client Expectations • Data In Versus Out • Good Schema • Data Maintenance Reasons for Success • Good Schema • Project Champion • Historic Reference • Real Need • Code Stealing Weekly Highlights
Some Examples - Configuration PC Based IOCs (Provide database derived configuration files to PCs) • Management Request • No Leader or “Champion” • No Long-term Plan or Procedure • Complex GUI BLM IOCs (Provide database derived configuration files to BLM IOCs) • “Champion” Left Project. • Database Developer Within BLM Group. • No Set Procedure. • GUI built as Part of Project BUT Not Completed. • RDB Control Developed to Replace Existing Hand Entry. Power Supply (Provide database derived configuration files to power supplies) • Multiple Leaders • Multiple Scopes • Good Plan and Procedure • Functioning Application • Schema Required Data From Others MPS (Provide database derived configuration files to MPS IOCs) • Strong Leader or “Champion” • Set Procedure • Existing Usable GUI • Standard Accepted Tool Weekly Highlights
Some More Examples Electrical Power Project (RPPA13) (Manage and Report on Electrical Power Routing) • Management Driven • Strong Leader or “Champion” • Procedure Built Into Project • Created GUI at Start of Project • Standard Accepted Tool • QA of Data • Data Ownership Diagnostics RDB Reports (Accessible data summary reports specific to the Diagnostics Group) • Group Leader Implemented • Database Developer within group acting as “Champion” • Data Ownership • Standard Toolset • Leader and developer have left group. General RDB Reports • Simple is better. • Require Easy Access (web or email) • Alternative not available. • Clients are necessary Weekly Highlights
Final Examples Electronic Logbook (Electronic Logbook) • SNS Wide Requirement. • Non-Restrictive Timeframe. • No RDB Restrictions on Data. • Easy to Use GUI. • The Wrench that Pounds the Nail. Equipment (use of DataStream to track equipment maintenance) • Management Mandate • Strong Leader or “Champion” • Takes advantage of complex SNS schema. • COTS (DataStream) • Ready to Use System? • SNS RDB developers not able to work with data. • GUIs are available but do not meet client requirements. • Overwhelming • No Implementation Strategy. • Too Much Work and Not Enough Support Personnel. • Extra Unplanned Work for Technical Groups. • Introduced Work-a-rounds • No Tools. • No Maintenance plan. Weekly Highlights
Who thinks what? • Database Developers (Glad and Sad) • Glad we have helped in the ways we have. • Disappointed in the lost opportunities. • Software Engineers (Pessimistic) • Changes in approach don’t help reach goals and the RDB is therefore unnecessary. • General Users (Frustrated) • Believe RDB should be populated. • Want Permissions. • Want Applications That Allow Maintenance. • Management (Apathetic) • Good idea, Use it if you can. • Don’t let it slow you down. • Still Not High Priority Weekly Highlights
What Does SNS Need To Do? NOTHING. • The overall goals of the project continue to be realized. BUT… • Goals may be easier to reach with a stronger RDB implementation. Weekly Highlights
SNS Summary Did Well • Schema • Complex but serves most project needs. • RDB was emphasized from beginning of project in a couple of groups. • I was first hired in Diagnostics group and did all sorts of stuff. It became personal. • Enthusiastic Champions • Some Groups Implemented directed use of RDB. • Managers of the Physics and Diagnostics directed members RDB final resting place for data. • Some Great applications and Reports • ELog, JERI, … Weekly Highlights
SNS Summary Cont. Could have done better. • Management support. • Procedures and Standards • More RDB development personnel. • Standardize the RDB use for all of project. • Access, Oracle, MySQL, etc are still in use. • GUI - Standardized toolset for data entry and reporting. • Entry GUIs Especially Bad or Absent. • Eliminate Telepathic Requests • Give tools to users as soon as possible. • Plan on how to deal with short cuts that were allowed. • Incorrect RDB use • Engineers admit to entering data just to get it in. Now it’s embedded and hard to fix. Weekly Highlights
Advice: • Start thinking RDB from start – a mind set • Unofficial part of mission statement. • Sooner or later it will go in. • Get support • Hire Database Developers as soon as possible • Help them understand their role. • Multi-task RDB developers as technicians (or vice versa) • Embrace Project Champions • Take advantage of what is available. • Settle on one project-wide toolset. • SNS Schema or IRMIS … • Use common reporting and input tools • Project-wide use of agreed upon RDB • Try to eliminate allowance of shortcuts. • Non-standard is bad and will probably become permanent. • Make Use of RDB Applications a No-Brainer • Don’t Mandate but proceduralize – Procedures and Standards. Weekly Highlights