转载微信公众平台.

 <xml>
 <ToUserName><![CDATA[toUser]]></ToUserName>
 <FromUserName><![CDATA[fromUser]]></FromUserName>
 <CreateTime>1348831860</CreateTime>
 <MsgType><![CDATA]></MsgType>
 <Content><![CDATA[this is a test]]></Content>
 </xml>

 ToUserName 消息接收方微信号，一般为公众平台账号微信号
 FromUserName 消息发送方微信号
 CreateTime 消息创建时间
 MsgType 文本消息为text
 Content 消息内容

 <xml>
 <ToUserName><![CDATA[toUser]]></ToUserName>
 <FromUserName><![CDATA[fromUser]]></FromUserName>
 <CreateTime>1351776360</CreateTime>
 <MsgType><![CDATA[location]]></MsgType>
 <Location_X>23.134521</Location_X>
 <Location_Y>113.358803</Location_Y>
 <Scale>20</Scale>
 <Label><![CDATA[位置信息]]></Label>
 </xml>

 ToUserName 消息接收方微信号，一般为公众平台账号微信号
 FromUserName 消息发送方微信号
 CreateTime 消息创建时间
 MsgType 消息类型，地理位置为location
 Location_X 地理位置纬度
 Location_Y 地理位置经度
 Scale 地图缩放大小
 Label 地理位置信息

 <xml>
 <ToUserName><![CDATA[toUser]]></ToUserName>
 <FromUserName><![CDATA[fromUser]]></FromUserName>
 <CreateTime>1348831860</CreateTime>
 <MsgType><![CDATA[image]]></MsgType>
 <PicUrl><![CDATA[this is a url]></PicUrl>
 </xml>

 ToUserName 消息接收方微信号，一般为公众平台账号微信号
 FromUserName 消息发送方微信号
 CreateTime 消息创建时间
 MsgType 消息类型image
 PicUrl 图片链接，开发者可以用HTTP GET获取

 <xml>
 <ToUserName><![CDATA[toUser]]></ToUserName>
 <FromUserName><![CDATA[fromUser]]></FromUserName>
 <CreateTime>12345678</CreateTime>
 <MsgType><![CDATA]></MsgType>
 <Content><![CDATA[content]]></Content>
 <FuncFlag>0</FuncFlag>
 </xml>

 FromUserName 消息发送方
 ToUserName 消息接收方
 CreateTime 消息创建时间
 MsgType 消息类型，文本消息必须填写text
 Content 消息内容，大小限制在2048字节，字段为空为不合法请求

 <xml>
 <ToUserName><![CDATA[toUser]]></ToUserName>
 <FromUserName><![CDATA[fromUser]]></FromUserName>
 <CreateTime>12345678</CreateTime>
 <MsgType><![CDATA[news]]></MsgType>
 <Content><![CDATA[]]></Content>
 <ArticleCount>2</ArticleCount>
 <Articles>
 <item>
 <Title><![CDATA[title1]]></Title>
 <Description><![CDATA[description1]]></Description>
 <PicUrl><![CDATA[picurl]]></PicUrl>
 <Url><![CDATA[url]]></Url>
 </item>
 <item>
 <Title><![CDATA[title]]></Title>
 <Description><![CDATA[description]]></Description>
 <PicUrl><![CDATA[picurl]]></PicUrl>
 <Url><![CDATA[url]]></Url>
 </item>
 </Articles>
 <FuncFlag>1</FuncFlag>
 </xml>

 FromUserName 消息发送方
 ToUserName 消息接收方
 CreateTime 消息创建时间
 MsgType 消息类型，图文消息必须填写news
 Content 消息内容，图文消息可填空
 ArticleCount 图文消息个数，限制为10条以内
 Articles 多条图文消息信息，默认第一个item为大图
 Title 图文消息标题
 Description 图文消息描述
 PicUrl 图片链接，支持JPG、PNG格式，较好的效果为大图640*320，小图80*80，限制图片链接的域名需要与开发者填写的基本资料中的Url一致
 Url 点击图文消息跳转链接

[转载]Fiddler Composer创建和发送HTTP Request – 小坦克 – 博客园.

之前已经写过两篇Fiddler的文章了，分别是【Fiddler教程】 【Fiddler script用法】。  我准备把Fiddler写成一个系列。

Fiddler的功能还有很多， 很多功能都没有被挖掘出来。这次我们介绍Fiddler中的一个非常有用的功能Composer，是用来创建和发送HTTP Request的。Composer的使用方法很简单，看下就知道用了。

阅读目录

1. Fiddler Composer介绍
2. Fiddler Composer比其他工具的优势
3. 实例：模拟京东商城的登录
4. Parsed和Raw两种编辑模式
5. 同类工具 – Firefox插件 Rest Client
6. 同类工具Linux上的Curl

Fiddler Composer介绍

Composer的官方帮助文档：http://www.fiddler2.com/fiddler/help/composer.asp

Fiddler的作者把HTTP Request发射器取名叫Composer(中文意思是：乐曲的创造者), 很有诗意

Fiddler Composer的功能就是用来创建HTTP Request 然后发送。 你可以自定义一个Request, 也可以手写一个Request, 你甚至可以在Web会话列表中拖拽一个已有的Request. 来创建一个新的HTTP Request.

Fiddler Composer比其他工具的优势

能创建发送HTTP Request的工具很多很多。 但是Fiddler的功能有如下的优势。

1. 能从”Web会话列表”中 拖拽一个先前捕获到的Request, 然后稍微修改一下

2. 发送Request后，还能设置断点，继续修改Request.

3. 支持在Request中上传文件

4. 支持发送多次Request.

实例: 模拟京东商城的登录

启动Fiddler, 启动IE, 打开京东，然后输入用户名和密码，登录。   Fiddler 将捕获到这个登录的Request.

1. 首先找出哪个Request 是用来登录的， 然后把它拖拽到Composer中。

[用来登录的request是这个: https://passport.360buy.com/uc/loginService?uuid=6bc79fbf-e882-49bb-b63a-6fd6ee448944]

2. 在Composer可以看到， 登录是使用POST方法， 把用户名和密码发送给服务器。 那么我们可以修改Composer中的request内容， 比如用户名为:fiddlertest@fiddler.com,密码为test1234。

3. Request造好了后， 我们按”Execute” 按钮就可以发送Request了(如果按住Shift键的同时，按”Execute”. Fiddler会自动给这个Request下断点)。

4. 发送的Request，将出现在左边的Web Session列表中。

Parsed和Raw两种编辑模式

Fiddler Composer有两种编辑模式

Parsed模式(最常用),  把Request分为三个部分， Request line, Request Headesr,  Request Body。  很容易创建一个Request.

Raw模式，需要你一行一行手动写一个Request。

同类工具- Firefox插件Rest Client

Firefox也有一个插件叫Rest Client，  使用起来也很方便

同类工具: Linux上的Curl

curl是个命令行工具， 功能也很强大

[转载]我的架构经验系列文章 – 后端架构 – 架构层面 – lovecindywang – 博客园.

回到索引 http://www.cnblogs.com/lovecindywang/archive/2012/12/23/2829828.html

架构层面：

• 日志集中

所谓日志集中就是把程序的所有日志和异常信息的记录都汇总到一起，在只有一台服务器的时候我们记录本地文件问题也不是最大，但是在负载均衡环境下再 记录本地日志的话就出现问题了。在想查看网站日志的时候到哪台机器去查都不知道，难道有100台机器就100台机器逐一远程连上去看？因此，把这些数据汇 总在一起保存对于大型网站系统来说是很必要的，这样我们就可以直接进行查看、搜索，也很明确可以知道是哪台机器的业务出了问题。至于这种日志数据是写到 RDBMS还是NOSQL甚至是搜索引擎这就看需要了，总之避免写本地的文本文件，否则真的是灾难。当然写一个日志远远没有想的这么简单：

1. 为了达到比较好的性能，日志是否先写本地内存队列然后定时刷到数据库中去？
2. 各种日志混在一起也难以搜索，是否要添加一些搜索字段？比如分模块？
3. 如果数据库不可用的话是不是先写本地日志以后再汇总过去？
4. 日志是否易于辨明问题还是看日志怎么记录，如果日志中只写错误那么记录了也白记录，一定要写清楚这是哪个模块哪里出现了问题，有条件的话还可以写上一些参数信息和当前的状态。
5. 对于未处理的异常信息不太可能手动去记录，一般而言很多框架或服务器都会提供一个接口点可以回调我们自己的代码，在这里我们就可以收集这些未处理 异常然后统一记录，最后把用户带到友好的错误页面。不记录任何一个未处理异常都是可怕的事情，想象一下用户已经看到了色彩斑斓的页面，而开发还一无所知， 这样的话这个问题始终会存在，即使用户投诉了反馈了我们也很难重现。

• 配置集中

配置集中和日志集中的道理是一样的，就是统一管理。任何一个系统其实或多或少都会有一些不能在程序中写死的参数（比如至少的数据库连接字符串和外部 服务地址），一般情况下会写到配置文件中，这样存在几个问题，第一就是在多服务器的负载集群情况下要修改配置需要逐一修改每一台服务器的配置，第二就是在 修改配置还可以需要重启服务或网站才会生效，第三无法统一管理也无法知道是否所有网站都统一配置了相同参数。解决的办法还是一样的就是汇总保存在统一的地 方比如保存在数据库中，然后每一个网站都从数据库中获取配置的值，在实现的时候简单有简单的做法，复杂有复杂的做法，比如要考虑以下问题：

1. 参数的值是直接保存强类型的那还是保存字符串在使用的时候转？甚至说值是支持对象和数组的，而不是简单类型。
2. 参数的值不可能每一次获取都从数据库取，怎么做缓存，缓存多长时间，值修改了怎么同步回来？
3. 程序是否允许修改值？还是说程序只是读取，不允许修改，修改参数的值只能通过数据库或后台进行。
4. 是否是需要根据不同的部署环境、用户的语言、服务器的IP来设置不同的值。

不管怎么样，至少一个最简单的配置服务，从数据库中读取参数值，哪怕读取后永远缓存只有重启服务才能生效，也会比直接从本地配置文件中读要好很多。

• 缓存

缓存这个架构手段实在是太常用了，几乎所有的人都知道缓存这个设计和性能优化手段。对于一个网站系统来说又有太多的地方可以做缓存，真正能把缓存用 好，在合理的地方用缓存，监控缓存的命中率，想办法提高缓存的命中率其实不是这么容易的，一般来说有这些地方可以做缓存，从上到下：

1. 浏览器和CDN缓存：通过这两种整页的缓存可以尽量减少请求打到网站服务器的机会，也就提高了网站服务器的负载能力，当然一般来说静态的资源比较 容易走这种缓存，动态的资源其实也可以走，只不过要能根据访问的条件做出合适的Key，对于和每一个用户都独立的页面可能要直接进行页面缓存比较难一点。
2. 反向代理的缓存：反向代理作为服务器的代理可以进行整页或是片段页面的缓存，可以提高直接把请求达到网站服务器的机会提高性能。
3. 数据的缓存：如果请求真正到了网站服务器，那么我们也不一定要所有的数据都从数据库中取，可以尝试把部分数据保存在分布式缓存中。只要Key合理，并且请求有规律那么可以保证比较高的命中率，从而减轻数据库的压力，也减轻网站服务器的压力。
4. 大块数据的内存中缓存：对于有一些大块的数据是无法保存在分布式缓存中的，那么可以直接在网站启动的时候把这种不太会改变的大块数据全部加到内存中来，这样这快数据的访问效率和计算效率就很高了。

对于缓存的更多内容可以参考我之前做的一个分享：http://www.cnblogs.com/lovecindywang/archive/2010/07/19/1780589.html

• 分布式缓存

所谓分布式缓存就是缓存的数据是分布在多个节点上的，好处是一来可以尽量利用服务器的资源，比如一台服务器可以有1GB内存空闲，找50台服务器就 是50GB了，如果不用这50台服务器其实也就是这么多内存空着（一般来说网站服务器使用的内存是相对固定的，主要业务不怎么变化的话，而且诸如 Memcached之类分布式缓存对CPU的使用是很低的，完全可以把Memcached寄居在大内存的Web服务器或是应用服务器上，实现神不知鬼不觉 的分布式缓存）；第二个好处就是可以减少单点故障带来的影响，一般来说分布式缓存都有类似于一致性哈希的算法，即使有单点故障的话也只是少部分缓存数据会 不命中，损失不是太大。在使用分布式缓存的时候要牢记下面几点：

1. 缓存就是缓存，数据是允许排出和丢失的，当成文件系统用的话就错了。
2. 分布式缓存的数据是通过网络存取的，数据传输走网络和本机内存中效率不能比，而且数据需要序列化和反序列化要考虑到性能开销。
3. 缓存的Key生成的策略是很关键的，Key生成的参数过多的话很可能命中率会几乎为0，这种缓存做了也白做，因此需要针对分布式缓存的命中率有监控。

• 队列

队列也是实现高性能架构的一个必不可少的利器，通过把执行时间比较长的任务在队列中进行排队，通过限制队列的最大容纳项目数，实现一个抗高压的能 力，并且队列后端的点也能有一个比较平稳的压力。队列说到底也只是一个容器，如果前端的压力永远比后端处理能力大的话，队列总是要爆的，因此队列也不是万 能。往往对于网站系统即使后端的业务有队列，前端的页面如果扛不住高压力，甚至是验证码之类的都刷不出来的话也是没用的，架构上就是这样系统中任何一个点 都会拖累整站的架构，架构优化针对最薄弱的地方而不是最强的地方。形式上来说队列有两种：

1. 生产者和消费者：生产者生产出来的数据只能被一个消费者消费，也就是任务只能执行一次的。往往这种形式的数据是需要持久化的。
2. 发布和订阅：任何一个事件都允许有多个发布者和多个订阅者，订阅者订阅自己感兴趣的东西，只要发布者发布了订阅者感兴趣的内容就会传播到所有的订阅者。一般来说这种形式的数据可以是允许丢失的不需要持久化的。

• 池技术

所谓的数据库连接池，线程池都是池技术的一个应用。池技术说到底就是把创建开销比较大的对象缓存在池中避免重复创建和销毁，对象用的时候从池拿出来 用，用好了重置后还到池里面别人还可以接着用。比如说数据库连接池就是避免了频繁创建代价高的TCP连接，线程池就是避免了频繁创建代价高的线程。虽然说 原理上是这样，但池其实也有一些算法需要考虑的：

1. 创建的富裕的对象的回收策略怎么做？
2. 对象损坏怎么处理？

一般来说可以参考网上的池实现方式来实现一个通用的池，这样各种对象都可以进行管理了。

• 分布式文件系统

分布式文件系统并不是所有网站都必须的，一般小网站会把用户上传的图片直接保存在Web服务器本地，这么做是可以的，但量大了之后会有问题，首先一 台服务器保存不下怎么办，怎么知道哪个图片在哪个服务器上？其次读的请求怎么进行分离，怎么把图片同步到其它服务器上去。分布式文件系统就是来解决这个问 题的，通过把一组服务器当做一个文件系统使得我们的文件资源可以分散保存在多个服务器上并且确保有一定的数据备份。在网站规模不是很大的时候其实可以保存 在单台服务器上，然后使用文件同步工具同步到另一台服务器，之前再架反向代理解决，数据量再大一定要分布式的话就要上分布式文件系统了。从原理上来说分布 式文件系统其实不是很复杂的，但选型的时候也要进行稳定性和性能的考量。有的人是把数据库保存在数据库中的，虽然这样可以实现单点虽然这样可以实现备份， 但这显然不是很合理的，会极大增加数据库的压力。

• 分布式搜索引擎

如果有站内搜索需求的话就要上搜索引擎了，现在开源的搜索引擎非常多，不过很多都是Lucene的封装，在选型的时候要根据自己的需求进行选型。所 谓分布式也就是如果单点的索引和查询不能满足性能容量需求的话就需要分布到多点了。从原理上来说搜索引擎主要还是一个分词和倒排索引，但是搜索引擎在内容 的排序等细节上点还是有很多算法的，除非必要不推荐自己去实现搜索引擎，可以直接针对开源组件进行封装和改良。搜索引擎做的好其实远远不止全文搜索这么简 单，甚至可以根据用户搜索的内容给予搜索的建议，可以根据用户搜索的内容进行索引的自完善，还可以根据用户的搜索结果进行大量的用户行为分析，为网站的产 品进行改良，如果站点具有自己的搜索模块的话其实有很多事情可以做的。

• NOSQL

NOSQL就是非关系型的数据库，NOSQL不是用来取代关系型数据库的，之所以NOSQL这么火是因为其性能。从本质上来说，程序就是一组代码， 对于相同的硬件配置来说，程序性能的高低也就取决于实现相同的操作要有多少代码在CPU中执行一遍，要有多少IO操作要在磁盘上过一遍，往往通用性的东西 就会有比较多的计算和IO，往往定制化的东西性能就会比较高。我们说RDBMS性能不高，但是我们也应该看到RDBMS要确保数据的完整性，持久性，要实 现通用的功能，要把它的性能和IO达到内存中然后定期刷磁盘的组件来比就不合理了，因此我们要根据业务在合理的地方使用合理的NOSQL，对于资金相关的 业务需要事务的业务不太适合NOSQL，对于允许延迟允许数据丢失需要大访问量的业务比较适合NOSQL。任何一种NOSQL往往都是某个大型公司针对自 己的需要定制出来的产品，只有这样定制化的东西才可能实现高性能，因此市面上才会有这么多NOSQL，那么我们在选择的时候也要看这个NOSQL针对的应 用场景是否就是符合我们业务需要的。另外，NOSQL逼近是一个新新事物，其用户群不可能有MYSQL或ORACLE这么多，因此我们也不能期望其稳定性 能达到非常高的标准，而且NOSQL由于其定制化的特点，在使用的时候不一定都可以通过标准SQL来使用对于学习成本也是我们需要考虑的因素。不管怎么样 在该需要用的时候还是要用，有的应用单靠RDBMS是没有可能实现这么高性能的，不用NOSQL就是死路一条，用了即使它不稳定还有可能活。

• NOSQL之Mongodb

Mongodb是一款性能超高的文档型数据库，之所以它这么火不仅仅是因为性能高，而且它功能也很全，相比其它NOSQL它几乎可以实现90%以上 的SQL操作，并且也有丰富的高可用性的配置方式。总结下来Mongodb是一款性能几倍于传统RDBMS的最接近于RDBMS功能的NOSQL。对于对 性能要求很高，特别是写数据并发要求很高的应用来说使用Mongodb是比较适合的，比如存业务日志或系统日志。值得一提的是：

1. Mongodb也不是万能的，对于超大级别的数据量如果不进行数据分区，那么Mongodb也救不了你，并且不要期望Mongodb的自动Sharding功能能有多好，自动的毕竟没有手动这么准确，如果你能想到怎么进行数据分片的话还是推荐手动进行。
2. Mongodb的性能是很好的，但这也是有限度的。只要拥有比较大的内存，那么热数据可以在内存中保存，读取性能不会太差，但是数据量达到一定的 限度之后，如果你的索引数据都在内存中放不下的话，那么其性能会很差的，其实我们也很容易想到为什么，举个例子，我们在查字典的时候需要翻索引的，至于字 典真正的内容在哪里其实问题不大的，如果一本百科全书即使由100本书构成，只要索引在手里查到了哪一本再去取问题不大，如果这个索引也是由100本书构 成，查索引就不能一次性在手里查完还需要翻不同书的话这个性能就会非常差。

• NOSQL之Redis

Redis于其说是一款NOSQL还不如说是一款缓存组件，在大多数时候把NOSQL当成一个服务端可以做计算的，存储复杂类型的，又具有一些诸如队列、管道等小功能的升级版本的Memcached是不错的。我个人使用Redis的心得是：

1. Redis不像Memcached，它可以保存多种形式的数据，而不仅仅是一个字符串，这是很有亮点的，意味着我们直接可以在服务端针对大量数据 进行一个计算，然后服务端直接返回计算结果，而不是要从缓存中把所有数据都取出来在客户端进行一番计算然后再保存回缓存中的（这里的客户端是指使用 NOSQL的客户端，不是浏览器），也就是说要用好Redis是要写一些定制性的代码的，把我们真正的业务逻辑嵌入到Redis中去，如果只是存 KeyValue的话性能不一定比Memcached高多少的。
2. 一般情况下不建议过多依赖Redis的磁盘VM的，有16GB内存保存32GB的数据是可以的，有16GB的内存用Redis保存1TB的数据那 就是用错Redis了。NOSQL的产品其实原理上来说都不是特别复杂的，使用NOSQL之前最好熟悉一下它的原理，这样我们更容易用好NOSQL产品。 总之我的观点还是这样，由于内存和磁盘性能的巨大差异，如果说能在内存中做大部分事情的话，这个性能就会比较好，如果要来回在内存和磁盘上翻腾的话这个性 能也好不到哪里去。

• NOSQL之HBase

HBase、Hadoop适合的是超大数据量的存储和计算，它其实是真正的一个分布式的概念，数据不再能在一个单点上保存了，需要分散到很多机器上，然后计算结果也是分别计算后汇总在一起。对于这套东西我的体会是不要轻易引入：

1. 除非是亿级以上的数据量并且数据的格式比较简单，否则要考虑是否适合引入，HBase的学习曲线不低的，而且最好是在社区熟悉过一段时间的，否则连用哪套版本的Hadoop什么的都搞不清楚，版本没用对要么有很多难以解决的BUG要么就是连基本的连通性都搞不起来。
2. 要想有很好的性能，至少有20台以上的服务器再来搞HBase，一两台机器就算了，还没到分布式的这个需求。想想也知道所谓通过并行来提高效率首先是你有这么多资源可以把数据并行分散出去，然后同时进行计算汇总才能节约时间，如果根本数据都没分出去怎么可能节省时间。

[转载]使用Glimpse 监测ASP.NET MVC网站 – 张善友 – 博客园.

The following configuration values are allowed for Glimpse in your web.config:

<glimpse enabled="true" 
    requestLimit="5" 
    loggingEnabled="false"
    ipForwardingEnabled="false"
    cacheEnabled="true"> 
    <!-- 
 set enabled to false to completely turn off Glimpse. 
 requestLimit specifies the max number of requests Glimpse will save. 
 enableLogging (false by default) if you experience problems with Glimpse 
 ipForwardingEnabled (false by default) will force Glimpse to validate IP addresses based on the value in the HTTP_X_FORWARDED_FOR header. Useful if your server is behind a proxy or load balancer.
 cacheEnabled (true by default) Glimpse will tell browsers to cache static files by default
 -->
    <ipAddresses> <!-- List of IP addresses allowed to get Glimpse data. Optional. localhost (IPv4 & IPv6) by default -->
        <add address="127.0.0.1" />
        <add address="::1" />
    </ipAddresses>
    <contentTypes><!-- List of content types Glimpse will provide data for. Optional  text/html and application/json by default -->
        <add contentType="text/html"/>
    </contentTypes>
    <pluginBlacklist><!-- List of plugins for Glimpse to ignore. Optional. By default all plugins will load -->
        <add plugin="Glimpse.Core.Plugin.Request"/>
        <add plugin="Glimpse.Core.Plugin.MetaData"/>
    </pluginBlacklist>
    <environments><!-- List of environments your application runs in. Used for the new environment switcher feature. Optional. By default environment information will no be shown -->
        <add name="Dev" authority="localhost:33333" />
        <add name="Prod" authority="getglimpse.com" />
    </environments>
    <urlBlacklist><!-- Glimpse will ignore all requests made to URI's that match any regular expression in this list. Optional. By default all URI's will be considered for Glimpse inspection. -->
        <add url="{regex}"/>
        <add url="{regex}"/>
    </urlBlacklist>
</glimpse>

[转载]SQL Server 2008之用户自定义函数 – 马燕龙 – 博客园.

[转载]GTD——一种比较流行的任务管理系统 – ZhugeKM – 博客园.

[转载]List的IndexOf方法和Remove方法 – 龙玺 – 博客园.

[转载]第一章 Web MVC简介 —— 跟开涛学SpringMVC – 开涛的博客 – ITeye技术网站.

Web MVC简介

1.1、Web开发中的请求-响应模型：

在Web世界里，具体步骤如下：

1、  Web浏览器（如IE）发起请求，如访问http://sishuok.com

2、  Web服务器（如Tomcat）接收请求，处理请求（比如用户新增，则将把用户保存一下），最后产生响应（一般为html）。

3、web服务器处理完成后，返回内容给web客户端（一般就是我们的浏览器），客户端对接收的内容进行处理（如web浏览器将会对接收到的html内容进行渲染以展示给客户）。

因此，在Web世界里：

都是Web客户端发起请求，Web服务器接收、处理并产生响应。

一般Web服务器是不能主动通知Web客户端更新内容。虽然现在有些技术如服务器推（如Comet）、还有现在的HTML5 websocket可以实现Web服务器主动通知Web客户端。

到此我们了解了在web开发时的请求/响应模型，接下来我们看一下标准的MVC模型是什么。

1.2、标准MVC模型概述

MVC模型：是一种架构型的模式，本身不引入新功能，只是帮助我们将开发的结构组织的更加合理，使展示与模型分离、流程控制逻辑、业务逻辑调用与展示逻辑分离。如图1-2

图1-2

首先让我们了解下MVC（Model-View-Controller）三元组的概念：

Model（模型）：数 据模型，提供要展示的数据，因此包含数据和行为，可以认为是领域模型或JavaBean组件（包含数据和行为），不过现在一般都分离开来：Value Object（数据） 和 服务层（行为）。也就是模型提供了模型数据查询和模型数据的状态更新等功能，包括数据和业务。

View（视图）：负责进行模型的展示，一般就是我们见到的用户界面，客户想看到的东西。

Controller（控制器）：接收用户请求，委托给模型进行处理（状态改变），处理完毕后把返回的模型数据返回给视图，由视图负责展示。 也就是说控制器做了个调度员的工作，。

从图1-1我们还看到，在标准的MVC中模型能主动推数据给视图进行更新（观察者设计模式，在模型上注册视图，当模型更新时自动更新视图），但在Web开发中模型是无法主动推给视图（无法主动更新用户界面），因为在Web开发是请求-响应模型。

那接下来我们看一下在Web里MVC是什么样子，我们称其为 Web MVC 来区别标准的MVC。

1.3、Web MVC概述

模型-视图-控制器概念和标准MVC概念一样，请参考1.2，我们再看一下Web MVC标准架构，如图1-3：

如图1-3

在Web MVC模式下，模型无法主动推数据给视图，如果用户想要视图更新，需要再发送一次请求（即请求-响应模型）。

概念差不多了，我们接下来了解下Web端开发的发展历程，和使用代码来演示一下Web MVC是如何实现的，还有为什么要使用MVC这个模式呢？

1.4、Web端开发发展历程

此处我们只是简单的叙述比较核心的历程，如图1-4

图1-4

1.4.1、CGI：（Common Gateway Interface）公共网关接口，一种在web服务端使用的脚本技术，使用C或Perl语言编写，用于接收web用户请求并处理，最后动态产生响应给用户，但每次请求将产生一个进程，重量级。

1.4.2、Servlet： 一种JavaEE web组件技术，是一种在服务器端执行的web组件，用于接收web用户请求并处理，最后动态产生响应给用户。但每次请求只产生一个线程（而且有线程 池），轻量级。而且能利用许多JavaEE技术（如JDBC等）。本质就是在java代码里面 输出 html流。但表现逻辑、控制逻辑、业务逻辑调用混杂。如图1-5

图1-5

如图1-5，这种做法是绝对不可取的，控制逻辑、表现代码、业务逻辑对象调用混杂在一起，最大的问题是直接在Java代码里面输出Html，这样前端开发人员无法进行页面风格等的设计与修改，即使修改也是很麻烦，因此实际项目这种做法不可取。

1.4.3、JSP：（Java Server Page）：一种在服务器端执行的web组件，是一种运行在标准的HTML页面中嵌入脚本语言（现在只支持Java）的模板页面技术。本质就是在html 代码中嵌入java代码。JSP最终还是会被编译为Servlet，只不过比纯Servlet开发页面更简单、方便。但表现逻辑、控制逻辑、业务逻辑调用 还是混杂。如图1-6

图1-6

如图1-6，这种做法也是绝对不可取的，控制逻辑、表现代码、业 务逻辑对象调用混杂在一起，但比直接在servlet里输出html要好一点，前端开发人员可以进行简单的页面风格等的设计与修改（但如果嵌入的java 脚本太多也是很难修改的），因此实际项目这种做法不可取。

JSP本质还是Servlet，最终在运行时会生成一个 Servlet（如tomcat，将在tomcat\work\Catalina\web应用名\org\apache\jsp下生成），但这种使得写 html简单点，但仍是控制逻辑、表现代码、业务逻辑对象调用混杂在一起。

1.4.4、Model1：可以认为是JSP的增强版，可以认为是jsp+javabean如图1-7

特点：使用<jsp:useBean>标准动作，自动将请求参数封装为JavaBean组件；还必须使用java脚本执行控制逻辑。

图1-7

此处我们可以看出，使用<jsp:useBean>标准动作可以简化javabean的获取/创建，及将请求参数封装到javabean，再看一下Model1架构，如图1-8。

图1-8 Model1架构

Model1架构中，JSP负责控制逻辑、表现逻辑、业务对象（javabean）的调用，只是比纯JSP简化了获取请求参数和封装请求参数。同样是不好的，在项目中应该严禁使用（或最多再demo里使用）。

1.4.5、Model2：在JavaEE世界里，它可以认为就是Web MVC模型

Model2架构其实可以认为就是我们所说的Web MVC模型，只是控制器采用Servlet、模型采用JavaBean、视图采用JSP，如图1-9

图1-9 Model2架构

具体代码事例如下：

从Model2架构可以看出，视图和模型分离了，控制逻辑和展示逻辑分离了。

但我们也看到严重的缺点：

1．  1、控制器：

1．1．1、控制逻辑可能比较复杂，其实我们可以按照规约，如请求参数submitFlag=toAdd，我们其实可以直接调用toAdd方法，来简化控制逻辑；而且每个模块基本需要一个控制器，造成控制逻辑可能很复杂；

1．1．2、请求参数到模型的封装比较麻烦，如果能交给框架来做这件事情，我们可以从中得到解放；

1．1．3、选择下一个视图，严重依赖Servlet API，这样很难或基本不可能更换视图；

1．1．4、给视图传输要展示的模型数据，使用Servlet API，更换视图技术也要一起更换，很麻烦。

1.2、模型：

1．2．1、此处模型使用JavaBean，可能造成JavaBean组件类很庞大，一般现在项目都是采用三层架构，而不采用JavaBean。

1.3、视图

1．3．1、现在被绑定在JSP，很难更换视图，比如Velocity、FreeMarker；比如我要支持Excel、PDF视图等等。

1.4.5、服务到工作者：Front Controller + Application Controller + Page Controller + Context

即，前端控制器+应用控制器+页面控制器（也有称其为动作）+上下文，也是Web MVC，只是责任更加明确，详情请参考《核心J2EE设计模式》和《企业应用架构模式》如图1-10：

图1-10

运行流程如下：

职责：

Front Controller：前 端控制器，负责为表现层提供统一访问点，从而避免Model2中出现的重复的控制逻辑（由前端控制器统一回调相应的功能方法，如前边的根据 submitFlag=login转调login方法）；并且可以为多个请求提供共用的逻辑（如准备上下文等等），将选择具体视图和具体的功能处理（如 login里边封装请求参数到模型，并调用业务逻辑对象）分离。

Application Controller：应用控制器，前端控制器分离选择具体视图和具体的功能处理之后，需要有人来管理，应用控制器就是用来选择具体视图技术（视图的管理）和具体的功能处理（页面控制器/命令对象/动作管理），一种策略设计模式的应用，可以很容易的切换视图/页面控制器，相互不产生影响。

Page Controller(Command)：页面控制器/动作/处理器：功能处理代码，收集参数、封装参数到模型，转调业务对象处理模型，返回逻辑视图名交给前端控制器（和具体的视图技术解耦），由前端控制器委托给应用控制器选择具体的视图来展示，可以是命令设计模式的实现。页面控制器也被称为处理器或动作。

Context：上 下文，还记得Model2中为视图准备要展示的模型数据吗，我们直接放在request中（Servlet API相关），有了上下文之后，我们就可以将相关数据放置在上下文，从而与协议无关（如Servlet API）的访问/设置模型数据，一般通过ThreadLocal模式实现。

到此，我们回顾了整个web开发架构的发展历程，可能不同的web层框架在细节处理方面不同，但的目的是一样的：

干净的web表现层：

    模型和视图的分离；

控制器中的控制逻辑与功能处理分离（收集并封装参数到模型对象、业务对象调用）；

控制器中的视图选择与具体视图技术分离。

轻薄的web表现层：

    做的事情越少越好，薄薄的，不应该包含无关代码；

       只负责收集并组织参数到模型对象，启动业务对象的调用；

       控制器只返回逻辑视图名并由相应的应用控制器来选择具体使用的视图策略；

       尽量少使用框架特定API，保证容易测试。

到此我们了解Web MVC的发展历程，接下来让我们了解下Spring MVC到底是什么、架构及来个HelloWorld了解下具体怎么使用吧。

本章具体代码请参考 springmvc-chapter1工程。

私塾在线学习网原创内容（http://sishuok.com）

原创内容，转载请注明私塾在线【http://sishuok.com/forum/blogPost/list/5050.html】

[转载]企业级系统架构设计技术与互联网应用技术结合主题一 – 大规模并发性能问题探讨 – 系统架构与架构应用 – ITeye群组.
何谓大规模并发，不同层面有不同的理解

企业应用（Intranet）：千级强并发，万级弱并发（在线用户），十万级用户

•     大型企业ERP、供应链,大型企业HR、办公OA

互联网应用（Internet）：百万级强并发，千万级弱并发（在线用户），亿级用户/

• 门户网站（新浪、腾讯）
• 平台级电子商务（阿里巴巴、淘宝网、拍拍网）
• 搜索引擎（百度）

电子商务企业应用（Intranet + Internet）：十万级强并发，百万级弱并发（在线用户），千万级用户

• B2C电子商务（京东、凡客、一号店）
• 垂直型电子商务（金银岛、携程）

不同系统间的并发特点
企业系统
大量事务性、实时性访问

• 大量的事务、锁检测导致数据库访问瓶颈
• 需要数据操作的实时更新

大量有状态性访问

• 数据访问具有较强的操作上下文
• 数据一致性、准确性的高敏感
• 数据每一次事务性更新都必须得到充分展现，并且确保数据访问的一致性

清晰的业务逻辑进行并发划分

• 一般来说，企业系统都可以进行明确的业务区分，从而决定系统特点

互联网系统
海量非事务性访问

• 极其巨大的数据量及数据访问导致IO操作成为瓶颈

模糊的并发区分

• 并发访问的用户中很难通过内容进行有效分发
• 并发访问一般具有地域性

数据访问效率的高敏感

• 用户对系统的响应时间非常敏感，需要在几秒内得到信息反馈
• 用户更加在意数据的匹配性

电子商务系统
数据实时性的高敏感
价格、信息同步的一致性等
受制于企业级系统的约束

• 如支付，受事务性影响

海量非事务性访问+一定规模事务性访问
信息访问具有互联网系统特点、信息操作具有企业系统特点

• 如数据的搜索查询、展现具有互联网系统特点
• 如数据的操作（支付、结算）具有企业系统事务性特点

什么是性能问题

• 在可识别的压力下，系统无法提供服务 （最差的性能问题）
• 在可识别的压力下，系统无法按服务质量标准提供服务 （满足性能标准，但是健壮性不足）
• 在可识别的压力下，系统无法持续按服务质量标准提供服务 （系统的可靠性和健壮性）
• 在超过识别的压力下，系统无法尽快恢复
• 能否有故障转移、故障恢复、冗余热备等机制
• 在超过识别的压力下，系统无法柔性伸缩 （系统的可伸缩性）

什么不是性能问题

• 超过可识别的压力情况下，系统暂时无法有效提供服务

性能测量
服务质量

• 网络响应：网络响应时间、网络吞吐量、网络带宽及带宽利用率
• 服务响应时间：包括平均、峰值、标准区间值
• 服务处理质量：事务成功率、单位时间响应事务次数

服务端设备状态

• CPU：CPU使用率
• 内存：使用内存大小
• VM：GC次数（Full GC次数）、堆内存、线程数、锁和阻塞情况
• 磁盘IO：磁盘访问效率、磁盘空间、磁盘IO吞吐量

系统可靠性、健壮性

• 单节点处理的访问量
• 故障恢复时间
• 节点复制和节点扩展的难易

系统可能的性能瓶颈
网络

• 网络带宽的总体限制
• 网络连接数的限制（如TCP/IP, 数据库连接等）

服务器

• 每个响应占用相应的资源，导致内存成为瓶颈
• 比如JVM为每个线程分配栈空间，过多栈空间导致内存消耗
• 比如每个HTTP连接在Session存储内容，导致OOME
• 同时响应一定量的并发操作，导致CPU占用过高

磁盘IO

• 频繁访问数据库，导致数据交换IO操作频繁
• 频繁访问IO文件，导致磁盘IO成为瓶颈

企业级系统架构及技术特点
架构设计
基于SOA和MDA的架构

• 以服务为核心单元的 设计思想，以传统WS作为服务发布
• 以模块化为系统构建方式，重视应用子系统和子模块的独立性和可重用性

中央集中式部署架构

• 专业小型服务器
• 一般不会超过5台部署服务器，不会多于10个应用节点
• 热备和故障恢复机制、灾备系统

关注流程

• 工作流技术，尤其是分布式节点间流程整合
• 企业系统间的无缝转移

门户

• 跨系统，跨节点间的单点登录

技术运用
以商业性产品为主

• 追求单节点稳定性
• 较少需要7*24小时支持
• 以商业性关系数据库为主要存储

比较严格的事务性访问

• 完全基于数据库事务
• 分布式事务（JTA）

较为复杂并且功能丰富的用户界面

• 用户具有相对统一的客户端（比如使用IE浏览器）
• 用户可以接受适当的响应和延迟

互联网系统架构及技术特点
架构设计
以界面展现和用户体验为主要设计

• 大量运用Ajax实现局部提交和局部刷新

以轻量级、伸缩性为架构主要考虑

• 除某些平台级应用外，极少使用服务扩展
• 使用REST风格的WebService或者纯粹的处理Json的Web响应
• 数以百台甚至上万台PC服务器，多个数据中心，站点镜像
• 分布式独立域以及部署域之间定时通信

高性能缓存机制

• 双向页面缓存
• 内容静态化技术
• 数据缓存

非事务、非关系型数据库

• 全面NoSQL数据库

技术运用
大量使用开源技术产品

• LAMP: Linux + Apache + MySQL + PHP
• Tomcat, Lucene, Memcache

简单界面开发技术

• 脚本语言，如PHP, Python， Ruby等
• 对多种浏览器的支持

底层高性能处理优化

• 使用C、C++实现底层通信和IO优化

电子商务系统架构及技术特点
架构设计
关注数据的糅合（Mashup）
关系数据库与高性能NoSQL数据库结合
不固定的架构设计思路

• 可能偏互联网方向，也可能偏企业系统方向
• 分布式部署

事务缓存机制

• 事务迁移、事务恢复、事务批量处理

较为严格的安全机制

• 部分功能使用HTTPS及数字证书

与企业系统的对接交互

• 与银行、支付平台的对接
• 与企业订单系统、进销存系统、物流系统的对接

技术运用
有时效的缓存机制

• 确保数据实时性与性能的平衡

大量数据挖掘和分析运用

• 相关性分析
• 定向推荐

部分运用商业中间件技术产品

• 应用服务器
• 业务流程管理

大量的开源技术运用

• Java相关开源技术比较常见

[转载]海量数据库及分区4——《12年资深DBA教你Oracle开发与优化——性能优化部分》 – Tech – ITeye论坛.

2012-12-21 21:52:05
海量数据库及分区4——《12年资深DBA教你Oracle开发与优化——性能优化部分》
浏览(305)|评论(1)   交流分类：数据库|笔记分类: 《12年资深DBA教……

目录：

Oracle数据完整性和锁机制

索引及优化之表分析

表分析、约束及表间关系

Oracle体系结构1

Oracle体系结构2

海量数据库及分区1

海量数据库及分区2

海量数据库及分区3

海量数据库及分区4

高级SQL优化(一) 

高级SQL优化(二)

高级SQL优化(三) 常用优化工具 

PPT和源码下载：    http://sishuok.com/forum/posts/list/6365.html

配套视频课程

    Oracle性能优化 http://sishuok.com/product/601

    海量数据库和高级SQL优化 http://sishuok.com/product/602

管理分区

增加索引分区

本地索引无法明确的增加分区，其增加只能是基表增加分区，此时新增加的索引分区的名字是Oracle自命名的，但可以给其重新命名。

也可是使用ALTER INDEX index_name MODIFY DEFAULT ARRTIBUTES  TABLASEPACE tablespace_name修改本地索引分区默认的表空间后，再使用ADD PARTITION增加表的分区，则基表增加分区带来索引分区的增加，会自动将新增加的索引分区指向该表空间。

接合分区

  分区接合是针对散列分区或者*-散列子分区的，目的是减少分区数。当某个散列分区接合后，Oracle将其分区的数据分散到其它分区中。被接合的分区 是由数据库选择的，接合完成后该分区会被删除，且如果没有使用UPDATE INDEX子句，本地索引和全局索引均将变成不可用，一般需要重建索引。

1.散列分区表的散列分区接合

  使用语法 ALTER TABLE  COALESCE PARTITION。

2.散列子分区表的散列子分区集合

  使用语法 ALTER TABLE MODIFY PARTITION  COALESCE SUBPARTITION。                        参见附件脚本1

 

删除表分区

  只针对范围和列表分区或者组合*-范围和组合*-列表分区，散列分区不能删除，替代的方式是接合分区。

分区或子分区删除后，其中的数据也被删除，同样，基于这些分区或者子分区的本地索引中相应的分区和子分区也会被删除；对于全局索引除非使用了UPDATE INDEXS子句，删除分区后其会变成不可用，一般需要重构。如果要防止数据被删除替代的方式是使用合并分区MERGE PARTITION。

删除分区的语句是ALTER TABLE DROP PARTITION，删除子分区的语句时ALTER TABLE DROP SUBPARTITION。

1.从包含数据和全局索引的表中删除分区

  此时指的是表中有数据，且包含一个或几个全局索引。

  (1).方法一(推荐的方法)

    先删除分区，再一个个的重构全部索引，此时可以解决范围分区的全局索引的问题（删除后全部变成不可用）。这么做的原因是不要考虑全局索引是什么分区的。一般的方法是编写一个工具子程序，通过动态SQL开重构索引：

  ALTER TABLE table_name DROP PARTITION partition_name;

ALTER INDEX index_name1_on_ table_name REBUILD;

  …

 ALTER INDEX index_namen_on_ table_name REBUILD;

(2).方法二

    先删除该分区的数据（因为删除数据会重构全局分区），再删除分区，一般针对数据不是特别多的表：

  DELETE FROM table_name PARTITION(partition_name);

ALTER TABLE table_name  PARTITION partition_name;

(3).方法三

    使用UPDATE INDEXES子句，此时Oracle会自动重构该全局索引：

     ALTER TABLE table_name  PARTITION partition_name UPDATE INDEXES;

2.从包含数据和参照完整性（外键）的表中删除分区

  (1).方法一

    如果要删除的分区中的数据没有被参照引用，先禁用该参照完整性约束，再删除分区，最后再启用该参照完整性约束。

(2).方法二

如果要删除的分区中的数据被参照引用，先删除该分区中数据，再删除分区。

删除索引分区

无法显式的删除本地索引的分区，删除的唯一方式是本地索引分区基表的分区被删除时由Oracle自动的隐式删除。
如果全局索引分区是空的，则可以显式的删除它，使用的语句是ALTER INDEX index_name DROP PARTITION partition_name。但是，如果全局索引分区包含数据，删除则会引起更高级的分区（即下一个分区）变得不可用。如果非要这么做，则对更高级的分 区需要重构，语法是：

 ALTER INDEX index_name REUBILT PARTITION nextpartition_name

交换分区

   可以将一个分区(子分区)和非分区表进行数据交换，oracle交换的方法是其实是对逻辑存储段进行交换。同样，散列|范围|列表分区可以与复合*-散 列|*-范围|*-列表分区间也可以进行数据交换。当应用中需要将非分区表的数据转换进入分区表的分区时非常高效实用。使用INCLUDEING INDEXES子句可以同步将本地索引也进行交换，使用WITH VALIDATATION子句还可以实现行数据的验证。

交换分区时如果不带UPDATE INDEXES子句，则全局索引或全局索引基于的分区将变为不可用。

1.三种单级分区与非分区表的交换

使用ALTER TABLE table_name EXCHANGE PARTITION partition_name WITH TABLE nonpartition_name

交换前：

1.三种单级分区与非分区表的交换

交换后：

如再次交换，则二者的数据会再次互换，变成第一次交换前的状态

2. 单级散列分区表与复合*-散列分区的交换

此时要求单级散列分区表的分区键与复合*-散列分区表的子分区键相同，且两个交换的散列分区数也得相同，此外也不能指定单级散列分区表的某一个分区进行交换。

交换前：

 

2. 单级散列分区表与复合*-散列分区的交换

交换后：

 

再交换后，回到原始状态：

 

参见附件脚本3

3. 复合*-散列分区中的散列子分区交换

   使用ALTER TABLE … EXCHANGE SUBPARTITION与非分区表进行交换，且只能跟非分区表进行交换。 参见附件脚本4

交换前：

 

交换后：

 

4.单级列表分区表与复合*-列表分区的交换

   此时要求List分区表的分区键和*-List表的子分区键相匹配，前者的List分区数与后者的List子分区相同。 参见附件脚本5

5. 复合*-列表分区中的列表子分区交换

同样也是使用ALTER TABLE … EXCHANGE SUBPARTITION与非分区表进行交换，且只能跟非分区表进行交换。 参见附件脚本6

6.单级范围分区表与复合*-范围分区的交换

此时要求Range分区表的分区键和*-Range表的子分区键相匹配，前者的Range分区数与后者的Range子分区相同。 参见附件脚本7

7. 复合*-范围分区中的范围子分区交换

    同样也是使用ALTER TABLE … EXCHANGE SUBPARTITION与非分区表进行交换，且只能跟非分区表进行交换。 参见附件脚本

列表分区值的增加

仅有列表分区或列表子分区存在该功能，如果要增加的值在其它分区或者当前分区的其它子分区中存在，则不能增加，因此对于存在default的List分区 /子分区，本功能不可用。本操作完成后，本地索引和全局索引保留为可用。 参 见附件脚本9

1.列表分区

 ALTER TABLE table_name MODIFY PARTITION partition_name

 ADD VALUES

2.列表子分区

ALTER TABLE table_name MODIFY SUBPARTITION subpartition_name

 ADD VALUES

列表分区值的删除

也是仅有列表分区或列表子分区存在该功能，如果要删除的值在当前分区子分区中存在，则不能报错，必须先删除该值对应的记录才能再删除，如果一个分区中只有 一个值，无论其有否数据，也不能删除该值，因此对于存在default的List分区/子分区，本功能不可用。本操作完成后，本地索引和全局索引保留为可 用。 参见附件脚本10

1.列表分区

 ALTER TABLE table_name MODIFY PARTITION partition_name

 DROP VALUES

2.列表子分区

ALTER TABLE table_name MODIFY SUBPARTITION subpartition_name

 DROP VALUES

移动分区

移动分区的作用包括：

l重新聚合数据，以减少碎片

l将分区移动到另外一个表空间(MODIFY命令搞不定)

l修改“建立时间”属性

l对有压缩属性的，将数据压缩后存储，因此对压缩分区表分写入后需要调用本命令

一般来说，该命令执行完后，本地索引和全局索引变成不可用，需要重新构建。

1.移动表分区

 ALTER TABLE table_name MOVE PARTITION partition_name

 [TABLESPACE new_tablespace_name][NOLOGGING|LOGGING][COMPRESS]

1.移动表分区

 ALTER TABLE table_name MOVE PARTITION partition_name

 [TABLESPACE new_tablespace_name][NOLOGGING|LOGGING][COMPRESS];

执行该命令后，即使没有指定新的表空间，也会删除旧的分区段，创建一个新的分区段。

2.移动子分区

针对复合分区表，同上，关键字改成SUBPARTIOTION  subpartition_name，此外此时只能移动子分区，对分区的移动是非法的。

3.移动索引分区

切记不要通过MOVE指令来执行，虽然Oracle支持，建议一律先删除索引再重建。

参见附件脚本11

重构索引分区

重构索引分区的理由一般包括：

l恢复空间或改善性能

l修复因介质原因而损坏的索引分区

l通过SQL*Loader或导入工具装载数据后重构本地索引

l重构被标记为UNUSABLE的索引分区

l启用b-tree索引中的键压缩

1.重构全局索引分区

有以下两种方法：

（1).ALTER INDEX index_name REBUILD PARTITION partition_name

  （2）.删除索引，再重建。推荐这种方法

  参见附件脚本12.1

2.重构本地索引分区  参见附件脚本12.2

有以下两种方法：

（1).ALTER INDEX index_name  REBUILD

       {PARTITION partition_name| SUBPARTITION subpartition_name}

  （2）. ALTER TABLE table_name  MODIFY

       [{PARTITION partition_name| SUBPARTITION subpartition_name}

       REBUILD UNUSABLE LOCAL INDEXES

重命名分区

使用重命名分区有两种需求，一种是将分区名改成更有意义的，第二种是将系统自动生成的分区名改成自己想要的名字。

1.重命名分区/子分区

  ALTER TABLE table_name RENAME PARTITION old_name TO new_name;

  ALTER TABLE table_name RENAME SUBPARTITION old_name TO new_name;

2.重索引分区

  除关键字改成ALTER TABLE table_name 改成ALTER INDEX index_name外，其它同重命名分区/子分区

参见附件脚本13

拆分分区

当一个分区变得很大时会带来备份、恢复和维护操作的长时性，此时可以对分区进行拆分，拆分可以将一个分区拆分成两个，拆分的分区如果包含数据，完成拆分后索引会变得不可用，一般需要重构。

1.拆分Range分区表的Range分区

  ALTER TABLE table_name SPLIT PARTITION partition_name

  AT(values) INTO(PARTITION new_ partition_name1,

                  PARTITION new_partition_name2);

  其中拆分完分区后的第一个分区的值小于AT值，第二个小于原来分区的值。如果拆分完的分区没有指定名字，系统使用SYS_Pn自动命名。拆分完成后如果存在索引，还需要重构。

参见附件脚本14.1

2.拆分List分区表的List分区

  ALTER TABLE table_name SPLIT PARTITION partition_name

  VALUES(values) INTO(PARTITION new_ partition_name1,

                  PARTITION new_partition_name2);

  其中values值是定义中枚举值范围的子集，该值写入到拆分后的第一个分区，未包含的写入到第二个分区。也可以对default分区进行拆分，方法同上。

参见附件脚本14.2

3.拆分*-hash分区表的的分区

子分区可以采用SUBPARTITIONS n方式，也可以采用PARTITION partition_name方式。如果不指定SUBPARTITION子句，则从父分区去继承子分区数。需要注意的是拆分时继承的属性与合并时不同，合 并时继承的是表级的属性，原因是合并时有两个父分区。其中关键字values或at取决于分区的类型，即range为at，list为values

参见附件14.3

4.拆分*-List分区表的分区

  此时分区级和子分区级均可拆分

(1).拆分*-List分区

如果是R-L类型，则与拆分范围分区类似，如果是L-L类型，则跟拆分列表分区类似。无需指定子分区语句，子分区属性从拆分的父分区处继承，此时拆分后新子分区的名字无法指定。

(2).拆分*-List子分区

  ALTER TABLE table_name SPLIT SUBPARTITION subpartition_name

  VALUES(values) INTO(SUBPARTITION new_subpartition_name1,

                  SUBPARTITION new_subpartition_name2);

参见附件脚本14.4

5.拆分*-Range分区表的分区   参见附件脚本14.5

  此时也是分区级和子分区级均可拆分，新分区的子分区的范围值不可指定，新分区的子分区属性继承自父分区。

(1).拆分*-Range分区

如果是R-R类型，则与拆分范围分区类似，如果是L-R类型，则跟拆分列表分区类似。无需指定子分区语句，子分区属性从拆分的父分区处继承，此时拆分后新子分区的名字无法指定。

(2).拆分*-Range子分区

  ALTER TABLE table_name SPLIT SUBPARTITION subpartition_name

  AT(values) INTO(SUBPARTITION new_subpartition_name1,

                  SUBPARTITION new_subpartition_name2);

6.拆分索引分区

  本地索引分区无法显式的拆分，其拆分的唯一途径是基表的分区拆分时由Oracle隐式的进行拆分。

全局索引分区可以拆分，拆分完成后需要重构，但我们不推荐这么做，如下例：

ALTER INDEX quon1 SPLIT

PARTITION canada AT ( 100 ) INTO

PARTITION canada1 …,

PARTITION canada2 …);

