Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
在大数据量的系统中,分区表是很常见的,分区有多种类型,可以根据业务来选择自己需要的分区,不过为了数据的兼容性,需要考虑对于分区表设定一个默认的表分区,如果数据在插入表分区的时候,没有符合条件的分区,就会插入默认的表分区中。
有时候想查看一个package的信息,但是对于package的名字不是很确定,比如只知道一个大概,知道一些关键字,这个时候通过图形工具是查找不到package的信息的,而且对于package的信息,我只关心package里面有哪些存储过程,哪些函数等,看看简单的参数情况就可以了,类似sqlplus的desc的形式。
在一个schema中,可能含有大量的procedure, 有时候想查看具体的信息,一般得通过toad,plsql dev等工具来查看,有时候在尽可能摆脱图形工具的前提下,想能够尽快的查找一些信息,还是使用shell脚本更快,更准,更直接。
在很多应用中如果数据量少有规模,都会有大量的分区表存在,使用比较多的是range partition. 一般的range partition都一时间为键值,或者根据业务绑定的关键id值。
在本地的虚拟机环境一直凑合着用英文,今天想看看中文的东西都显示乱码,下定决心要把问题解决了。 如果直接打印文本内容,通过putty也会显示乱码。 [ora11g@rac1 ~]$ cat aa.sh δ? ε??ο?θ?ζ―δ?δ??ζ?θ― [ora11g@rac1 ~]$ 这个时候很可能是putty的编码转换的问题,通过查看putty的设置,如上,可以看到应该选为utf-8。
早上刚到公司,查看系统的负载,就马上看到一个进程的执行时间已经有3天了。 而且cpu的消耗极高。 Tasks: 2374 total, 19 running, 2354 sleeping, 0 stopped, 1 zombie Cpu(s): 21.
在数据迁移中,可能有成百上千个表,有些表很大,有些表又很小。 如果启用了多个并行的进程,可能会有资源分配上的问题。 比如下面有10个表,100代表预计的时间为100分钟。
使用shell分析了一些数据有一些时间了,而且分析的数据情况也是基于历史数据,今天写了个脚本对历史的数据进行一个简单的分析,看看准确率到底有多高。 这里有一个借助一个脚本12c.sh 对一些数据的排列百分比进行分析,比如今天有两个球队,主队让球一个,胜平负的概率为35%,40%,25% 表data里存放着一些样本数据,记录了球队的比赛情况。
在之前的章节中讨论过怎么把一个很大的分区表切分为若干的dump文件,在数据加载的时候能够同时做基于每个分区的数据导入,如果有些分区比较大,有几十个dump文件,那么这个分区做数据导入的时候是不能再进行并行切分了。
今天在一套环境中做系统检查的时候,发现alert日志中有一段ODM的错误。日志内容大体如下,可以看到是在半夜4点多报的错误。 Clearing Resource Manager plan via parameter Fri Aug 22 02:00:52 2...
有些时候想直接查看某个用户下对应的权限信息。自己每次从数据字典中查找有些太麻烦了。如果涉及的对象类型多一些,很容易遗漏。 一种方式就是通过exp直接导出对象的信息来,可以直接解析dump内容来得到object的一些信息,也可以直接访问数据字典表来得到。
当我们得到一个dump文件的时候,总是有些不太确定dump文件中是否含有一些我们原本不希望出现的表,如果在未知的情况下对dump文件进行操作时很危险的,比如我们想要得到的是表结构的信息。
昨天使用shell脚本来抽取html数据的时候,碰到了一个问题,如果要抽取的数据成了如下的情形时,数据的抽取就会出现不一致,有一些记录会没有数据,只显示"未开售" 这个时候如果还是按照原来的思路来抽取就会出现数据混乱的情况,比如根据第一列抽取数据一共有75 行,但是根据右边的赔率只能得到74行,有一行的数据混乱,后面的数据就全乱了。
最近看一些网站的时候,发现有些数据很有意思,想把数据截取出来,但是想把数据抽取出来很是困难。因为如下的小方框的数字都是上下两行排列,想要把数据抽取到一行是很难实现的。
最近对足彩的数据进行了一点分析,简单分享一下自己的一点收获, 对于足球比赛的赔率还是很有计算方法的。我收集了一些比赛的数据,进行了简单的分析。创建了一个表为data.
在平时的工作中,可能需要查询一些数据字典的信息,比如数据字典对应的基表信息,可以得到更多数据库内部的一些详细信息。 比如user_objects这个数据字典视图,里面可能就包含很多的信息。
关于数据迁移,在之前也讨论过一些需要注意的地方,可能林林总总列了不少,都是在数据迁移迁移前和迁移时需要注意的。http://blog.itpub.net/23718752/viewspace-1195364/http://blog.itpub.net/23718752/viewspace-1254945/ 我在这些帖子的基础上进行更多的总结和补充。
关于数据迁移,在之前也讨论过一些需要注意的地方,可能林林总总列了不少,都是在数据迁移迁移前和迁移时需要注意的。http://blog.itpub.net/23718752/viewspace-1195364/ 我在这个帖子的基础上进行更多的总结和补充。
昨天有一个网友问我,怎么能够查询一个表中最后一条插入的记录,我大概回复了,可以通过闪回事务来实现,但是得看什么时候插入的数据,也需要一定的运气。 如果通过闪回事务来得到对应的undo_sql,可能多个dml语句对应一个事务,所以我们需要得到的是一个完整的事务的信息,里面包括对应的Undo_sql,这样才算得到比较完整的sql语句。
在生产系统中,会发现一些潜在的sql问题,为了能够及时和准确的定位,我们可以借助sql_monitor来做性能sql的查找。可以在后台启用一个job不定时的去查找。
在平时的工作中接触到的分区表一般都比较大,而且分区也少则几十,多则几百,上千。 在数据迁移的时候,分区表的迁移更是块大骨头,因为数据量太大,而且有些分区表中还有一些lob字段,想直接通过sqlldr来迁移还是需要做一些额外的工作。
在平时的工作中,数据库所处的文件系统是vxfs的话,可以考虑启用veritas的odm特性。 ODM(Oracle Disk Manager)是在oracle 9i之后开放出来管理数据文件,可以提高oracle数据库的输入输出数据吞吐量。
在昨天晚上10点开始,数据库的性能开始下降,出现了一些j00开头的进程。 而且持续了比较长的时间,简单分析了一下,对应的进程执行的sql语句如下。 ####### Process Information from OS level as be...
昨晚在做测试环境数据迁移的时候,遇到了io的问题,本来预计2,3个小时完成的数据导入工作最后竟然耗了7个多小时。在数据的导入中,使用了10个并行的session,每个session都启用的并行度为8,在表级,索引级都做了nologging设置,在insert的时候使用了append模式,结果本来数据的导入还是比较顺利的,突然在8点左右开始就一下子直线下降。
在工作中我们需要查询表的数据条数,一般来说就是使用select count(1)或者select count(*)之类的语句。 当然了对于不同的表来说,应该还是可以做一些细分,能够最大程度的提高效率,比如表中含有主键列,尝试走索引扫面可能会被全表扫描效率要高。
在之前的章节中,讨论过了通过 分区+并行等方式来进行超大的表的切分,通过这种方式能够极大的提高数据的平均分布,但是不是最完美的。 比如在数据量再提高几个层次,我们假设这个表目前有1T的大小。
在数据迁移的时候,目前启用了10个并行的进程。每个进程负责一部分的数据导入工作。然而在统计数据导入进度的时候,总是感觉抓不到重点,没有一目了然的报告。 在定时做数据状态检查的时候,总是凭着感觉和不停的查看日志来得到最基本的状态。
在海量的数据迁移中,如果某个表特别大,可以考虑对表中的分区进行切分,比如某个表有100g,还有100个分区,那么可以考虑针对这100个分区,那么可以考虑把这100个分区看成100个表进行并行抽取,如果某个分区数据比较多,可能生成5个dump,那么着100个分区,就可能生成105个分区以上。
exp/imp 对于数据结构的复制和同步,还是比较理想的工具。 在数据量比较小的情况下,这个工具的性能要远远好于datapump,而且重点推荐,他对于各种常用数据类型的支持还是很不错的。
零零星星的接触到写一些shell也有一些日子了,发现自己已经犯了不少的错误,自我总结下。 选择合适的shell shell本身有很多种,大体有如下的几种。
在数据迁移的过程中,会产生大量的dump文件,需要对dump的文件情况进行一个简单清晰的管理,比如目录下的文件特别多,而且某些表比较大,对应的dump文件比较多,就想得到一个很简洁的报告,能够统计出来每个表有多少个dump文件。
今天在做数据迁移的时候,碰到了一个严重的问题,数据加载完全hang住了,最后无奈回退了。 系统使用的vxfs文件系统,在生产升级前一个月的时候,做过一次小规模的数据迁移,当时查看awr,ash,最后根据addm的推荐得出加载速度比较慢主要是由于异步IO导致的,而且当时生产库确实没有启用异步io, filesystemio_option的设置为none,在经过确认之后,在半个月前的一此例行维护中,由客户做了这个配置的修改。
老是做工作中的数据分析,最近也在看足球彩票,竞猜游戏有输有赢,但是里面还是有不少的数据分析的乐趣,关于足球彩票的分析,自己写了如下的程序,可以参考。当然了,最好能带有主观的分析,这样可能准确率要高一些。
在平时的工作中,有时候需要准备一些脚本,比如能够简单验证一下表是否可访问,或者验证表中有无数据等。 今天在测试环境进行了简单的模拟,发现还是有很大的差别。 简单来说,要实现如上的需求有两种方式,一种是通过count来判断,另外一种是通过rowid来判断。
在之前的章节中分享过一些数据迁移中并行抽取的细节,比如一个表T 很大,有500G的数据,如果开启并行抽取,默认数据库中并行的最大值为64,那么生成的dump文件最50多为64个,每个dump文件就是7.8G,还是不小,况且在做数据抽取的时候,资源被极大的消耗,如果资源消耗紧张,可能可用的并行资源还不到64个。
在前几篇中讨论过海量数据的并行加载,基本思路就是针对每一个物理表都会有一个对应的外部表,在做数据迁移的时候,如果表有上百G的时候,一个物理表对应一个外部表性能上会没有任何提升。
根据oracle的规范,对象的长度最大为30位,也就是说,在平时的使用中如果碰到表名长度大于30位,首先oracle是不答应的,它会提示idnetifier too long的错误。
现在得到一个需求,需要把生产环境的多个schema下的表结构复制到测试环境中的一个schema下。 生产环境和测试i环境的表空间配置都不一样。 目前可以考虑用如下的几种方式来实现。
在linux中有些命令可能功能强大,方便快捷,但是这些命令在测试环境中有些可以用,但别在生产上挑战。有些命令一敲,可能你的职业生涯由此转折。 关于rm -rf 对于这个命令真没什么好说的,最好的挽救措施就是备份,可能在有些环境中这类命令都是禁用的,但是不管怎么样,注意备份。
在系统升级的过程中,准备了大量的脚本,分成几个窗口来分别执行。 在碰到问题的时候,一定要很细心和冷静,不经意的错误可以需要几倍,几十倍的努力来挽回。 准生产环境中有一个表。
生产系统中有一条sql语句,目前执行的时间有点长了,而且看起来有些臃肿,客户问能不能改进一下。得到的sql语句如下: SELECT COUNT(1) FROM ( SELECT /*+ leading (payment_temp_ta...
有些linux命令看起来极其简单,只包含2个字符,但是确有很强的功能性。看起来还是有些陌生的命令,在工作中别忘记它们的存在。 ab 这条命令式做为性能测试所广泛用到的一下子就有了一种高大上的感觉,来一个例子,对百度的某...
在数据迁移中,经常会碰到null值的问题,比如在源库中,某些列可能是null值,但是在目标库中,却有非空约束。这样在数据的迁移过程中就会发生问题。 为了更好的对数据的非空问题进行判断,我写了如下的脚本来生成检查的脚本,基本的思路就是生成动态sql,类似 select count(1) from xxx where xxx is null,如果输出结果不为0,说明在源库中存在着非空约束的问题。
今天在从生产环境中做一个数据抽取,为了提高效率,加了并行。发现了一些小的细节。 首先,抽取数据时,对于并行度的指定我是设定200M为一个单位,如果表有1G,那么就需要启5个并行,结果有一个表有40G,按照这个单位,需要200个并行。
在生产系统中有些时候需要保证一些表的只读特性,不允许表的数据被轻易修改。可能有一下的场景比较适用。1) 一些系统中有一些类似数据字典信息的表。这些表的信息基本都是稳定的,不会轻易的改变。
今天在生产环境中,开发人员提交了一个脚本,是做update操作的,但是update操作的时候过滤条件有些大,本来预计修改的数据只有5000条,结果这个语句运行下来更改了500万条数据。
今天在生产环境中发现一条sql语句尽管走了主键索引,但是查询还是很慢。 sql语句类似下面的形式: SELECT /*+ index (bl1_cyc_payer_pop BL1_CYC_PAYER_POP_PK) */ T_TAX.
生产中有一条sql语句消耗了大量的cpu资源,执行时间在18秒左右, Session : PRODBUSER (156...
行列转换在数据库,开发语言中都是一个津津乐道的话题,今天来简单演示一个使用sed所作的特殊行列转换。 日志的内容如下: append data from MIG_TEST.
在linux中有经常做文件的操作,今天有个同事在生产环境统计数据,发现有很多日志文件都是空的,文件太多了,他想查看一下有哪些文件不是空文件。 而且还不想使用脚本,就想用一个命令来搞定,确实够懒的一个人。