Oracle Performance Tuning 11g2 (2-0)

這一節的內容非常的多，我複製到word中之後達到了30頁的大小，為了防止無法上傳到部落格，我分成2部分翻譯。因此能看完此篇，絕對有學好oracle的潛質。

因為文章太長，所以我可能會將一些英文的內容在翻譯完刪除掉；最好的辦法是花幾分鐘掃一眼大致內容，然後去看原版的英文文件最妙。

2 Designing and Developing for Performance

Optimal system performance begins with design and continues throughout the life of your system. Carefully consider performance issues during the initial design phase so that you can tune your system more easily during production.

理想情況下，效能設計要在系統設計階段就要考慮進來，並且要貫穿在系統生命週期當中。在應用系統設計階段仔細的考慮好系統的效能問題，遠比在上線之後再去調優效能要容易的多。（這些話說起來很簡單，但是在銀行的系統中，很多專案經理可能只有2年左右的工作經驗（5年工作經驗的或許都轉行去淘寶開店了，或者當個小官，不做技術了），很難讓他們去考慮那麼多，而且他們本身開發能力就不夠，哪裡能考慮那麼多。不僅是年輕人辦不到，在專案工期比較緊的時候，牛人也顧不了那麼多，只能靠經驗大概的去判斷一下就開始設計開發了（這算好的了，有些專案主管是那種僅僅嘴上能說的那種，許多知識只是聽說過一點卻不懂實際開發技術還要參與設計，即使不對它還要堅持它的想法，可想而知後果是什麼樣子的。因此專案經理參與的越少專案成功的機率越大）。因此效能問題基本上都放到專案上線前的那段壓力測試階段去修正，而oracle已經告訴我們這樣是比較難的了---它說的沒錯，的確比較難了。很多時候在效能出現問題時需要修改程式碼，但是往往程式碼已經開始進行凍結狀態，SVN也要凍結的，沒有高層的授權不能去隨意的改的，否則一旦修改後就需要將全部的業務功能要重新測試一遍----測試人員能饒得了你這麼折騰嘛！下次還想不想混了！）

This chapter contains the following sections:

• Oracle Methodology

• Understanding Investment Options

• Understanding Scalability

• System Architecture

• Application Design Principles

• Workload Testing, Modeling, and Implementation

• Deploying New Applications

2.1 Oracle Methodology

System performance has become increasingly important as computer systems get larger and more complex as the Internet plays a bigger role in business applications. To accommodate this, Oracle has produced a performance methodology based on years of designing and performance experience. This methodology explains clear and simple activities that can dramatically improve system performance.

Performance strategies vary in their effectiveness, and systems with different purposes—such as operational systems and decision support systems—require different performance skills. This book examines the considerations that any database designer, administrator, or performance expert should focus their efforts on.

System performance is designed and built into a system. It does not just happen. Performance problems are usually the result of contention for, or exhaustion of, some system resource. When a system resource is exhausted, the system cannot scale to higher levels of performance. This new performance methodology is based on careful planning and design of the database, to prevent system resources from becoming exhausted and causing down-time. By eliminating resource conflicts, systems can be made scalable to the levels required by the business.

隨著網際網路應用扮演著更加重要的角色，系統變得非常的龐大而且複雜，效能問題顯得更加的重要。為了達到效能要求，oracle根據自己多年的深耕發展了自己的一些效能方法論。這種最佳化技術清晰明瞭簡單實用，同時能像夢一般（顯著）的提升效能，呵呵。居家生活必備良藥啊！

效能最佳化策略在不同的系統業務領域有著不同的方式，比如在OLTP系統和資料庫倉庫中就不一樣。本書主要研究了對於資料庫開發人員，管理人員，和效能專家都應該考慮的基本問題。

系統效能功能被內嵌到系統之中。不是說效能問題時時刻刻都發生。它通常是由於爭用（競爭，併發）或者是過度的使用某些系統資源造成的。當一個系統資源被過度使用時，系統效能很難提升到一個很高的層次。oracle新的效能技術是基於對資料庫深入的研究以及精心的設計而發展演化的，它能阻止那麼系統資源被過度使用所導致當機情況的出現。透過消除這些資源亂用情況，系統將變得更加的穩固可靠，以達到業務要求的水平（只要適合業務要求即可，不需要過多的最佳化----每多一步最佳化對專案都是成本壓力）。

 

2.2 Understanding Investment Options     專案投入

With the availability of relatively inexpensive, high-powered processors, memory, and disk drives, there is a temptation to buy more system resources to improve performance. In many situations, new CPUs, memory, or more disk drives can indeed provide an immediate performance improvement. However, any performance increases achieved by adding hardware should be considered a short-term relief to an immediate problem. If the demand and load rates on the application continue to grow, then the chance of the same problem occurring soon is likely.

In other situations, additional hardware does not improve the system's performance at all. Poorly designed systems perform poorly no matter how much extra hardware is allocated. Before purchasing additional hardware, ensure that serialization or single threading is not occurring within the application. Long-term, it is generally more valuable to increase the efficiency of your application in terms of the number of physical resources used for each business transaction.

