DBA101

Editor's Notes

• #12: Bottom line: Y2K introduced a drop dead date for re-hosting. This has stemed the move to distributed systems. Is this true of your accounts ? If not rehosted, re-investment into M/F solution and this is unlikely to be abandoned. ERPs are now in the Mainframe space. Announce may 10th SAP application server to run on OS/390. For e-business, the mainframe webserver supports high volume transactions.
• #17: Pre-Joined Tables - Used when the cost of joining is prohibitive. Report Tables - Used when specialized critical reports are needed. Mirror Tables - Used when tables are accessed concurrently by multiple different types of environments. Split Tables - Used when distinct groups use different parts of a table. Combined Tables - Used to consolidate one-to-one or one-to-many relationships into a single table. Redundant Data - Used to reduce the number of table joins required. Repeating Groups - Used to reduce I/O and (possibly) storage usage. Derivable Data - Used to eliminate calculations and algorithms. Speed Tables - Used to make the processing of hierarchies more efficient. Physical Denormalization - Used to optimize for specialized physical DBMS characteristics.
• #18: Bottom line: E-commerce is driving workload growth. The data we are seeing shows that transaction based processes are expanding. This is significant for us as we move forward. Gartner: Te internet gives rise to unpredictable and unthrottable transaction volumes. The explosion in electronic delivery channels will lead to a mammoth surge in online transaction volumes. Number of IMS transactions growing at a rate of 25% Researchers forecast a three-fold increase in IT transactions between now and the year 2000. Every day, within the US alone, S/390-based systems transfer approximately two trillion dollars in electronic funds with near 100 percent availability. The number of US home banking users is expected to grow 75 percent annually until the year 2000. Ninety percent of the worlds largest businesses run their mission critical transactions on CICS and IMS processing monitors. IBM technology holds a potential 60 million North American households to enable access to the home-banking highway. The world’s largest organizations rely on a continuous link to information and logic residing on large-scale hosts. IBM CICS and IMS provide that access to business critical data and logic, keeping information accurate and consistent while providing timely access to many end users. Investments in these mission critical systems are profound. Changes that affect the corporate ‘jewels’ are evaluated intensely with conservative perspectives. The challenge to business is to leverage existing investments in mission critical systems while extending the business through new delivery platforms and the Internet. What is needed is an evolutionary approach to the new revolution.
• #19: Atomicity means that a transaction must exhibit an “all or nothing” behavior. Either all of the instructions within the transaction happen, or none of them happen. Atomicity preserves the “completeness” of the business process. Consistency refers to the state of the data both before, and after, the transaction is executed. A transaction maintains the consistency of the state of the data. In other words, after running a transaction all data in the database is “correct.” Isolation means that transactions can run at the same time. Any transactions running in parallel have the illusion that there is no concurrency. In other words, it appears that the system is running only a single transaction at a time. No other concurrent transaction has visibility to the uncommitted database modifications made by any other transactions. To achieve isolation a locking mechanism is required. Durability refers to the impact of an outage or failure on a running transaction. A durable transaction will not impact the state of data if the transaction ends abnormally. The data will survive any failures.
• #23: Specifying read uncommitted isolation implements read-through locks and is sometimes referred to as a dirty read . It applies to read operations only. With this isolation level data may be read that never actually exists in the database, because the transaction can read data that has been changed by another process but is not yet committed. Read uncommitted isolation provides the highest level availability and concurrency of the isolation levels, but the worst degree of data integrity. It should be used only when data integrity problems can be tolerated. Certain types of applications, such as those using analytical queries, estimates, and averages are likely candidates for read uncommitted locking. A dirty read can cause duplicate rows to be returned where none exist or no rows may be returned when one (or more) actually exists. When choosing read uncommitted isolation the programmer and DBA must ensure that these types of problems are acceptable for the application. The read committed isolation level, also called cursor stability , provides more integrity than read uncommitted. When read committed is specified the transaction will never read data that is not yet committed; only committed data can be read. With an isolation level of repeatable read a further restriction is placed on reads, namely the assurance that the same data can be accessed multiple times during the course of the transaction without its value changing. The lower isolation levels (read uncommitted and read committed) permit the underlying data to change if it is accessed more than once. Use repeatable read only when data can be read multiple different times during the course of the transaction and the data values must be consistent. Finally, the greatest integrity is provided by the serializable isolation level. Serializable isolation removes the possibility of phantoms. A phantom occurs when the transaction opens a cursor that retrieves data and subsequently another process inserts a value that would satisfy the request and should be in the result set.
• #32: Unplanned outages - driven by problems Element failure Performance degradation Capacity limitation Application logic error Transaction backout Data corruption Planned outages - driven by change Database maintenance Application migrations Configuration upgrade Data propagation Source of 70% and 30% is CIO feed back during Customer briefings and meetings.
• #33: Type of Business Estimated Hourly Financial Impact of an Outage Retail Brokerage $6.45 million Credit Card Sales Authorizations $2.6 million Home Shopping Channel $113,750 Catalog Sales Centers $90,000 Airline Reservation Centers $89,500 Package Shipping Service $28,250 ATM Service Fees $14,500 Percentage Approximate Downtime Per Year 99.999% 5 minutes .08 hours 99.99% 53 minutes .88 hours 99.95% 262 minutes 4.37 hours 99.9% 526 minutes 8.77 hours 99.8% 1,052 minutes 17.5 hours 99.5% 2,628 minutes 43.8 hours 99% 5,256 minutes 87.6 hours 98% 10,512 minutes 175.2 hours (or 7.3 days)
• #51: This is the most basic strategy (and the only one actually supported by IBM). You must be able to determine a common recovery point for a series of table spaces . A DB2 quiesce certainly works fine but if that’s not available, a quiet point report can be generated to show common points of consistency. One of the listed points of consistency can be used as a recovery point. Of course there is the question of determining what exactly had run since the bad transaction. For this the summary report (by Unit of Recovery, Table) is the ideal weapon. It is assumed that the user would rerun or reentry “Good Transaction 2”.
• #52: For example, suppose you took a full image copy of a database object early Monday morning at 2:00 AM; and then took an incremental image copy at the same time the following three mornings. The full image copy plus all three incremental image copies need to be applied to recover the tablespace. If the same column of the same row was updated on Tuesday to “A”, Wednesday to “B”, and Thursday to “C”, the recovery process would have to apply these three changes before arriving at the final, accurate data. If a full image copy were taken each night, the recovery process would only need to apply the last image copy backup which would contain the correct value.
• #53: The simplest version of SQL based transaction recovery is the generation of UNDO SQL (inserts turned into deletes, etc.) for the transactions in error. Note that in this case there is no work that needs to be redone. But, the potential for anomalies causing failures in the UNDO is certainly a consideration.
• #57: XML is getting a lot of publicity these days. If you believe everything you read, then XML is going to solve all of our interoperability problems, completely replace SQL, and possibly even deliver world peace. Okay, that last one is an exaggeration, but you get the point. In actuality, XML stands for eXtensible Markup Language. The need for extensibility, structure, and validation is the basis for the evolution of the web towards XML. XML, like HTML, is based upon SGML (Standard Generalized Markup Language) which allows documents to be self-describing, through the specification of tag sets and the structural relationships between the tags. HTML is a small, specifically defined set of tags and attributes, enabling users to bypass the self-describing aspect for a document. XML, on the other hand, retains the key SGML advantage of self-description, while avoiding the complexity of full-blown SGML.
• #63: 19 The concept that inspire our product lines is exemplified here by the Cockpit of a Boeign 777 perhaps the most advanced and automated aircraft today. Like in a real aircraft cockpit our products are focused at keeping your mission critical applications running (availability) and running efficiently (performance). Transition Also like in a real cockpit we not only display valuable information on the equipment and the applications that comprise your Distributed Enterprise but ...