Love Sun

11.2.0.1.0 exp ORA-01455: converting column overflows integer datatype 错误处理

环境:客户端和服务器端在一台机器,都是11.2.0.1.0 用exp 导出报错。 exp csc/passwd file=csc_.dmp log=csc_.log owner=csc 报错如下: . exporting synonyms . exporting views EXP-00056: ORACLE error 1455 encountered ORA-01455: converting column overflows integer datatype EXP-00000: Export terminated unsuccessfully 解决方法,分析一下需要导出的用户 SQL> exec dbms_stats.gather_schema_stats(ownname => ‘csc’,estimate_percent => 1); 再执行exp,一切ok。 refer to:http://blog.itpub.net/25027760/viewspace-775651/ dbms_stats.gather_schema_stats官方文档

Linux下,多线程程序死循环问题调试

当你的软件在某个时刻停止服务,CPU占用达到100%+,这种问题一个可能的原因是产生了死循环,假设程序某处存在潜在的死循环,并在某种条件下会引发,本文以一个示例来定位出现死循环的位置。 当程序某处存在死循环,通常定位问题及缩小范围的方法是,在可疑的代码处加log,或者注释掉可疑代码,这对于容易重现问题的程序来说还好,但对于“偶尔”才会产生问题程序却很难调试,因为我们很难重现程序故障。本文所述的调试过程正是在这种情况下,假设问题已经出现,我们要求环境保护现场,即出问题的程序还在运行中。 1.我们首先要知道是哪个线程出了问题: 首先查一下出问题进程的pid,例如

然后top命令查看线程信息:

从上面可以看出,出问题线程PID为11073 2.接下来,我们用gdb来attach目标进程 执行:

在gdb中,列出线程状态:

gdb已经列出了各线程正在执行的函数,我们需要更多信息,记住11073对应的行首标号,这是gdb为线程分配的id,这里为2,然后执行切换:

bt一下:

来看一下101行的代码:

现在我们定位到了出问题的代码位置,这里的循环只用来演示的。 最后别忘了detach refer to:http://www.cppblog.com/elva/archive/2010/08/02/121943.html

定位Linux下定位进程被谁KILL

今天上午有个同事问,自己的进程被莫名其妙的杀死了,想知道是被那个进程误杀了。 第一个想法是用kernel hack系统调用的方式,刚打算翻出hook的代码,想起了貌似audit不就是干这个的吗 #auditctl -a exit,always -S kill #auditctl -l #tail -f /var/log/audit/audit.log 加上这个规则后,再用kill杀死一个进程就可以看到是谁干的了。 type=SYSCALL msg=audit(1446528422.179:18502): arch=c000003e syscall=62 success=yes exit=0 a0=53f a1=8 a2=0 a3=53f items=0 ppid=1427 pid=2613 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=1 comm=”bash” exe=”/usr/bin/bash”…

Linux大文件传输

我们经常需要在机器之间传输文件。比如备份,复制数据等等。这个是很常见,也是很简单的。用scp或者rsync就能很好的完成任务。但是如果文件很大,需要占用一些传输时间的时候,怎样又快又好地完成任务就很重要了。在我的测试用例中,一个最佳的方案比最差的方案,性能提高了10倍。 复制文件 如果我们是复制一个未压缩的文件。这里走如下步骤: 压缩数据 发送到另外一台机器上 数据解压缩 校验正确性 这样做会很有效率,数据压缩后可以更有效的利用带宽 使用ZIP+SCP 我们可以通过ZIP+SCP的组合实现这个功能。

这条命令是将/home/yankay/data经过GZIP压缩,通过ssh传输到yankay01的机器上。 data文件的大小是1.1GB,经过Zip压缩后是183MB,执行上面的命令需要45.6s。平均吞吐量为24.7MB/s 我们会发现Scp也有压缩功能,所以上面的语句可以写成

这样运行效果是相同的,不通之处在于我使用了blowfish算法作为Scp的密匙算法,使用这个算法可以比默认的情况快很多。单单对与scp,使用了blowfish 吞吐量是62MB/s,不使用只有46MB/s。 可是我执行上面一条命令的时候,发现还是需要45s。平均吞吐量还为24MB/s。没有丝毫的提升,可见瓶颈不在网络上。 那瓶颈在哪里呢? 性能分析 我们先定义几个变量 压缩工具的压缩比是 CompressRadio 压缩工具的压缩吞吐是CompressSpeed MB/s 网络传输的吞吐是 NetSpeed MB/s 由于使用了管道,管道的性能取决于管道中最慢的部分的性能,所以整体的性能是: speed=min(NetSpeed/CompressRadio,CompressSpeed) 当压缩吞吐较网络传输慢的时候,压缩是瓶颈;但网络较慢的时候,网络传输/吞吐 是瓶颈。 根据现有的测试数据(纯文本),可以得到表格: 压缩比 吞吐量 千兆网卡(100MB/s)吞吐量 千兆网卡吞吐量,基于ssh(62MB/s) 百兆网卡(10MB/s)吞吐量 ZLIB 35.80%…

Linux下常用的文件传输方式介绍与比较