隨著CPU，記憶體，硬碟的價格不斷的下降，透過購買更多的硬體去提升效能是許多人的想法。在許多場景下，購買新的CPU,記憶體，硬碟的確能立竿見影的看到效果。透過購買硬體來立即大幅提升系統效能僅僅是一種吃興奮劑的效果。但是如果需求和壓力繼續增長的話，這種解決問題的辦法是不可行的，也就是說問題還是在前面路口等著你。

在有些場合下，加硬體一點都無法提升效能。差勁的系統設計無論加多少CPU記憶體都沒用的，它們根本無法使用到的。在你購買新的硬體之前，確保你的應用程式不是序列化處理的，同時不是單任務（單程式）在執行。長期來看，透過提升應用程式的資源使用效率是更加划算的。

注：在銀行業開發C語言程式是很簡單的一件事，因為記憶體不夠要銀行加就是了。所以很多時候看到一個人在仔細的節約記憶體使用時，就知道他基本上是個外行（或者高高手）。多數情況下透過增加CPU和記憶體，我們可以更加容易的提升系統的效能，特別是硬體很便宜的情況下。簡單算一下：買32G記憶體也不過3000塊錢，請個專家最佳化一下可能幾萬就沒了，回頭可能還要買硬體，對不？

    應用伺服器加再多的CPU也不過是電費空調費增加的問題。但是我們知道ORACLE可是有一種按CPU賣錢的，這樣在資料庫上加更多的CPU有時是不划算的，這就是為什麼有時在開發的時候會將許多業務直接在應用中實現，而不是去使用資料庫已提供的功能，就是這個原因。

    但是有的時候加硬體是沒有用的。可能有人說怎麼可能？ 我舉個簡單的例子，兄弟我唯一能玩的遊戲就是蜘蛛紙牌（4幅牌的那種噢），其他的都不喜歡。那你說給我一個8核，32G記憶體的電腦對於提升蜘蛛紙牌效能有多大影響？同樣的道理，我見過一個系統，他們在伺服器上就一個程式在處理業務（因為難以併發執行，我看了系統設計後發現要併發的確需要大量的工作要做，的確比較難），這樣使用1個主頻更高的POWER CPU更划算些，因為它只能使用這一個，給2個就是浪費，不如劃分一個給我玩蜘蛛紙牌了。另外一個就是批次程式，通常這玩意兒是要按序列化進行處理的，比如先要批次增加新註冊的個人資料，然後再處理公司的工資入賬預處理，同時併發執行個人業務相關預處理，但是以上所有這些工作不能放到真正入賬程式步驟之後，必須要提前處理的，順序一定要正確的，這就是序列化。因此對於多大的交易量，單一時刻也只能使用那麼多。更簡單的說就是隻有一張嘴，不能說著話再吃著東西吧！（或許上帝發明鼻子就是為了解決吃飯時還可以吸氣？）

 

2.3 Understanding Scalability

The word scalability is used in many contexts in development environments. The following section provides an explanation of scalability that is aimed at application designers and performance specialists.

擴充套件性這個詞在開發環境中使用的比較多些。下面的章節和系統設計人員和效能分析人員討論一下擴充套件是什麼玩意兒。包含了什麼是可擴充套件性？系統如何擴充套件？阻止可擴充套件的因素有哪些？（我個人特別喜歡oracle這種風格，它總是能以列舉的方式仔細的剖析問題，然後加以解決）

This section covers the following topics:

• What is Scalability?

• System Scalability

• Factors Preventing Scalability

2.3.1 What is Scalability?

Scalability is a system's ability to process more workload, with a proportional increase in system resource usage. In other words, in a scalable system, if you double the workload, then the system uses twice as many system resources. This sounds obvious, but due to conflicts within the system, the resource usage might exceed twice the original workload.

可擴充套件性就是可以透過增加系統硬體資源的使用量就能處理更多業務的一種能力。換句話說，當業務量增加一倍的時候，系統資源比如CPU使用率真就隨之增加一倍。聽起來好像是理所當然的事情，但是由於系統內部設計中的資源競爭和衝突，這個系統資源的使用可能不止2倍的。下面列舉幾個差勁的擴充套件性導致資源無法合法使用的情況：

Examples of poor scalability due to resource conflicts include the following:

• Applications requiring significant concurrency management as user populations increase   隨著使用者量的增加，系統需要更多的併發處理

• Increased locking activities                                                                                         業務量增加時鎖隨之增加

• Increased data consistency workload                                                                           資料併發量隨著業務量增加而增加

• Increased operating system workload                                                                          作業系統負荷增加

• Transactions requiring increases in data access as data volumes increase                        業務量增加時事務處理隨之增加

• Poor SQL and index design resulting in a higher number of logical I/Os for the same number of rows returned  SQL和index設計差勁

• Reduced availability, because database objects take longer to maintain                           資料庫需要更長的維護，導致可用性降低

An application is said to be unscalable if it exhausts a system resource to the point where no more throughput is possible when its workload is increased. Such applications result in fixed throughputs and poor response times.

由於過度使用系統資源，當一個系統的業務增加到一定程度時，系統的吞吐量或者響應時間已經無法再提升時，我們稱它是不可擴充套件了。這類系統就是吞吐量是固定的，而響應時間也是相對無法再提升的。

