记录点小P事

够麻烦的

create procedure dbo.sp_string_split

@param_string varchar(100),

@split varchar(2)

as

    declare @idx int

    declare @split_length int

    declare @last_string varchar(100)

    declare @curr_string varchar(100)

begin

    create table #split_str(str varchar(100) null)

    set @last_string= @param_string

set @idx=CHARINDEX(@split,@last_string)

set @split_length = char_length(@split)

if(@idx>0)

begin

   while(@idx>0)

   begin

  set @idx=CHARINDEX(@split,@last_string)

       if(@idx>0)

       begin

           set @curr_string = substring(@last_string,1,@idx-@split_length )

           set @last_string = substring(@last_string,@idx+@split_length ,100)

       end

       else begin

        set @curr_string = @last_string

       end

            insert into #split_str(str) values(@curr_string)

  end

end

else begin

insert into #split_str(str) values(@last_string)

end

--show data

select * from  #split_str

end

test:

exec dbo.sp_string_split   '123|333|888', '|'

平时设置个JAVA_HOME一般的做法是在~/.bashrc或者~/.bash_profile里面加上个export就好了。

加完之后source一下，然后按照网上大部分的说法回显一下就ok了：

echo $JAVA_HOME 

今天遇到的情况是echo $JAVA_HOME 每次都有值，但是启动tomcat每次都报一副死相的报JAVA_HOME没设置，找了半天才发现系统里的环境变量被设置成这样了：

JAVA_HOME=/opt/java

但是没有export

这种情况下echo $JAVA_HOME 是有值的，- -!

所以保险的验证环境变量是否正确设置的办法应该是

export|grep JAVA_HOME

一下看看是否有值。

---EOF

sonar管理员密码重置：

登陆：

mysql -u sonar –h localhost –p

改：

update users set crypted_password = '88c991e39bb88b94178123a849606905ebf440f5', salt='6522f3c5007ae910ad690bb1bdbf264a34884c6d' where login = 'admin'

见:http://docs.codehaus.org/display/SONAR/Frequently+Asked+Questions#FrequentlyAskedQuestions-Ilosttheadminpassword

1.没有权限

a)需要检查/etc/cron.d/cron.allow中是否配置了该用户，如果没有则加入

b)检查/etc/cron.d/cron.deny中是否配置了该用户，如果有则不能访问

2.报bad user

在/var/cron/log中看到如下报错:

>  CMD: echo "Good morning." >> /opt/sybase/aaaa.txt

>  sybase 4999 c Tue Oct 18 11:24:00 2011

! bad user (sybase) Tue Oct 18 11:24:00 2011

放狗看到这里说有可能是帐号被锁了需要改一下密码才行，

马上改密码试验，发现设定的任务运行正常了。

不过忘了看看是不是因为帐号被锁了。Locked account? ("*LK* in password field; or possibly it timed out)

记下备忘，下次遇到用 cat /etc/shadow看看是不是因为锁住了。

悲摧的4.1太惊喜了,N久以前某位同志埋下的雷居然在节日爆了出来...居然在一张有1亿多数据的表里做了一个全表扫描的select.于是tmpdb被撑爆,数据库无法响应正常的请求.

借助万能的google和sybase同志的支持，俺这只菜鸟只能硬着头皮上了.

基本思路，把一定范围内的数据insert到备份表，删除原来的数据，直到没有符合查询范围的数据为止.

修改了一下存储过程后暂时解决问题了，测试了800w数据迁移没有问题

--sybase用proc迁移大数据量到备份表操作

create procedure INSERT_AND_DELETE

    @insert_sql  varchar(5000),

    @delete_sql  varchar(5000),

    @row_count   int

as

begin

declare @rc varchar(19) 

select @rc=convert(varchar,@row_count) 

print  @insert_sql

    print  @delete_sql

    print  @rc

    set rowcount @row_count

    begin tran

    exec(@insert_sql)

    exec(@delete_sql)

    while ( @@rowcount !=0 )

    begin 

    commit tran

    begin tran

    exec(@insert_sql)

    exec(@delete_sql)

    end

    commit tran

    set rowcount 0

end

go