2010-03-20 Sat
现在下载的DataCopy版本中多出了两个选项, 他们是: conflict(冲突解决)和filler(过滤列). 命令行中的简单解释如下所示, 不能使人很清楚了解其函义, 需要再特别说明一下.
* conflict= conflict columns for update on target table.
* filler = filler columns (exclude columns) for target table.
conflict用于简单解决双向同步时的冲突, 我们可以在被复制的表上加上冲突解决列, 通常是时间或单向增长的列, 在同步时, 更新时要求源端的值一定要大于目标端的值, 以便在双向同步时保留最新的列. 比如在员工表(SCOTT.EMP)中增加一列最后修改时间(LAST_MODIFY), 则可以在DataCopy同步时, 加入conflict参数, 如下所示.
datacopy ... table=emp sync=update conflict=last_modify unique=empno
在这个设置下, 在目标端同步时用的更新SQL中就会加入如下WHERE条件, 对于DELETE操作也一样会加入同样的WHERE条件. 当端源的最后修改时间比目标端小时, 记录才会被更新掉.
UPDATE EMP SET ENAME=:ENAME, ......
WHERE EMPNO=:EMPNO AND LAST_MODIFY <= :LAST_MODIFY
filler用于快速去掉一些不想同步的列, 选项名称取自sqlldr工具, 这个选项只影响INSERT(包括Direct Path Load)及UPDATE语句. 假如我们不想同步员工表(SCOTT.EMP)的SAL和COMM字段, 则可以用FILLER来去掉这两个字段, 否则需改写源端SQL语句才能实现.
datacopy ... table=emp sync=update unique=empno filler=sal,comm
正在思考如何加入一些公共性的需求到这个小工具里, 如果你有什么想法, 可以告诉我. 另外进行了详细的测试, 目前的程序在Direct Path Load时不能处理ROWID/UROWID类型和TIMESTAMP WITH LOCAL TIME ZONE类型, 后者还会使程序中途退出运行.
Relative Posts:
2010-03-19 Fri
今天在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的速度.
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的相关操作.
这一点包含普通的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.
在一个测试环境进行统计信息收集，结果提示被锁定：
SQL> exec dbms_stats.gather_table_stats('erp','balance');
BEGIN dbms_stats.gather_table_stats('cnderp','balance'); END;*
ERROR at line 1:
ORA-20005: object statistics are locked (stattype = ALL)
ORA-06512: at "SYS.DBMS_STATS", line 13056
ORA-06512: at "SYS.DBMS_STATS", line 13076
ORA-06512: at line 1
Elapsed: 00:00:00.87
可以用以下命令解除锁定：
SQL> exec dbms_stats.unlock_table_stats('erp','balance');
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.47
SQL> exec dbms_stats.gather_table_stats('erp','balance');PL/SQL procedure successfully completed.
Elapsed: 00:04:37.31
解除都整个schema对象的锁定
SQL> EXEC DBMS_STATS.unlock_schema_stats(ownname => 'erp');
PL/SQL procedure successfully completed.
统计信息被锁定的原因有多种：
Symptoms
---------
Either of the following two error messages are signaled:
1. ORA-38029: object statistics are locked
2. ORA-20005: object statistics are locked (stattype = ALL)Cause
---------
Possible Cause 1:
DBMS_STATS.LOCK_[SCHEMA|TABLE]_STATS has been used to lock statistics on the table.Possible Cause 2:
Using import (imp) or data pump import (impdp) to import a table without data results in the table's statistics being locked in 10gR2.Possible Cause 3:
After an IMPORT is finished for which ROWS=N, the statistics for all tables imported will be locked.
Part Number B14233-04 Database Readme 10g Release 2 (10.2) (39.5 Original Export/Import)Possible Cause 4: If the table is a queue table then the statistics are intended to be empty and locked so that dynamic sampling will be used due to the table's volatility. During an upgrade to 10gR2 statistics on queue tables are deleted and then locked. In 10gR2 when a queue table is created statistics are locked while still empty.
Solution
---------
If the table is a queue table then the statistics should remain empty and locked so that dynamic sampling is used due to the volatility of queue tables. If the table is not a queue table, unlock the statistics using DBMS_STATS.UNLOCK_[SCHEMA|TABLE]_STATS or gather statistics on the table using DBMS_STATS.GATHER_[SCHEMA|TABLE|INDEX]_STATS and the force=>true parameter.To prevent import (imp) from locking the table's statistics when importing a table without therows (rows=n), use statistics=none. To prevent data pump import (impdp) from locking the table's statistics when importing a table without the rows (content=metadata_only), use exclude=(table_statistics,index_statistics).
我这里统计信息被锁定的原因就是在imp数据的时候没有导入约束，然后通过imp加rows=n参数又导入了约束信息后导致的。
但是奇怪的事情是，在完成了统计信息收集后，通过autotrace查看sql语句的统计信息时，统计信息显示的都是0：
SQL> connect sys/sys as sysdba
Connected.
SQL>
SQL> shutdown immediate
SQL> startup
ORACLE instance started.
Database opened.
SQL> connect erp/erp
Connected.SQL> set timing on
SQL> set autotrace on statistics
SQL> select count(*) from balance;COUNT(*)
----------
19548622Elapsed: 00:00:01.31
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
0 bytes sent via SQL*Net to client
0 bytes received via SQL*Net from client
0 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
尝试了很多种办法也没用：
SQL> drop table plan_table
2 /Table dropped.
Elapsed: 00:00:02.83
SQL> @?/rdbms/admin/utlxplan.sqlTable created.
Elapsed: 00:00:00.26
SQL> analyze table balance estimate statistics;
Table analyzed.
开来这个问题有待进一步研究。
2010-03-18 Thu
原文：Sharing the verification love
转载自：谷歌中文网站管理员博客
发布时间：2010年3月2日，星期二，下午4:47
网站站长级别：所有
标签：Google站长工具
任何事情，只要能与朋友分享就会变得分外有趣！我们的“网站站长工具”里的网站验证页面添加了全新功能，使您能够更方便地将朋友验证为网站站长之一。
过去，如果有一个以上的用户需要被验证成为网站站长，那么所有这些用户都需要通过元标记或HTML文件验证程序。某些情况下，这可能没有什么大不了；但很多时候，却会为用户带来极大的不便。比如，当有20个人需要验证成为网站站长呢？添加20个元标记或HTML文件将耗费大量时间。现在，我们推出了全新的验证授权功能，使新站长验证变得易如反掌。
一旦您通过验证并成为网站站长，您就可以浏览“验证详细信息”页面（在网站站长工具或验证页面上有相关链接）。该页面会显示网站的信息以及其他通过验证的站长列表。在站长列表底部，您会看到“添加用户……”按钮。点击该按钮，输入用户的电子邮件地址，该用户即刻就能通过验证，成为网站的站长。您也可以随时点击“详细信息”页面上用户电子邮件地址旁的“取消验证” 按钮移除用户。
在使用这一功能时，您需要注意以下事项：首先，每个网站至少要有一个通过直接方式（通过元标记或HTML文件）获得验证的站长。如果所有通过直接方式完成验证的站长被取消验证，其授权的站长也将被取消。第二，您只能授权拥有Google账户的用户为站长。最后，请记住，您授权的所有站长都拥有与您一样的权限。他们可以授权更多的站长，提交URL移除请求并在网站站长工具中管理网站链接。因此，请仅授权您信任的用户为站长！
如果您的网站需要验证多个用户为站长，那么希望这篇文章能为您带来方便。最后，如果您有任何疑问，欢迎您随时访问我们的网站管理员帮助论坛。
周末去常熟，特地走访了钱谦益和柳如是两位古人墓。
真实的柳如是，如果活在现代，基本是一个有追求有想法的女文青，当然，也可以叫作女愤青。相貌清秀，个子不高，和李宇春一样，善女扮男妆，倒也很帅，与朋友见面，喜抱拳招呼，称兄道第，神情洒落，有林下风气。这样的女子不要说古代，即便是现在，也是个宝。
和大多女文青女演员喜欢“扑”名家名师一样，柳如是也渴望着能得到大师的关照，而钱谦益就是当时中国文坛名望最高的领袖级人物，而且家里很有钱，谁要是能傍上钱老师，想不红都难。于是，23岁的柳如是就去了。
去哪个地方呢？换作现在，肯定是北京了。据说现在北京的女文青扎堆扎堆的，而老头子就那么几个。当年柳如是要去的地方是江苏常熟，钱老师家住常熟半野堂。没有邀请，也没有谁推荐，柳如是就去了，乘一扁舟，著男子服，幅巾弓鞵，风度翩翩。可以想象一下，如果是一幅画面，应该还是很美的。
七溪流水皆通海，十里青山半入城。那个时候的常熟，小船大概可以直接开到钱老师家的门口。柳如是抬头见半野堂到了，于是上岸，敲门。钱老师正在家看书，门一开，见是一俊俏后生，神情帅气，可眉宇间总感觉又有那么一丝娇媚，这是谁呢？
柳小姐一低头，举起两根手指作V字状，然后眼梢45度角往上一翘，说，你猜啊？
钱老师难能猜得出呢？摇摇头。
柳小姐嘴巴一撅，人家要你再猜一次嘛。
钱老师心想这孩子怎么如此调皮呢，左看看，右看看，然后两只眼睛落在了对方似乎微微隆起的胸部上，更加迷惑了，这到底算有，还是没有呢？真不认识。不过还是把她请进了屋。
一进屋，柳小姐便把外衣给脱了下来，露出了女儿身。钱老师简直不敢相信自己的眼睛，站在自己面前的，还真是一个女的，上上下下，那么的标致，那么的具体。而等对方说出她叫柳如是后，我们德高望重的钱老师乐坏了，差点没能当场把握住。柳小姐，您来寒舍有什么事吧？
柳小姐说，也没什么大事，钱老啊，我就是特崇拜您，想来看看您，并请教如何才能写得一手好诗。
不错啊，小柳，你很好学嘛，钱老说。
于是，他们就开始谈诗，谈音乐，谈梦想。先是坐着谈，然后站着谈，走着谈，从白天一直谈到黑夜，最后谈着谈着就谈到了床上……□□□□□（此处省略二百八十六个字）。第二天一早……□□□□□（此处再省略三百六十个字）
像只小鸟立在枯木的枝头，一粒泪珠从柳小姐的眼角流了下来。钱老一惊，问小柳，你怎么了？柳小姐说，钱老，我是不是一个坏女人啊？钱老说，不是啊。小柳说，哪有一个女的刚和别人认识，就和他上床的呢？我是不是太随便了啊？钱老说，这都是俗人的理论，咱们可不能这样想，再说了，咱们是有感觉的啊。
有感觉是真的，一个是自己的偶像，一个是自己梦中的美人，今日碰撞在一起，能没感觉？然而，习惯性地，柳如是又想起了自己的这些年来的经历，二次婚恋，三入娼门，心里不免又是一阵酸痛，情不自禁地抽泣起来。
我会对你负责的，如是。钱老紧紧地搂住了小柳。虽然这个女人有着这样那样的问题，可人家毕竟是个80后，就像后人李敖评价杨翁恋一样，对每位年逾花甲的老人来说，年轻女孩都是他们渴望而不可及的梦想。而现在，这个梦想犹如天上掉下的馅饼，突然砸在了他的怀里。他愿意给她保护，给她温暖。不仅仅因为她是一个尤物，还因为她还是一个孩子。他甚至有点感激她，是她点燃了他生命中那些早快湮灭的激情。
如果我愿意嫁给你，你会娶我吗？我知道你是有妻室的人，可我只想做一个小。性格爽直的柳如是说。
当然愿意，我怎么会不愿意呢？钱老说，从今往后，你就住下来吧。
柳如是在钱家住了几个月，然后大家相约来年结婚。
说到做到。第二年，不顾家人的反对，不顾社会舆论的压力，一代文豪钱谦益在常熟正式迎娶了当红名姬柳如是。这一年，钱谦益六十岁，柳如是才二十四岁。
说到这里我们必须说说“爱情”二个字。我曾在一篇文章中讲过，“爱情”是文学家发明的词汇，世上本无爱情，说的人多了便有了爱情。如果没有“爱情”一说，那么，我们就很难解释这个世界上男女之间的很多事情。以钱谦益当时的社会地位，一位退居二线但依然有着巨大影响力的老同志，文化部的老部长，怎么会和一名妓女结婚呢？即便要找，最起码也要找个演员吧。这个魄力真不是一点点，换作现在，我相信我们的老同志是没人能做到的，玩么想玩的，一到关键时刻就成了缩卵，比如戏剧学院的某院长，比如同样是德高望重的赵老师，黄老师。而更能显出钱谦益作为一个男人具备大爱胸襟的是，后来，钱老复出，去北京从政（此时已是清朝），有人向钱老打小报告，说留在南京的柳如是和别的男人勾勾搭搭，钱老不但没有生气，还很能理解地说，这年头连士大夫都不能守全节，我们凭什么去要求一个女人守身如玉呢？
这是何等的气量与高度啊！所以，我对后来有人批评钱谦益在爱国的气节上连一个妓女都不如的说法，是不敢苟同的。有些话人家早就自己先说了，钱谦益思想的复杂性绝不是普通人能理解的。
有情人终成眷属。但光成眷属还不够，还需长寿。好在钱氏活了八十多岁，他们还是共同生活了二十多年。
如很多世俗故事一样，钱去世后，为了遗产，钱氏家人把柳如是告上了法庭。几个月后，柳如是选择了自杀。朋友们把柳氏葬在了离钱墓不远的一角。明末清初，这出中国爱情史上最富争议的故事，以典型的“不求同年生，但求同年死”“不求同衾，但求能相望”的方式划上了一个完整的句号。
而要想了解文学史和政治史上的柳如是和钱谦益，请读陈寅恪先生的大作《柳如是别传》。
