在云彼方

首先就是发现自己对Jquery的理解还是皮毛啊，根本就没有发现它的精髓，一直都只是会用一些change、blur之类的事件+匿名函数的方式，但是上次遇到了动态添加元素并且绑定事件的情况下就没辙了，后来发现Jquery还有live这样的事件委派发方法。 当需要在页面上动态的添加元素，并且同时要给元素添加事件的时候，老的办法自然就是在HTML里面写上一大堆的onclik=、onchange=之类的，但是作为代码洁癖的我自然是不能这么写的，之前我采用的办法是把之前写的绑定事件再次绑定，但是这次我碰上了麻烦，因为我发现这样做了之后之前存在的同类元素的事件并没有消失，重复绑定之后造成了事件会重复执行。Live这样的事件委派方法就解决了这样的问题了。 先看看Live方法的定义： .live() 方法能对一个还没有添加进DOM的元素有效，是由于使用了事件委托：绑定在祖先元素上的事件处理函数可以对在后代上触发的事件作出回应。传递给 .live() 的事件处理函数不会绑定在元素上，而是把他作为一个特殊的事件处理函数，绑定在 DOM 树的根节点上。在我们的例子中，当点击新的元素后，会依次发生下列步骤： 生成一个click事件传递给 <div> 来处理  由于没有事件处理函数直接绑定在 <div> 上，所以事件冒泡到DOM树上 事件不断冒泡一直到DOM树的根节点，默认情况下上面绑定了这个特殊的事件处理函数。 执行由 .live() 绑定的特殊的 click 事件处理函数。 这个事件处理函数首先检测事件对象的 target 来确定是不是需要继续。这个测试是通过检测 $(event.target).closest('.clickme') 能否找到匹配的元素来实现的。 如果找到了匹配的元素，那么调用原始的事件处理函数。 由于只有在事件发生时才会在上面的第五步里做测试，因此在任何时候添加的元素都能够响应这个事件。 它的作用基本上和.bind() 的作用是完全一致的，只是似乎对部分事件的支持不足，但是在新版本中基本上也修正了。 $("p").live("click", function(){     $(this).after("<p>It Wor...

服务器有需要重装,因为本身有6G内存,为了能够发挥6G内存实际的功效,所以64bit的操作系统是必要的,但是之前有同事在64位的Win7上都无法正确的安装Oracle 10g,所以我特别留心的查看了一下到底需要注意哪些事情. 首先,要下载Oracle 10g的64位Windows版,但是Oracle 10g R2本身就不支持Windowns 2008R2这么新的操作系统,Oracle推荐是安装11g,如果一定要装,首先应该更改安装文件的配置文件: 位置位于/install/oraparam.ini文件.打开它,然后找到: #You can customise error message shown for failure, provide value for CERTIFIED_VERSION_FAILURE_MESSAGE Windows=5.0,5.1,5.2,6.0 改为: #You can customise error message shown for failure, provide value for CERTIFIED_VERSION_FAILURE_MESSAGE Windows=5.0,5.1,5.2,6.0,6.1 其实就是在末尾添加",6.1 "这句话,意思就是让它兼容Windows 6.1,也就是Windows 2008 R2. 然后就可以顺利开始安装了.安装的时候切记选择 不要安装实例 ,在安装过程中可能会提示你检查操作系统要求状态为"错误",无视它就行了. 安装完成之后,开始打补丁P8202632,其实就是Oracle 10g R2的10.2.0.5版升级包,官方网站其实在你下载Oracle 10g R2 for Windowns 2008 R2的版本的时候就提到过,如果你在WIndows 2008 R2下安装,你一定要升级这个包. "If installing on Windows 7 or Windows Server 2008 R2, then 10.2.0.5 patchset or higher must be used." Oracle本身提供了这个升级包的下载,但是需要用服务ID登陆后下载...我仅仅只是作为测试用户的...

一直都是用Oracle的dmp语句来导入导出整个库，但是这次为了减低工作量，采用了部分表更新的方式，所以选择了部分导出。 刚开始的时候打算像MySQL一样采用SQL语句导入导出的方式，结果也就4000多条数据而已，2M的一个SQL语句，直接让PL/SQL立扑了。看来对于Oracle这方法行不通。于是还是想到使用dmp，但是我本机只是安装了一个简化的客户端，捣鼓了半天还是没办法用dmp，于是只能在服务器上做这个操作。 语句就很简单了，导出： exp system/manager@TEST file=d:\daochu.dmp tables=(table1,table2) 导入： imp system/manager@TEST  file=d:\daochu.dmp  tables=(table1)  ignore=y 但是发现似乎只要是数据库中还存在那两张表，就没办法正确的导入进去，必须要先Drop掉，才可以顺利的导入进去，这次速度就快多了，不到10秒就完成了。 如果有多个以某个字符开头的表，比如AAA_A,AAA_B这样的，要实现批量导出可以先运行： select  table_name   from   user_tables t WHERE t.TABLE_NAME LIKE 'AAA_%' 将导出的文件形成一个CSV，然后编辑它，把它变成类似table1，table2这样的模式（正则表达式很容易做到这点） 然后为了能够顺利的导入，最好先truncate表，于是把这个文件再次操作一下变成类似 truncate table AAAA_A; truncate table AAAA_B; ... 这样的形式，然后保存为SQL文件，例如1.sql 然后在字符界面下运行： sqlplus  system/manager@TEST   @D:\1.sql 批处理执行SQL文件即可，然后再导入表，就不会报告那么多错误了

今天数据库日志满了,然后同事删除了一部分日志,空出来一部分的磁盘空间,但是却发现数据库怎么都起不来,一直报告ORA-01033错误, ORACLE initialization or shutdown in progress. 强制Shutdown immediate之后再Startup结果报告: ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: 'xx\redo1.log' 上网搜索发现是数据库日志读取出问题了. 于是开始检索解决的办法: 先查询出错的这个Log 1是否是当前使用中的日志: SQL>select group#,sequence#,archived,status from v$log; 得到的结果是 GROUP# SEQUENCE# ARCHIVED STATUS ---------- ---------- -------- ---------------- 1 1 NO INACTIVE 2 2 NO INACTIVE 3 3 NO CURRENT 解决的办法是: alter database clear unarchived logfile group 1; 然后很正确的提示了 Database Altered. 之后再Shutdown一次再Startup一次就好了. 但是值得注意的是: 1、这种办法恢复的数据库是一致的不完全恢复，会丢失当前联机日志中的事务数据 2、这种方法适合于归档数据库并且有可用的数据库全备份。 3、恢复成功之后，记得再做一次数据库的全备份。 4、建议联机日志文件一定要实现镜相在不同的磁盘上，避免这种情况的发生，因为任何数据的丢失对于生产来说都是不容许的。 但是我们局内的数据库是无所谓数据一致性的,因为并没有那么强的实时性的要求.于是很顺理成章的就完成了了事~ 相关材料引用自: http://www.cnblogs.com/jimeper/archive/2008/04/14/1153234.html