資源過度使用包括了以下幾個：硬體的消耗；過多事務進行表掃描造成IO資源不足；過度的網路佔用；記憶體過度佔用導致交換出現；過多的程式或執行緒配置導致作業系統忙於排程。（簡單說就是CPU消耗多，IO消耗多，網路消耗多，記憶體消耗多，程式太多）

Examples of resource exhaustion include the following:

• Hardware exhaustion

• Table scans in high-volume transactions causing inevitable disk I/O shortages

• Excessive network requests, resulting in network and scheduling bottlenecks

• Memory allocation causing paging and swapping

• Excessive process and thread allocation causing operating system thrashing

This means that application designers must create a design that uses the same resources, regardless of user populations and data volumes, and does not put loads on the system resources beyond their limits.

也就是說應用程式設計人員要開發出一個可以使用相對固定資源的應用程式，當使用者量增加（比如網銀應用，ATM機增加）和資料量增加時，不會導致系統資源的使用超過應有的限制。（在銀行裡通常會監控CPU,記憶體的使用，一般情況下一旦達到90%就開始報警了；幾分鐘內警報無法解除就要開始問責了）

 

2.3.2 System Scalability

Applications that are accessible through the Internet have more complex performance and availability requirements. Some applications are designed and written only for Internet use, but even typical back-office applications—such as a general ledger application—might require some or all data to be available online.

網際網路應用對於可用性有著更高的效能和可用性的要求（12306就是活生生的例子啊）。有些程式只是為了網際網路的應用，但是對於一些商業的如賬務處理程式也要求7*24小時的可用性的。簡單說就是不能當機！工行，建行等ATM機的前置系統當機試試！上交所，深交所當機試試，一會就上報國務院啦！

Characteristics of Internet age applications include the following:  網際網路應用主要包含著下面幾個特點：

• Availability 24 hours a day, 365 days a year                       7*24小時服務

• Unpredictable and imprecise number of concurrent users     不可預測的併發使用者量（天弘基金做餘額寶就是一開始沒預測到吧！網民太給面子了，我算一個了）

• Difficulty in capacity planning              難以預先做好擴容計劃（準備處理1000W使用者的系統如果只有10W人來用，也是浪費錢；反之更慘）

• Availability for any type of query         查詢條件亂七八糟

• Multitier architectures                        多層次的體系架構（這個應該還可以了，weblogic，spring等等架構還是必要的）

• Stateless middleware                        無用的中間層（這個在C架構中容易出現，可能是為了靈活造成不必要的中間層設計）

• Rapid development timescale             開發時間比較短（銀行裡開發更短！）

• Minimal time for testing                     測試時間不夠（網際網路應用有測試嗎？許多程式1天三更新的，不就是說明沒測試就讓我們做小白鼠嘛）

Figure 2-1 illustrates the classic workload growth curve, with demand growing at an increasing rate. Applications must scale with the increase of workload and also when additional hardware is added to support increasing demand. Design errors can cause the implementation to reach its maximum, regardless of additional hardware resources or re-design efforts.

下面的圖說明了一個隨著交易量增加後的一個壓力增長曲線圖。應用程式必須要要靈活的處理突如其來的壓力，要設計成當在增加硬體情況下就可以從容處理。如果設計不善，將無論怎麼增加伺服器配置都已經達到自己效能的瓶頸（吃的再多也跑不過博爾特）。（其實這個只是理論上的，比如說oracle自己的RAC系統很強嗎？不見得吧。但是在增加單伺服器配置時oracle的確很NB，但總會有它的一個峰值的）

Figure 2-1 Workload Growth Curve      壓力增長曲線圖

Applications are challenged by very short development timeframes with limited time for testing and evaluation. However, bad design typically means that you must later rearchitect and reimplement the system. If you deploy an application with known architectural and implementation limitations on the Internet, and if the workload exceeds the anticipated demand, then failure is a real possibility. From a business perspective, poor performance can mean a loss of customers. If Web users do not get a response in seven seconds, then the user's attention could be lost forever.

In many cases, the cost of re-designing a system with the associated downtime costs in migrating to new implementations exceeds the costs of properly building the original system. The moral of the story is simple: design and implement with scalability in mind from the start.

在有限的開發測試時間裡開發出好的系統是非常有挑戰性的。然而糟糕的系統設計通常意味著需要重新設計架構和重新編碼實現。對於網際網路應用而言，當資料量超過了系統能夠承受的壓力，錯誤是總是難免的。從商業角度看，差勁的效能將會導致客戶的流失。如果一個使用者在7秒無法得到響應結果，那麼這個客戶可能永遠也不會登入了。（什麼邏輯啊，你瞧瞧我們銀行業網銀設計的那麼爛，不還得用嘛，客戶算個屌啊，不理解中國國情的表現！呵呵，我個人很看不起那麼銀行的JAVA網銀設計人員，多少年啦，除了浦發等個別銀行能在firefox上使用，其他還是繫結在那個破IE上，對這些開發人員真是無語！你們小小的變更一下CSS,js能死啊！）

 

2.3.3 Factors Preventing Scalability

When building applications, designers and architects should aim for as close to perfect scalability as possible. This is sometimes called linear scalability, where system throughput is directly proportional to the number of CPUs.

In real life, linear scalability is impossible for reasons beyond a designer's control. However, making the application design and implementation as scalable as possible should ensure that current and future performance objectives can be achieved through expansion of hardware components and the evolution of CPU technology.