ALTER INDEX quon1 REBUILD PARTITION canada1;

ALTER INDEX quon1 REBUILD PARTITION canada2;

清空分区

   使用ALTER TABLE table_name TRUNCATE {PARTITION partition_name| SUBPARTITION subpartition_name}清空分区会清除掉分区中的数据，类似清空表。但是索引分区不可清空，清空分区同步会清空索引分区在该分区的数据。

1.清空表分区

会清空分区数据，但不会回收空间，有两种情况：

(1).包含数据和全局索引的分区

  方法一是先清空该分区再重构基于该分区的全局索引；第二种方法是先删除该分区的数据再清空该分区；第三种方法是使用UPDATE INDEXES子句。推荐第二种方式。

1.清空表分区

(2).包含数据和代参考完整性约束的分区

  方法一先禁用该约束再清空分区最后启用该约束；第二种方法是先删除该分区的数据再清空该分区。推荐第一种方式。

2.清空子分区

直接使用该语句，同步的本地索引数据也会删除。

相关数据字典

视图	说明	视图	说明
DBA_PART_TABLES ALL_PART_TABLES USER_PART_TABLES	分区表	DBA_TAB_PARTITIONS ALL_TAB_PARTITIONS USER_TAB_PARTITIONS	分区
DBA_TAB_SUBPARTITIONS ALL_TAB_SUBPARTITIONS USER_TAB_SUBPARTITIONS	子分区	DBA_PART_KEY_COLUMNS ALL_PART_KEY_COLUMNS USER_PART_KEY_COLUMNS	分区键
DBA_SUBPART_KEY_COLUMNS ALL_SUBPART_KEY_COLUMNS USER_SUBPART_KEY_COLUMNS	子分区键	DBA_PART_COL_STATISTICS ALL_PART_COL_STATISTICS USER_PART_COL_STATISTICS	分区的列和柱状图统计信息

