作者：Fenng 发布在 dbanotes.net.

昨天出差回来，发现家里的宽带因为欠费被停了。浏览器提示页面说宽带服务已经到期，可以在线付费或者到营业厅缴费云云。

初探

印象中电信宽带在服务到期之前会提示，这次什么提示都没有，所以就拨 10000 号客服电话询问，拨通后等了很久，人工服务才接通，客服告知，因为到期转成包月的服务了，就不提示，而且已经欠费。如果续费的话，必须先付清欠费才能续下一年的年费。

考虑到自己也算是做互联网的，而且人家居然还提供在线付费的功能。那就尝试一下吧，也省得跑营业厅了，没想到这是噩梦的开始。点击在线充值，选择地区，输入自己的号码，这地方没有别的提示，我只好认为就是我的宽带账户，填好，然后跳到新的页面，首选是工行网银，因为自己只有招行的网银，所以点击"其它网银/百事通卡支付"，弹出页面提示：

不支持的产品类型：99，请确认你输入的号码（包括地区）

这个提示我猜测了半天没明白到底要说什么，只好重新回到开始的页面，反复数次，还是如此，难道是浏览器的问题？换成 IE，我用的是 IE8，依然是这样的错误。莫非是 IE6 才能兼容? 我特地下载了一个 IETester，折腾了一下还是不行。

再探

又拨了一次 10000 号，这次等了六分钟终于接通了，我假装成不懂网络的用户，客服一步一步教我怎么做。首先要登录到网上营业厅(不登录还没有用? 我心里暗想，果然刚才没这么做，笨啊)，然后选择"我要支付"，然后选择地区，再选择号码。我在这里问，这个号码到底要我输入什么号码? 客服告诉我，就是你宽带帐户的号码。可是我刚才用了很多次也不行啊。客服又改口，不对，应该是你绑定的座机电话的号码，我当时晕倒。心想，这次估计不会出问题了。遂挂断电话，继续折腾。

这次果然，用我家绑定的座机的号码--这个宽带办理的时候是和家里的电话一起办的套餐。终于提示选择使用哪家银行了，好，用招行，发现无法登录，莫非是网络不通? 没办法，只好把自己的无线网卡插上，续费，完毕(后来证实服务停掉也是可以使用指定网银的)。

然后回到网上营业厅首页，一刷新，账户欠费为0了，去办理"宽带续费"。提示"如果你未办理宽带续包业务，请先点击业务办理"，"如果你已经完成业务办理，则请选择在线支付"。点击"立即办理"，出现"中国电信股份公司浙江分公司业务申请协议"页面，确认同意，然后选择定制套餐，选好，确认。然后? 发现不能在线支付。而且发现似乎要等一个"受理结果"才可以。天啊，这大半夜的，难道还要拨打 10000 号找客服? 这次倒好，不管怎么等，客服人工服务就是接不通。

沟通

这时候我已经忍无可忍了，在我的 Twitter 和 微博 上各自发了数条信息声讨这这糟糕的网上营业厅，发现这事情很多朋友都有同感，大家都对电信营业厅垃圾的用户体验相当有怨言。

有点累，休息了一会儿回来继续折腾。重新登录到网上营业厅，一看，差点晕倒，刚才显示欠费 329.68 元，付费之后，现在显示欠费 322.95 元。这到底怎么回事呢? 莫名其妙。想了半天，或许是因为内部数据同步问题吧(后来有该项目的承包商公司的人回复说：真正的原因是：实际欠费322.95，欠利息 6.73元，合计329.68。当你付款进入系统时，先扣利息，再扣欠费，有两次余额。天啦，这样的解释给用户意义在哪里? 即使是内部人员也未必有多少人理解是怎么回事吧?)。我在 Twitter 上的抱怨有朋友看到，给我发消息告诉我这是因为"百事通平台和CRM对接兼容导致"，预计要等到 4 月份会解决。我最关心的还是怎么能最快开通我的宽带，这位朋友说看看能否直接帮我处理一下。过了一会儿，一个网上营业厅的小伙子用自己的电话打过来，和我说了半天，最后告诉我，要等10000号处理了我的业务申请之后，才能生成一个工单，有了这个工单，我才能缴费。正常时间要 1-2 个工作日，他明天会帮我催。

新浪围脖上有人告诉我中国电信客户服务部总监张女士也在，直接发了条私信过去，接着通过私信沟通了一下，张女士也相当的坦诚，"服务方面要改进的很多。包括网厅的优化、宽带续费问题等等"，最后我留了电话愿意提供进一步的反馈。

这时我在微博质疑 10000 号到底是怎么回事，为什么到了晚上拨打不进去? 到底有没有人值班? 过了一会儿，张女士给我打来电话，说是可以拨进去的，要我再试试。本来想休息去了，既然这样，我就再测试一次，再拨，过了7分钟，依然告诉我"人工繁忙，继续等待请按2"...

看了一会儿Twitter和新浪围脖上网上网友的评论和反馈，不乏精辟论断，比如"要是有他们推广业务的那个劲头，这种事就会少很多"。也通过反馈信息进一步了解了电信网上营业厅现状的由来。在此，也允许我向那些承包此类工程的垃圾公司竖起中指！你们赚了钱也就算了，网站做得用心一点不能么?

结局

今天早晨，还在睡梦中的我接到 10000 号客服电话，直接给了我一个 18 位的工单号，终于付款成功了。过了 10分钟，路由器重新拨号，宽带恢复。

今天晚上九点半，接到浙江电信 10000 号客服经理的电话，向我表达了歉意，我对昨天的使用感受做了反馈，当然是不怎么留情面的批评了一下垃圾的网站功能。

后记