在設計系統時，架構師應該儘可能地實現可擴充套件性。也就是說達到線性增長的方式，系統的處理能力隨著硬體資源的增加，吞吐量也隨之增加。

在現實生活中，線性擴充套件性架構是由於多種原因無法實現的。但是我們要有理想，有信念，要儘可能在在設計階段就考慮到如果壓力增大時，透過對CPU記憶體增加達到提升系統效能。

（微軟SQL SERVER這個破東西在解決併發方面就是一個反面的例子！一併發就亂加鎖啦，能不能學學Oracle的設計啊！DB2好像也會鎖提升的，只學oracle的DBA絕對不可想像這些系統的！好在銀行的核心繫統除了oracle，DB2是不會用其他的了。informix,sybase逐漸被oracle替代，SQL SERVER是那種可有可無的邊緣專案可能會用，MYSQL這種網際網路應用資料庫，果斷無法應用到金融方面大事務系統上的。我OCM老師說MYSQL主要就是要消滅SQL SERVER的，呵呵）

Factors that may prevent linear scalability include:                                            影響線性擴充套件的因素包括：

• Poor application design, implementation, and configuration                        差勁的應用程式設計、實現、及配置化

  The application has the biggest impact on scalability. For example:             應用程式在擴充套件性方面有非常大的影響，比如：

  • Poor schema design can cause expensive SQL that do not scale.         糟糕的schema設計導致昂貴的SQL處理（你oracle能實現此功能不就可以啦？）

  • Poor transaction design can cause locking and serialization problems.  糟糕的事務處理機制導致鎖和序列化處理

  • Poor connection management can cause poor response times and unreliable systems. 糟糕的連線管理導致響應時間下降和系統不穩定（這個多數不是問題的，因為C是通常長連線的，JAVA是用連線池的）

  However, the design is not the only problem. The physical implementation of the application can be the weak link. For example:

  然而應用程式設計差還不是所有問題的全部。物理配置方面也是薄弱環節。

  • Systems can move to production environments with bad I/O strategies.  糟糕的硬碟配置不正常（通常測試環境配置差，結果生產也按測試一樣配置的結果）

  • The production environment could use different execution plans than those generated in testing. 測試環境與生產環境執行計劃不一樣，這很正常，因為測試環境使用的資料通常都是自己手工造的資料。但是我們應該去分析。同時如果是維護期的話可以使用手續章節講解的內容處理。

  • Memory-intensive applications that allocate a large amount of memory without much thought for freeing the memory at run time can cause excessive memory usage.    應用程式分配了太多的記憶體卻沒有釋放掉。

  • Inefficient memory usage and memory leaks put a high stress on the operating virtual memory subsystem. This impacts performance and availability.                         記憶體太小或者出現記憶體洩漏導致記憶體swap到硬碟上了，這個是影響效能和可用性的。

• Incorrect sizing of hardware components

  Bad capacity planning of all hardware components is becoming less of a problem as relative hardware prices decrease. However, too much capacity can mask scalability problems as the workload is increased on a system.

        糟糕的硬體配置不足已經隨著硬體價格的下降很少成為一個問題了。然而太多的容量有時候會掩蓋系統的一些問題。（比如程式設計的差，但是來了128G記憶體，要很久才能知道有沒有記憶體洩露）

• Limitations of software components            軟體限制

  All software components have scalability and resource usage limitations. This applies to application servers, database servers, and operating systems. Application design should not place demands on the software beyond what it can handle. 所有的軟體都有資源使用的限制。無論是對於應用軟體，資料庫，還是作業系統都是一樣的。應用程式設計應該考慮到這些因素，不要超過他們的能力範圍。（比如oracle讓給它設定processes=10000，作業系統也掛了，何況它呢）

• Limitations of Hardware Components          硬體限制

  Hardware is not perfectly scalable. Most multiprocessor computers can get close to linear scaling with a finite number of CPUs, but after a certain point each additional CPU can increase performance overall, but not proportionately. There might come a time when an additional CPU offers no increase in performance, or even degrades performance. This behavior is very closely linked to the workload and the operating system setup.

  Note:

  These factors are based on Oracle Server Performance group's experience of tuning unscalable systems.

        硬體也不是完美擴充套件的。多處理器在有限的CPU數量內可無限的接近線性擴充套件，但是過於這個點再增加也沒用了，即不是成比例增加的。當過了那個極限以後，再增加CPU已經沒有什麼效能提升，還可能會導致效能下降的。這種行為類似於壓力和作業系統啟動（這個不是很理解啊，CPU多的話，作業系統啟動會變慢，和這個有什麼關係）

這些內容和寫oracle此文章的作者無關。因為他們是根據Oracle Server Performance group's 的一些非擴充套件系統的經驗而編注的。

也和我無關，英語不是我母語，只能這麼翻譯。

 

2.4 System Architecture

There are two main parts to a system's architecture:

• Hardware and Software Components

• Configuring the Right System Architecture for Your Requirements

2.4.1 Hardware and Software Components

This section discusses:

• Hardware Components

• Software Components

2.4.1.1 Hardware Components

