ZZzz……

#开放端口
vi /etc/sysconfig/iptables
#重启防火墙
service iptables restart

#ssh
vi /etc/ssh/sshd_config
service sshd restart

#oracle 修改内核坏了处理
create spfile='/oracle/product/11.2.0/db_1/dbs/spfileorcl.ora' from pfile='/oracle/admin/orcl/pfile/init.ora.1025200916059';

#挂载USB
mount -t vfat /dev/sda1 /media/usb

#安装rpm
rpm -Uvh xxx.rpm

*****************************************************************
*  更改 Server 端字符集步骤方法(ZHS16GBK --> UTF8) *
*****************************************************************

cmd下用 sqlplus scott/tiger

在sqlplus窗口下才能用 conn scott/tiger

select * from nls_database_parameters

SQL>

1.在SQL*PLUS 中，以DBA登录
conn 用户名 as sysdba
2.执行转换语句：
SQL>

将数据库启动到RESTRICTED模式下做字符集更改：
SQL> conn /as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount exclusive;
ORACLE instance started.
SQL> ALTER SYSTEM ENABLE RESTRICTED SESSION;
System altered.
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
System altered.
SQL> ALTER SYSTEM SET AQ_TM_PROCESSES=0;
System altered.
SQL> alter database open;
Database altered.
SQL> ALTER DATABASE character set INTERNAL_USE UTF8;
Database altered.
SQL> select * from v$nls_parameters;

略
19 rows selected.
重启检查是否更改完成：
SQL> shutdown immediate;
Database closed.

Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

我们看到INTERNAL_USE提供的帮助就是使 Oracle数据库绕过了子集与超集的校验.
这一方法在某些方面是有用处的，比如测试；应用于产品环境大家应该格外小心，除了你以外，没有人会为此带来的后果负责: 结语(我们不妨再说一次):
对于DBA来说，有一个很重要的原则就是:不要把你的数据库置于危险的境地！
这就要求我们，在进行任何可能对数据库结构发生改变的操作之前，先做有效的备份，很多DBA没有备份的操作中得到了惨痛的教训 .

*****************************************************************
*  更改 Client 端字符集步骤方法 *
*****************************************************************
在 /home/oracle与 /root用户目录下的.bash_profile中 添加或修改 export NLS_LANG="AMERICAN_AMERICA.UTF8" 语句
关闭当前ssh窗口。
注意 NLS_LANG变量一定要配置正确否则会引起sqlplus 失效

写了一个J2ME程序，代码量不大，但数据量很大，用ReroGurad混淆时，总是不成功

后来先去掉数据，混淆代码，将混淆后得到的jar文件解压，放到classes目录，再执行打包过程，就KO了，注意此时不要选择混淆了

在sybase上执行如下SQL：

select count(distinct field1) from table1，其中字段field1的类型为varchar(1000),执行时SQL报错如下：

The current query would generate a key size of 1000 for a work table.  This exceeds the maximum allowable limit of 600.

当前表table1中是没有记录的，

对另一个表，select count(distinct field2) from table2，表中field2的类型也为varchar1000，但是却可以执行，十分的不解，后来将查询1的语句修改成如下：

select count(distinct convert(varchar(200), field1)) from table1,就可以了，table1中的field1设置为varchar1000是通用的表，table1是在业务过程中动态添加的，但根据当前业务，该字段实际使用量不超过200，

--------------------------------------------------------------------------------------------------

在网上找到相关资料

Solution Title: Native Error code: 414  - key size of 765 for a work table. This exceeds the maximum allowable limit of 600.

asked by alitor99 on 11/01/2004 10:04AM PST