这次的事情，反映出来的中国电信内部信息各个子系统环节衔接的混乱令人发指，网站基本谈不上什么用户体验，当然网友也告诉我，这还不算是最差的。就事论事，一系列的接触的过程中，电信人的态度都还是不错的，对待批评倒是有则改之（只是不知道这样的声音是否能传递给公司管理层）。此外，能够通过微博听取反馈相当令人赞赏。

有些地方，可能仅仅是一行文字就可以描述的更加准确，为什么就不从使用者的角度考虑一下呢? 用户体验，不需要高深的东西，只需要常识就够了。

Twitter 、新浪微博发挥了起到了很重要的传播和反馈作用，进而促进平等对话。

如果有其他的选择的话，我当然不想用现在任何一家宽带公司的服务，但是，没得选择，所以我们只好忍受莫名其妙的提价，只好忍受 DNS 劫持... 不过，既然我是你的用户，"你不给我一个说法，我就给你一个说法"，作为用户，我们理应对服务提供商提出一些最基本的要求。这就是我这次较劲的目的。

--EOF--

---

最近文章|Recent Articles

• 杭州五年
• 暂缓迷恋 Cassandra
• 苹果为何不在 iPhone、iPad 平台支持 Flash
• 苹果往事

本站赞助商：豆瓣网

评论数(33)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址：http://www.dbanotes.net/mylife/Bad_UE_Of_CHINA_TELECOM.html

DBA Notes 理念: 用简约的技术取得最大的收益...

我们家彭浩翔滴新片
《志明与春娇》

哦，不
这不是一砣讲《拳皇》和《街霸》滴片片。

这是一砣讲香港禁烟以后
很多办公室吸烟男女走到小巷背后，
吸烟烟滴故事……

 

如果香港还有谁
在饶有趣味滴
观察和拍摄香港，
那估计就只剩下
每天坐地铁滴彭浩翔同学了吧。

虽然丫每天在看《蜗居》含《潜伏》

3月26日21：45
香港会展
传说中滴世界首映...

今天在Itpub看到一个讨论大表的truncate与drop操作的帖子, 下面是我对其的回复.

1. drop 与 Truncate操作类似的地方.
drop 是直接处理数据字典,去掉object与其对应的data_object_id的对应关系..
truncate 操作是创建一个新的空的segment(对应于data object id), 并将此segment与现有对象关联起来.

2. drop 与 truncate 操作都会触发object checkpoint操作, 如果buffer Cache很大的话, 这两个操作都可能会出现较长时间的等待, 在Oracle 10gR2以后, Oracle对Buffer header做了些许变更, 以提高Fast Object Checkpoint的速度.

comment #9 By Jonathan Lewis

Re: KO - I think that appeared in 10.2. There is a new entry in the buffer header structure which allows for a linked list to be built between buffer headers of the same object. This, of course, means yet another little overhead when reading a block into the buffer in the first place. But it is useful for truncates, drops, and shrinks, as it avoids a massive scanning process if you drop a large object which has not been subject to much update.

3. 对于drop 与 Truncate 操作还涉及另外一块事情: 空间的回收.
对于使用Local Management的tablespace ,需要修改这个segment 涉及到的所有数据文件的bitmap 内容的修改.. 一般情况下, 速度都还可以..

如果是基于字典管理的表空间.. 由于所有的回收操作都是基于uet$,fet$表操作的,,所有如果使用的空间量非常大, 回收的操作将非常慢,,我层听说,,有人删除一个表要等待好几个小时甚至1-2天的情况..

解决办法是:

truncate table xxx reuse storage;
alter table xxx deallocate unused keep 2000m;
alter table xxx deallocate unused keep 1500m;
alter table xxx deallocate unused keep 1000m;
alter table xxx deallocate unused keep 500m;

因为, 在数据字典管理的表空间中,所有涉及到空间管理的操作,都需要持有一个ST lock,如果单个操作执行的时间过长, 可能导致整个系统的空间分配操作都无法继续, 这对于绝大部分的OLTP应用,应该都是不可接受的事情..

ST Enqueue - This type of enqueue is used for space management and allocation for dictionary-managed tablespaces

附注:
1. 涉及到fast object checkpoint的相关操作.

truncate table

drop table

direct path read

这一点包含普通的direct path read, 以及在Oracle 11g中引入的Adaptive Direct path read.

2. alter table exchange partition 操作涉及的主要也是object_id 与 data_object_id之间对应关系的切换, 这也是为什么这个操作效率为什么那么快的原因.

No related posts.

今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture

Oracle高可用架构
作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”).Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:

将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:

从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:

如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.

现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:

备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:

这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.

上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).

附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).

今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture

Oracle高可用架构
作者: Uwe Hesse, 译者: Jametong
Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”).Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构(Maximum Availability Architecture,MAA).除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷.
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库.一个Oracle数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本:

将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:

从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障.从而这些服务器所在的站点也是单点故障.这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:

如果两个服务器的其中一个发生故障,数据库C将仍然可用.当然,使用RAC并不仅仅是为了实现HA.在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了.从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点.如果站点C发生故障(比如火灾),数据库C将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC.

现在,这两个站点就不再是单点了.数据库D是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志.在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:

备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换(Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将RAC与Dataguard集合起来,我们就实现了MAA.显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处.
远程镜像是一个广受欢迎的第三方HA解决方案.总体上,它的架构与下图类似:

这时,也没有哪个站点是单点的,类似于使用扩展RAC架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同.使用RAC时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载.

上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).

附注:
其实还有另外一种可选择的架构. 基于Data Guard与单实例的一个结合.
类似于上面介绍的远程Data Guard方案, 做了一点修正: 将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时).

No related posts.