Today's designers and architects are responsible for sizing and capacity planning of hardware at each tier in a multitier environment. It is the architect's responsibility to achieve a balanced design. This is analogous to a bridge designer who must consider all the various payload and structural requirements for the bridge. A bridge is only as strong as its weakest component. As a result, a bridge is designed in balance, such that all components reach their design limits simultaneously.

現在的設計人員和架構師是有責任去規劃硬體的規格，或者說提出最少的硬體要求。這是一個架構師要實現一個平衡設計的要求。這個和一個橋樑設計是類似的，工程師要考慮各種部件的負荷，但是你只給他磚頭不給水泥他達不到工程師建造的要求的。這個橋樑到底有多結實，是看他最薄弱處有多結實的。因此在資金一定的情況下，設計人員要考慮各種情況去平衡各個部件，以使其達到最大可靠性。

簡單說就是架構師要提出自己的要求，需要多少CPU,多少記憶體，多少硬碟。這個在系統需求分析完之後就會提一個文件給運維組，由他們去採購的。如果無法達到要求的話，就需要回頭趕緊修改自己的架構。多數情況下銀行還是可以給滿足的，但是對於一個老的系統，如果要進行功能或效能升級的話，就要在現有的伺服器上進行。或者是當一個伺服器最大隻支援16G記憶體的時候想增加再多的記憶體，那隻能等下一批機器採購的時候才能考慮是否能給專案組使用。所以有時候看起來很簡單的一個升級卻要拖一年，很大一部分原因就在這裡----硬體不太位。

The main hardware components include:

• CPU

• Memory

• I/O Subsystem

• Network

2.4.1.1.1 CPU

There can be one or more CPUs, and they can vary in processing power from simple CPUs found in hand-held devices to high-powered server CPUs. Sizing of other hardware components is usually a multiple of the CPUs on the system. See Chapter 9, "Managing Operating System Resources".

從個人用的低效的單核到伺服器的高效能多核處理器，他們效能差距是很大的。其他的一些硬體容量通常是CPU的好幾倍。

2.4.1.1.2 Memory

Database and application servers require considerable amounts of memory to cache data and avoid time-consuming disk access. See Chapter 7, "Configuring and Using Memory".

資料庫和應用伺服器需要足夠的記憶體去快取資料，以避免太多的硬碟訪問。

2.4.1.1.3 I/O Subsystem

The I/O subsystem can vary between the hard disk on a client PC and high performance disk arrays. Disk arrays can perform thousands of I/Os each second and provide availability through redundancy in terms of multiple I/O paths and hot pluggable mirrored disks. See Chapter 8, "I/O Configuration and Design".

IO子系統在個人電腦和伺服器上差別是非常大的。伺服器上的磁碟組可以達到幾千個的IOPS（SSD都是幾萬幾十萬了），以及提供了可以熱插拔和多路冗餘功能（不是你想像的那種幾分鐘的熱插啊拔啊的運動，不過也差不多了）。

2.4.1.1.4 Network

All computers in a system are connected to a network, from a modem line to a high speed internal LAN. The primary concerns with network specifications are bandwidth (volume) and latency (speed).

所有伺服器都要連線到網路上，從簡單的電話線到高速的內網（通常是光纖或者是華爾街的微波傳輸，我請教過一個物理研究生朋友，他說微波會比光纖快30%左右）。在網路中我們主要關注網路頻寬和網路延遲兩個指標。（對於光纖而言，每秒鐘幾G到幾百G可以理解，但是這個延遲的指標我目前也不清楚生產上大概會達到多少毫秒或者微秒）

2.4.1.2 Software Components

The same way computers have common hardware components, applications have common functional components. By dividing software development into functional components, it is possible to better comprehend the application design and architecture. Some components of the system are performed by existing software bought to accelerate application implementation, or to avoid re-development of common components.

The difference between software components and hardware components is that while hardware components only perform one task, a piece of software can perform the roles of various software components. For example, a disk drive only stores and retrieves data, but a client program can manage the user interface and perform business logic.

與硬體方面的限制類似，軟體也有自己設計功能上的限制。將軟體的功能劃分開來，會更好的理解這個系統的架構設計。有些系統模組，是根據現有的一些已經實現的功能中組裝起來的，避免重新發明輪子。（比如已經有開源的linux,就沒必要再自己寫個作業系統了；oracle大量的使用了開源的軟體，比如perl,glibc,libaio,sysstat,odbc等等我們安裝時要求的軟體，這些都是避免再重寫一套的案例）

軟硬體的區別在於硬體模組只執行一個任務，在各種軟體模組中一部分軟體就可實現此功能（這個地方翻譯不準確，被繞進去了，可以不用看這段，講的一點不生動活潑！）。例如磁碟驅動程式只負責存取資料，但是一個客戶端應用程式要管理使用者的介面錄入，業務邏輯處理等等。

Most applications involve the following components:  多數的系統都會實現以下的功能

• Managing the User Interface                                使用者介面管理（這個通常是JAVA做的）

• Implementing Business Logic                               業務邏輯處理（這個通常是C做的）

• Managing User Requests and Resource Allocation  管理使用者請求和資源分配（網銀的話是由JAVA處理或是weblogic吧，其他的多數是由C處理）

• Managing Data and Transactions                         資料管理和事務處理（基於上都是C來做的，儲存過程也可以的）