I have a stored procedure querying a Sybase database. The SQL is : SELECT     tblLDAP.UserAutoId, tblLDAP.FirstName, tblLDAP.LastName FROM     (tblContacts INNER JOIN tblLDAP      ON tblContacts.UserId = tblLDAP.UserAutoId) INNER JOIN LDAP_CAD_Buildings      ON tblLDAP.Building = LDAP_CAD_Buildings.Building WHERE LDAP_CAD_Buildings.Arena_id = @strRegion GROUP BY     tblLDAP.UserAutoId, tblLDAP.FirstName, tblLDAP.LastName ORDER BY     tblLDAP.LastName Just recently it is generating the following error: Sybase ADO Provider error '80004005' [Native Error code: 414] [DataDirect ADO Sybase Provider] The current query would generate a key size of 765 for a work table. This exceeds the maximum allowable limit of 600. The query works in a blink in both SQL Server and Access, but not in Sybase. All that has changed recently is that there has been an increase in records in the table tblLDAP from 32,000 records to 72,000. This would not have affected the output of the recordset which is dependant on tblContacts. tblContacts holds 534 records and LDAP_CAD_Buildings has 256 records. The SQL produces a recordset of only 60 records If I remove the aggregation the procedure will work. What is causing this problem in Sybase and how do I correct it? Comment from Joe_Woodhouse Date: 11/01/2004 04:43PM PST Comment Ok, the problem here is that, as the error suggests, the query needs to generate a worktable to hold some intermediate results. In your case this seems to be for the GROUP BY clause. Sometimes the optimiser creates temporary indexes on worktables. Sybase has a limit on how large an index can be in bytes. The error is telling you that the optimiser needs to create an index that is too wide and exceeds this limit. What's interesting is that you say this has previously worked and has only stopped behaving recently. This says to me that there is a different query plan being generated and something in the new way of how the optimiser wants to do things is breaking the key size limit. It is certainly possible that some changes in row sizes could affect the query plan in terms of join orders etc. I wouldn't think it would affect the GROUP BY, so I admit I'm scratching my head a bit there. Can we see some more information? It would help us to see the exact schema/structure/definition of the tables involved. There's probably no point asking you to generate a "SHOWPLAN" output (which documents the query plan chosen) since it's dying before it finishes optimising. If you have the option, try temporarily deleting rows to return to your old rowcounts and see if it works there? Comment from alitor99 Date: 11/02/2004 01:19AM PST Author Comment Joe, Your comments got me thinking and I was able to run SHOWPLAN  by using set showplan on set noexec on and then adding the text of the stored procedure. This gave me the following results: QUERY PLAN FOR STATEMENT 1 (at line 1).     STEP 1         The type of query is SET OPTION ON. QUERY PLAN FOR STATEMENT 2 (at line 2).     STEP 1         The type of query is SET OPTION ON. QUERY PLAN FOR STATEMENT 3 (at line 3).     STEP 1         The type of query is SELECT (into Worktable1).         GROUP BY         Evaluate Grouped COUNT AGGREGATE.         FROM TABLE             tblContacts         Nested iteration.         Index : idxUserId         Forward scan.         Positioning at index start.         Index contains all needed columns. Base table will not be read.         Using I/O Size 16 Kbytes for index leaf pages.         With LRU Buffer Replacement Strategy for index leaf pages.         FROM TABLE             tblLDAP         Nested iteration.         Index : idxLdap         Forward scan.         Positioning by key.         Keys are:             UserAutoId  ASC         Using I/O Size 2 Kbytes for index leaf pages.         With LRU Buffer Replacement Strategy for index leaf pages.         Using I/O Size 2 Kbytes for data pages.         With LRU Buffer Replacement Strategy for data pages.         FROM TABLE             LDAP_CAD_Buildings         Nested iteration.         Table Scan.         Forward scan.         Positioning at start of table.         Using I/O Size 2 Kbytes for data pages.         With LRU Buffer Replacement Strategy for data pages.         TO TABLE             Worktable1.     STEP 2         The type of query is INSERT.         The update mode is direct.         Worktable2 created, in allpages locking mode, for ORDER BY.         FROM TABLE             Worktable1.         Nested iteration.         Table Scan.         Forward scan.         Positioning at start of table.         Using I/O Size 16 Kbytes for data pages.         With MRU Buffer Replacement Strategy for data pages.         TO TABLE             Worktable2.     STEP 3         The type of query is SELECT.         This step involves sorting.         FROM TABLE             Worktable2.         Using GETSORTED         Table Scan.         Forward scan.         Positioning at start of table.         Using I/O Size 16 Kbytes for data pages.         With MRU Buffer Replacement Strategy for data pages. Does this help? Accepted Answer from Joe_Woodhouse Date: 11/02/2004 03:10AM PST Grade: A Accepted Answer On its own, sadly no, that doesn't help much, as it doesn't tell us which worktable is unhappy about a key size. On the other hand if you were able to replicate your earlier experience (with smaller rowcounts) and get a SHOWPLAN from that, it could be helpful to compare the differences. Did any indexes change recently? I notice the showplan saying it used a covered non-clustered index. This might be a large index containing other columns not needed for this query, and the limit might be too large. Oh, I just thought of another reason for why this might have changed - if these columns are varchars, it might be that their maximum width exceeds the 600 byte limitation, but you were never affected by this earlier because none of your columns were filling up the varchars. Can we get some more information, the results of: sp_help tblLDAP go select max(datalength(UserAutoId)),           max(datalength(FirstName)),           max(datalength(LastName)) from   tblLDAP go (It will table scan, sorry.) It could be that one or more of the new rows causes the GROUP BY expression to be too large. Lastly, try removing the GROUP BY altogether and replacing it with a DISTINCT: SELECT     DISTINCT tblLDAP.UserAutoId, tblLDAP.FirstName, tblLDAP.LastName FROM     (tblContacts INNER JOIN tblLDAP      ON tblContacts.UserId = tblLDAP.UserAutoId) INNER JOIN LDAP_CAD_Buildings      ON tblLDAP.Building = LDAP_CAD_Buildings.Building WHERE LDAP_CAD_Buildings.Arena_id = @strRegion ORDER BY     tblLDAP.LastName It doesn't seem you're using the GROUP BY for any aggregate functions, so all it will be doing is removing duplicates. Speaking of which, a column name like "UserAutoId" sounds like it would probably be unique - are you sure any duplicates are possible in this query? If not, then neither a GROUP BY nor a DISTINCT are needed here... Good luck! Comment from alitor99 Date: 11/02/2004 07:32AM PST Author Comment Joe, Replacing GROUP BY with DISTINCT did the trick, albeit rather slowly. There were duplicates created through the tblContacts. This was perfectly correct becuase they detailed Contacts for various functions and one individual could take on many roles. Looking through your comments, I think the error arose when I started updating the tblLDAP through SQL Server. Fields were being created as varchar (255). Thus the 3 fields aggregate to 765! Now, through reverse engineering, I understand the error message - after the problem is fixed. Thanks very much for your help Comment from Joe_Woodhouse Date: 11/02/2004 01:06PM PST Comment You're welcome, glad I could help.