视图	说明	视图	说明
DBA_SUBPART_COL_STATISTICS ALL_SUBPART_COL_STATISTICS USER_SUBPART_COL_STATISTICS	子分区的列和柱状图统计信息	DBA_PART_HISTOGRAMS ALL_PART_HISTOGRAMS USER_PART_HISTOGRAMS	分区柱状图数据
DBA_SUBPART_HISTOGRAMS ALL_SUBPART_HISTOGRAMS USER_SUBPART_HISTOGRAMS	子分区柱状图数据	DBA_PART_INDEXES ALL_PART_INDEXES USER_PART_INDEXES	分区索引

按范围分区和列表分区

1.按范围分区

l大表且对数据的扫描经常按使用范围时，如日期和时间

l对数据的维护需要使用滚动窗口时，如在数据仓库中，经常按月度需要装载最近3年(36个月)的数据。滚动窗口是指一般是周期性的需要装载新数据并清除旧数据的时间窗口

2.列表分区

l列的取值范围是离散且可以枚举时，如按地理区域分区、按流程状态分区

散列分区

   无明确的按范围或者列表方式分区时，可考虑在以下情况下使用散列分区：

l想要数据均衡分布，并可启用部分/全部分区智能连接功能时

l分区键作为主要的唯一值或者值列表时，如使用序列为主键