2.4.1.2.1 Managing the User Interface

This component is the most visible to application users, and includes the following functions: 對使用者可用的模組透過包含下面的功能：

• Displaying the screen to the user                                        一個漂亮的顯示介面，不像sqlplus黑不拉嘰的

• Collecting user data and transferring it to business logic        收集使用者錄入的資料，然後對其進行加工處理

• Validating data entry                                                          驗證使用者的資料合法性

• Navigating through levels or states of the application             根據級別或身份做不同的應用導航，簡單說就是不同人看到的東西是不一樣的

       在銀行業裡，JAVA主要是負責使用者錄入，驗證資料及展示一些報表，他們是為後面賬務核心系統（C語言處理）做預處理。更簡單的說就是JAVA將錄入的配置資訊插入或更新到表中，同時要保證資料正確，這樣賬務系統才能正常運轉。比如一個人最大的年齡是150歲，結果匯入了一個15000的資料進來，這樣是不行的，必須要由JAVA去判斷一下年齡是否符合業務要求；到了核心系統，就僅僅看這個錄入的100歲的人有沒有能力去貸款，要給他放貸的話最高額度可能是100塊等等。通常情況下核心系統要求的人員非常少，一般1到5個人就差不多了夠，JAVA人員通常會佔用10到幾十個，每天給客戶畫介面。

2.4.1.2.2 Implementing Business Logic

This component implements core business rules that are central to the application function. Errors made in this component can be very costly to repair. This component is implemented by a mixture of declarative and procedural approaches. An example of a declarative activity is defining unique and foreign keys. An example of procedure-based logic is implementing a discounting strategy.

應用實現的核心就是那些處理核心功能的模組。一旦這些核心模組出現錯誤就要趕緊去修復，就像看到alert日誌中出錯一樣。這些模組的實現通常是declarative and procedural 共同實現的。具個例子就是：declarative 就是定義唯一索引和外來鍵。procedure-based logic 就是實現打折銷售策略。（這兩個詞語還沒有好的翻譯方式；或許他的意思是一個是搞技術的去做，一個是搞業務的去做，兩個人共同配置以達到需要的效果？）

Common functions of this component include:

• Moving a data model to a relational table structure         將資料模型遷移到關聯式資料庫上（比如以前的網狀結構資料庫或者將EXCEL表格資料）

• Defining constraints in the relational table structure        在資料結構（表）上定義約束（這個多數不用，因為很多語法在不同資料庫上不好遷移）

• Coding procedural logic to implement business rules       編寫程式邏輯去實現業務需求

2.4.1.2.3 Managing User Requests and Resource Allocation

This component is implemented in all pieces of software. However, there are some requests and resources that can be influenced by the application design and some that cannot.

In a multiuser application, most resource allocation by user requests are handled by the database server or the operating system. However, in a large application where the number of users and their usage pattern is unknown or growing rapidly, the system architect must be proactive to ensure that no single software component becomes overloaded and unstable.

這種模組通常是在所有的程式上都會有的。然而有些要求和資源會對應用程式的設計造成影響，而有的則不會。

在一個多使用者的環境中，多數處理使用者請求的資源分配是由資料庫和作業系統做的。然而在一些大的應用系統中，使用者的數量和使用方式是未知的，或者增長非常快的，這種系統架構的設計就要前瞻性的確保任何一個模組都不能出現大的問題，即應對大的衝擊。

Common functions of this component include:

• Connection management with the database                                     與資料庫的連線管理（如dedicade,shared,mixed）

• Executing SQL efficiently (cursors and SQL sharing)                         SQL執行的效率

• Managing client state information                                                   客戶端狀態資訊管理

• Balancing the load of user requests across hardware resources         根據硬體資源來平衡使用者的業務請求（如VIP單獨給一臺機器處理）

• Setting operational targets for hardware and software components   配置軟硬體的資源使用

• Persistent queuing for asynchronous execution of tasks                   非同步執行任務的持久排除

2.4.1.2.4 Managing Data and Transactions

This component is largely the responsibility of the database server and the operating system. 這個模組是資料庫和作業系統的職責

Common functions of this component include:

• Providing concurrent access to data using locks and transactional semantics 透過鎖和事務原語對併發資料進行訪問管理

• Providing optimized access to the data using indexes and memory cache      使用index和快取提供最佳的資料訪問方式

• Ensuring that data changes are logged in the event of a hardware failure      確保在當機時資料已經做了記錄

• Enforcing any rules defined for the data                                                    確保資料的定義規則

2.4.2 Configuring the Right System Architecture for Your Requirements

Configuring the initial system architecture is a largely iterative process. System architects must satisfy the system requirements within budget and schedule constraints. If the system requires interactive users transacting business-making decisions based on the contents of a database, then user requirements drive the architecture. If there are few interactive users on the system, then the architecture is process-driven.

設計一個系統的架構是一個迭代的過程（也就是說不可能一次性設計好就完了，是需要不斷進行調整的，或者是業務量上升或者響應時間要求提高等等）。系統架構師需要在計劃時間及預算內設計出滿足系統要求的功能。假如一個系統需要根據資料庫中的內容處理互動式的使用者請求，那麼這個系統設計時就是由使用者的要求驅動的。假如互動的使用者比如少，那麼這個系統就是功能驅動的。（個人理解：像淘寶之類的就是使用者驅動的，它要考慮使用者的數量，查詢的條件等等；而銀行的賬務系統很少需要人去幹預的，這類系統就是業務功能驅動的）