新华字典手机版，共收录汉字7025个，根据汉字可查询到英文信息，成语等，检索方式如下
1. 按字查询
2. 按拼音查询
3. 按部首查询
4. 按笔画查询

http://www.waplife.cn/software/view.asp?sId=CDict

在手机上检索公交线路，支持两种方式：

1.根据起点站或终点站检索线路（支持换乘），站点支持模糊输入

2.根据线路号检索公交线路信息 所有公交数据均再本地手机上，无需GPRS连接 

 

 

 

 

 

需要手机支持MIDP2.0

 在手机上检索火车时刻表

1. 支持站点模糊输入
2. 支持站、站站、线路查询
3. 所有数据均在本地手机，无需GPRS连接
4. 优化了数据初始化速度和查询速度 

http://waplife.cn/software/view.asp?sId=mtrain

某些原因，譬如系统突然掉电，导致sybase的异常关闭，可能会使sybase受损而无法启动，如果近期没有对数据库作dump备份，那头就要大了，不过可以尝试通过以下方法进行数据恢复

需要两个前提条件
1。需要得到sybase的数据库所在的设备文件，在win系统下，这些设备文件默认存在系统盘的/WINNT/System32目录下（实在是想不通sybase怎么会默认把设备文件放在这里，系统分区一般都不大，很容易占满分区导致空间不足），在HP-UNIX下，设备文件默认存放在Sybase安装目录的ASE-12_5/install/目录下，其中12_5是当前sybase的版本号。
2。需要知道数据库的数据区和日志区的大小，及所在的设备。比如数据库ABC，在DeviceA上建了数据区，大小100M。在DeviceB上建了日志区，大小为50M等。

下面开始恢复
1。重新安装Sybase数据库
2。创建设备，注意每个设备的大小必须和原先的完全一致，如果忘记了原先的设备大小，请参看原先Sybase的启动日志文件，在日志文件中详细描述了每个设备的名称，设备大小，设备号，设备路径等，日志文件存放在Sybase的安装目录ASE_12-5/install目录下
3。创建数据库，注意每个数据库的数据区和日志区大小，及其所在的设备，必须和原先的完全一致，否则数据无法恢复（如果忘记了数据库数据区和日志区的大小，及其所在的设备，我现在也不知道怎么办，没有在sybase中找到可以获取这些信息的文件）
3。备份步骤2创建的设备文件，用原Sybase的设备文件覆盖步骤2的设备文件
4。启动SybaseSqlServer，Online数据库，谢天谢地，赶紧DUMP备份数据库吧