本文介绍了linux之间传输文件的几种方式,并通过具体实验测试了几种文件传输方式之间的传输速度。这篇文章是我一次作业的实验报告,我经常查看这个文档,所以贴出来方便自己查略。 0. 实验环境以及实验数据 实验环境: 两台装有Ubuntu的电脑,两台电脑位于同一个局域网中,传输速度约4.1MB/s。 实验数据: 使用MySQL的日志文件(ib_logfile0)进行测试,日志文件压缩前1.1G,压缩后159M,具体应用中,压缩比例可能没有这么高,但是不影响我们的讨论。 1. scp scp是secure copy的缩写,scp是linux系统下基于ssh登陆进行安全的远程文件拷贝命令,主要用于linux服务器之间复制文件和目录。scp使用ssh安全协议传输数据,具有和ssh一样的验证机制,从而可以实现安全的远程拷贝文件。 下面介绍SCP三种不同用法的效率。注意:使用SCP前请配制好SSH。 1.1 scp 不使用压缩 将本地文件拷贝到远程服务器:

将远程服务器中的文件拷贝到本地的用法:

经测试,SCP不启用压缩功能的情况下,传输ib_logfile0文件需要4:12s。 1.2 压缩后传输 SCP传输ib_logfile0文件之所以需要那么多时间,是因为它没有对传输的数据进行压缩,可以先 将文件压缩,然后再进行远程拷贝。如下所示:

经测试,先手动压缩,然后再传输,4次测试结果的平均值为00:39s。 1.3 scp启用压缩 相对于第一种方法,第二种方法极大地减少了传输时间,但是需要执行三条语句,较为麻烦。更简单的方法如下所示:

-C选项启用了SSH的压缩功能,通过man ssh可以看到,在-C选项的解释部分有这么一句话:”the compression algorithm is the same used by gzip”。SSH与gzip使用的是同一种压缩算法,即第二种方法与第三种方法几乎一样,但是,第三种方法更为简单方便,所以,推荐使用第三种方法传输数据。…

Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt

“Unhandled Exception: System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt” This issue shouldn’t happen in managed code. You can try setting Visual Studio Debugger to bypass this exception: Tools menu…

C/C++获取进程信息

Taking a Snapshot and Viewing Processes The following simple console application obtains a list of running processes. First, the GetProcessList function takes a snapshot of currently executing processes in the system using CreateToolhelp32Snapshot, and then it walks through the list recorded in the snapshot using Process32First and Process32Next. For each process in turn, GetProcessList calls the ListProcessModules function which is described in Traversing the Module List, and the ListProcessThreads function which is described in Traversing the Thread List. A simple error-reporting function, printError, displays the reason for any failures, which usually result from security restrictions.

 

从DataGridView中复制中文到Excel中乱码,怎么解决

DataGridView的KeyUp事件

ListView的KeyUp事件

 

将Linux命令的结果作为下一个命令的参数

1. 符号: 名称:反引号,上分隔符 位置:反引号()这个字符一般在键盘的左上角,数字1的左边,不要将其同单引号(’)混淆 作用:反引号括起来的字符串被shell解释为命令行,在执行时,shell首先执行该命令行,并以它的标准输出结果取代整个反引号(包括两个反引号)部分 举例:

2. $()  效果同 3. 命令:xargs xargs是给命令传递参数的一个过滤器,也是组合多个命令的一个工具。它把一个数据流分割为一些足够小的块,以方便过滤器和命令进行处理。通常情况下,xargs从管道或者stdin中读取数据,但是它也能够从文件的输出中读取数据。xargs的默认命令是echo,这意味着通过管道传递给xargs的输入将会包含换行和空白,不过通过xargs的处理,换行和空白将被空格取代。

管道与xargs的区别: 管道是实现“将前面的标准输出作为后面的标准输入” xargs是实现“将标准输入作为命令的参数” 4. find命令的-exec参数 xargs:通过缓冲方式并以前面命令行的输出作为参数,随后的命令调用该参数 若忽略 xargs 的 options 来看的话, cm1 | xargs cm2 可以单纯看成: cm2 cm1 因此, find …. | xargs rm 也可作 rm…

查找Linux进程目录

Linux下我们一般使用ps查看进程信息,但是ps给出的进程信息比较有限,没有进程的工作路径,进程命令的绝对路径等等,这时候我们可以通过Linux下 /proc/ 目录下存储的信息进行查询进程命令路径信息。 Linux下,任何一个程序启动以后,系统会为其分配一个ID,即我们熟悉的PID,称为进程号,与此同时,系统会在/proc目录下为其创建一个独立的文件夹,文件夹以PID命名,在该文件夹内保存着该进程运行相关的详细信息,有兴趣的朋友可以进到这个目录下好好研究研究,不过今天的重点是获得该进程的绝对路径。 在 /proc/ 该目录下有一个名为exe的文件,像Windows系统下的可执行文件,这其实是一个符号链接(类似于Windows下的快捷方式),它指向该进程对应程序的绝对路径。用file命令或ls命令查看该符号链接的属性即可获取它所指向的绝对路径:

将上面命令中的PID换成你要查询的Linux进程号就可以。

Page 1 of 3123