Examples of interactive user applications:         使用者互動類的系統

• Accounting and bookkeeping applications  會計賬務系統（會計人員要登入上去做查詢或賬務錄入）

• Order entry systems                               訂單處理系統

• Email servers                                         郵件服務

• Web-based retail applications                  淘寶零售

• Trading systems                                    交易系統

Examples of process-driven applications:         應用（程式，業務）驅動的系統

• Utility billing systems                              賬務處理系統

• Fraud detection systems                        欺詐系統（或者是風險管理系統）

• Direct mail                                            直接的郵件處理系統

In many ways, process-driven applications are easier to design than multiuser applications because the user interface element is eliminated. However, because the objectives are process-oriented, system architects not accustomed to dealing with large data volumes and different success factors can become confused. Process-driven applications draw from the skills sets used in both user-based applications and data warehousing. Therefore, this book focuses on evolving system architectures for interactive users.

許多情況下，業務驅動系統要比多使用者應用開發要相對容易些，因為他們不需要處理使用者的介面請求。同時因為由業務驅動的方式，使得系統架構師不習慣於處理大資料量以及不同的成功歷史因素使得他們變得混亂，神智不清（說的可能是以前的設計經驗在這種新的系統上已經不適合了，或者說的就是我了）。業務驅動系統從基於使用者的應用程式和資料倉儲的技術經驗中獲得。因此本書聚焦於涉及到使用者互動的體系架構（直接講最難的啦）。

Note:

Generating a system architecture is not a deterministic process. It requires careful consideration of business requirements, technology choices, existing infrastructure and systems, and actual physical resources, such as budget and manpower.

The following questions should stimulate thought on system architecture, though they are not a definitive guide to system architecture. These questions demonstrate how business requirements can influence the architecture, ease of implementation, and overall performance and availability of a system. For example:

設計一個系統架構不是一個一成不變的過程（不確定的過程）。因為需要考慮到許多因素如：業務的需求，技術架構的選擇，公司已經存在的基礎架構或者說是程式碼庫，實際的系統限制或專案預算、團隊人員素質（開發人員的能力）等等的物理資源限制。---給的錢的少，團隊差，時間緊，公司程式碼差，這些全都體現在我們國內的企業上了。設計一個好的產品，難！有多難？難於上青天啊！所以作為一個二流的架構師，如果有人再說我設計的差，那先多給點錢吧（我再去請個好的來設計，再招些好的開發人員，這總可以了吧）

下面的這些問題應該在系統架構設計時仔細的思考，儘管他們不是一個明確的指導手冊。這些問題決定了一個業務系統怎麼影響架構的設計，降低程式的實現的難度，以及總體的系統可用性及高效性。（下面具的例子一般是在需求分析階段都要去考慮的，否則沒有辦法設計的）例如：

• How many users must the system support?             -----> 你的破系統，破業務到底要支援多少使用者訪問？

  Most applications fall into one of the following categories:     多數的系統基於上基於以下3個考慮：

  • Very few users on a lightly-used or exclusive computer                                  只有很少的使用者在一個獨有的或者壓力比較小的系統上執行

    For this type of application, there is usually one user. The focus of the application design is to make the single user as productive as possible by providing good response time, yet make the application require minimal administration. Users of these applications rarely interfere with each other and have minimal resource conflicts.   這種系統通常只有一個使用者在使用。設計的目標是給這個哥們提供儘可以快的響應時間，因此這種應用很少需要去管理。這種應用程式很少需要和其他使用者進行打交道。（說的可能是我的蜘蛛紙牌程式不需要和其他人的蜘蛛紙牌溝通了吧）

  • A medium to large number of users in a corporation using shared applications  在一箇中等的公司內部大家共用一些資源

    For this type of application, the users are limited by the number of employees in the corporation actually transacting business through the system. Therefore, the number of users is predictable. However, delivering a reliable service is crucial to the business. The users must share a resource, so design efforts must address response time under heavy system load, escalation of resource for each session usage, and room for future growth.對於這類應用程式，使用者數是由在公司內部的，實際透過此係統進行交易處理的員工數決定的（比如公司報銷時，可能同一時間就那2%左右的員工會同時登入系統進行報銷錄入）。因此使用者數是可以預測的。然而這類系統需要一個非常健壯的服務功能。許多使用者共享一個資源，那麼設計的原則就是要在大負荷下能提供儘可能快的響應時間，增加資源以滿足未來增加的員工。（我們公司那個破財務系統，是由2個2年工作經驗的人寫的，還只是支援IE,我都告訴他們去修改一點點CSS就可以用的情況下他們也不改，實在是不好意思在辦公室罵人，特別是人家不是我們部門的，更不好去當著人家領導的面批評他們了）

  • An infinite user population distributed on the Internet                                    網際網路上不確定的使用者資料（網遊，淘寶等）

    For this type of application, extra engineering effort is required to ensure that no system component exceeds its design limits. This creates a bottleneck that halts or destabilizes the system. These applications require complex load balancing, stateless application servers, and efficient database connection management. In addition, use statistics and governors to ensure that the user receives feedback if the database cannot satisfy their requests because of system overload.對於這類系統，額外的一些工作就是要確保系統中沒有某一個模組是超負荷動作。這樣就產生了一個瓶頸。這些應用程式需要更加複雜的壓力測試（國內一般用loadrunner來壓的），無狀態的應用服務（這個不清楚啊），和有效的資料庫連線（一般weblogic都幫應用開發人員處理了）。另外，要使用統計資料和協調部件確保，在資料庫超負荷壓力下無法滿足客戶請求時給使用者一些反饋資訊。（就像404網頁無法開啟錯誤一樣，給點安慰的資訊）