1。建议使用Hiberante进行Session和Transaction的管理

    将需要进行事务的多个原子DAO设置到Service里，在Service层进行事务控制和会话控制

    设置一个基础的dao，即baseDAO 且继承之HibernateDaoSupport，而业务对象原子DAO，持有一个baseDAO的引用，通过setter注射设置到业务DAO中

    多个原子DAO，通过setter注射到Service层。

2。在显示层，一对多显示时，提示Session关闭的问题

    两个解决方法：
    1）在one－to－many设置lazy＝false，即不延迟加载子对象，但这样可能会带来性能的问题，特别是父子关系模型是树状结构时。
    2）使用Hibernate提供的openSessiojnInView技术，即在视图层开启和关闭Session，在service层进行Transaction管理，这个较为简单，只需要设置一个filter即可，在web.xml中配置

<filter>   <filter-name>hibernateFilter</filter-name>   <filter-class>org.springframework.orm.hibernate.support.OpenSessionInViewFilter</filter-class>  </filter>  <filter-mapping>   <filter-name>hibernateFilter</filter-name>   <url-pattern>/*</url-pattern>  </filter-mapping>

需要注意的是，OpenSessionInViewFilter在调用过程中，需要引用Spring的ApplicationContext，而该对象实例必须是保存在ServletContext中的，因此需要在web.xml中处始化Spring的环境，增加配置如下：

<context-param>              <param-name>contextConfigLocation</param-name>              <param-value>/WEB-INF/spring/applicationContext-hibernate.xml</param-value>         </context-param>      <servlet>      <servlet-name>context</servlet-name>              <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>              <load-on-startup>1</load-on-startup>      </servlet>

其中

<servlet-name>context</servlet-name>              <servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>              <load-on-startup>1</load-on-startup>      </servlet>

表示在启动时，进行Spring环境的处始化，因此以后如果要引用Spring中的某个bean实例

如下代码即可

org.springframework.context.ApplicationContext ctx = (org.springframework.context.ApplicationContext)application.getAttribute(org.springframework.web.context.WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);

然后调用ctx.getBean返回bean实例

Spring不只是AOP和IOC，更提供了大量的可重用技术，譬如request中的重设编码，Spring提供了相应的Filter：org.springframework.web.filter.CharacterEncodingFilter 通过直接配置，即可解决Web应用中POST的中文乱码问题，JMS的org.springframework.jms 包  JavaMail的org.springframework.mail包等等，更多的，请参看Spring的reference，

Spring能改善现有代码结构，大量的减少hard code，加快开发进度；

一直有一种感觉：系统的构建是类似的搭积木
       

        将原有的应用从tomcat4.X升级到5.X，原来通过get方式传递的中文字符，出现了乱码，在server.xml的http连接配置connector中添加URIEncoding="GBK"即可

       但不是最佳方法，限制了服务器端编码

导出

   bcp dbName..tableName out filePath -c -t@ -Jcp936 -Ppassword -Uuser -SserverIP

导入命令

   bcp dbName..tableName in filePath -c -t@ -Jcp936 -Ppassword -Uuser -SserverIP

  -c表示以char方式导出数据，也可以用-n，表示以二进制方式导出

  -t 表示自定义字段连接符，这里是@，必须保证字段值里不含有@，sybase默认是空格的

  -J表示指定导出数据的编码格式，在win32下一般是cp850，而在unix下，一般是iso8859_1

更多的参数说明参看sybase手册

SYBASE公司建议我们将现在使用的数据
库的字符集cp850换为能够很好的处理简体中文和英文的字符集cp936.

企业类 Enterprise 含有N个产品类Products

public class Enterprise {

 private java.util.Set products

}

下面查询所有的产品类别为A，并且企业名称是E 的企业

select distinct e form Enterprise as e inner join e.products as p where e.name='E' and p.type='A'

注意，一定要加distinct

如果使用了类的基础,如下

public class Parent{

}

public class Child extends Parent{

}

那么对于如下的HQL查询

select obj from package.Parent as obj .....

Hibernate会翻译成如下

select obj from package.Childs......

十分不解Hibernate是如何处理的,需要参看源代码作分析

另一个问题:

select obj from pckage.Parent as obj .....

最终查询的结果数量是实际的两倍,因为Hibenate查询时,是对子作查询的,而父亲也是存在的,于是实际数量=父亲数量+孩子数量