l想要数据随机均衡分布在不同的分区以便规避I/O瓶颈时

当一个列或多个列构成唯一值时，使用这些列为分区键来建立散列分区，并且将分区数尽量设置为2的幂，如2、4、8、16、32等，一般会获得比较好的性能。

1.复合范围-范围分区

l两个均能按范围分区的维度时，如两个维度的时间（如起始时间、截止时间）

2.复合范围-散列分区

l存储有大量历史数据，且这些历史数据经常要跟另外一个大表连接时。如销售历史表和客户表一期关联对比分析趋势数据时

l传统意义上的散列分区数据经常需要滚动操作时，如某个系统访问的日志信息，需要统计不同客户端ip各个时期的各种记录（如访问记录次数、在线时长等）时

3.复合列表-范围分区

l一般用在第一个维度是枚举值，第二个维度是范围值时，如捐赠数额表，可以先按币种列表分区，再按金额范围分区

4.复合列表-散列分区

l通常用在第一个维度是枚举值，第二个维度无法按范围或列表分区时，如某个信用卡记录表，可以先按区域列表分区、再按卡号进行散列分区

5.复合列表-列表分区

l一般用两个维度都是不连续的离散值时，如前述信用卡账户表，可以先按区域列表分区，再按省份或账户类型（白金卡、金卡、银卡、普通卡等）列表分区

习题

1.本地分区索引的分区可以增加吗，为什么？

2.散列分区要减少分区数如何处理？范围分区和列表分区呢？请试着举例说明。

3.假定表A基于列colA有3个范围单击分区，且建立了一个全局分区索引，表中有数据，如果要删除某个分区，有几种方法？

4.本地索引分区可以删除吗，为什么？如果某个表存在全局分区索引，删除某个分区后，需要接下来执行什么操作，为什么？

5.单级散列分区表与复合*-散列分区交换时，需要满足什么条件？

6.举例说明复合*-散列分区中的散列子分区交换为什么只能跟非分区表进行交换。

7.对分区执行移动操作的两大主要目的是什么？

8.列表归纳各种分区的拆分限制条件，并举例说明其语法。

9.散列分区、范围分区、*-Hash和*-List分区分别建议在什么情况下使用？

10.练习本课程的分区管理操作，增强对分区管理的直观理解。

转载请注明私塾在线【 http://sishuok.com/forum/blogPost/list/0/6411.html】