• What will be the user interaction method?   使用者需要以什麼樣的方式和系統互動？在基於B/S的瀏覽器方式還是基於傳統的windows視窗程式（客戶應用程式）？

  The choices of user interface range from a simple Web browser to a custom client program.

• Where are the users located?  使用者分佈在哪裡？使用者的分佈決定了網路的延遲處理設計。同時也影響一天業務高峰區間，影響批次或維護時間的確定。

  The distance between users influences how the application is engineered to cope with network latencies. The location also affects which times of the day are busy, when it is impossible to perform batch or system maintenance functions.

• What is the network speed?  網路的速度？速度決定了傳輸的方式。高度靈敏的使用者介面可以應對任何的衝擊；否則就需要傳送等待模型處理。在慢網路中不可能去實現大資料傳輸的同時滿足客戶的通訊體驗。

  Network speed affects the amount of data and the conversational nature of the user interface with the application and database servers. A highly conversational user interface can communicate with back-end servers on every key stroke or field level validation. A less conversational interface works on a screen-sent and a screen-received model. On a slow network, it is impossible to achieve high data entry speeds with a highly conversational user interface.

• How much data will the user access, and how much of that data is largely read only?  需要處理多少使用者資料，多少資料是隻讀的？查詢的方式會很大的影響系統的設計，包括表建立方式及索引的建立。必須要確保資料庫的響應時間不是一個問題。假如系統主要是讀取一些資料的話，那麼將資料快取到應用程式服務端就是一個好的方案。這也減少了核心事務處理的壓力。（我們在設計系統時，這方面很多時候處理的相對是過度的，也就是說都儘可能的去快取，要麼快取到共享記憶體中，或者自己的程式內，儘可能地去麻煩資料庫，因為資料庫是要處理多使用者多併發的，因此實現一個單使用者多併發是效率非常高的。由於現在資料庫伺服器效能越來越強勁，所以有些系統又把這些快取放回到資料庫端，不再做這些功能的編寫。當然oracle是建議我們這麼做的）

  The amount of data queried online influences all aspects of the design, from table and index design to the presentation layers. Design efforts must ensure that user response time is not a function of the size of the database. If the application is largely read only, then replication and data distribution to local caches in the application servers become a viable option. This also reduces workload on the core transactional server.

• What is the user response time requirement?                                                         需要提供的一個使用者響應時間是多少？

  Consideration of the user type is important. If the user is an executive who requires accurate information to make split second decisions, then user response time cannot be compromised. Other types of users, such as users performing data entry activities, might not need such a high level of performance.  不同使用者需求是不一樣的。如果一個公司高官，他需要一個準確的資訊以制定計劃，那麼就不能以提供響應時間上的妥協。另外一些使用者，例如主要做一些資料的錄入工作，那就不需要太高的效能。

• Do users expect 24 hour service?                                                                          是否需要7*24小時的服務？

  This is mandatory for today's Internet applications where trade is conducted 24 hours a day. However, corporate systems that run in a single time zone might be able to tolerate after-hours downtime. You can use this after-hours downtime to run batch processes or to perform system administration. In this case, it might be more economic not to run a fully-available system.

• Must all changes be made in real time?                                                                   是否需要實時的處理？

  It is important to determine whether transactions must be executed within the user response time, or if they can be queued for asynchronous execution.

        簡單概括一下就是設計時考慮一下：系統有多少人會訪問，以什麼方式訪問，對網路要求有多高， 一天的交易量大概有多少，TPS要求多高，系統是否需要7*24時執行。

The following are secondary questions, which can also influence the design, but really have more impact on budget and ease of implementation. For example:

下面的一些問題是次要的問題，它也一樣決定了如何去設計，但是主要是專案預算及簡易實現方面的。例如：

• How big will the database be?                                                    需要多大的資料庫？

  This influences the sizing of the database server. On servers with a very large database, it might be necessary to have a bigger computer than dictated by the workload. This is because the administration overhead with large databases is largely a function of the database size. As tables and indexes grow, it takes proportionately more CPUs to allow table reorganizations and index builds to complete in an acceptable time limit.

• What is the required throughput of business transactions?          業務處理的最大吞吐量是多少？

• What are the availability requirements?                                       可靠性要求是什麼？ （是否要做DG）

• Do skills exist to build and administer this application?                  開發人員的能力是否能夠滿足目前的專案開發？（銀行裡很多是由剛畢業的大學生做的）

• What compromises are forced by budget constraints?                  在專案預算是有多少可以協商的餘地？（一般沒得商量）