作者简介： 李真旭（Roger） 云和恩墨西北区技术总监，Oracle ACE, ACOUG 核心专家 对于数据库升级迁移，这两年是一个非常热门的话题，尤其是 x86 的流行，很多客户纷纷投向了 x8
目前有一个很实际的需求，因为硬件老化严重，需要能够借助一次维护时机把数据库迁移到一台较好配置的机器上，避免潜在的硬件故障导致的业务停顿，也算防患于未然吧。 本来这个事情不是很紧急，但是因为硬件故障导致的问题防不胜防，踩过几次坑，就会有些经验教训，在这种情况下维持现状就是一个潜在的炸弹。 当前的硬件环境是Solaris，Oracle 10gR2 单实例,数据量在800G左右。我大体想了下，主要的目标有以下几个。 1.借助这次维护的时机，能够把数据库升级至11g 2.升级的过程需要尽可能保留一个
云时代的大背景下，传统的商业数据库各厂商都开始转向云服务，传统的dba也开始面临各种挑战。
本篇主要讲一下关于Entity Framework Core访问oracle数据库的采坑。。
其实从前两年开始，坊间就不断传出浪潮要进军数据库市场，于去年底月浪潮宣布与Tmax共同建立合资公司，浪潮也因此拿到了Tmax中国区的知识产权和经营授权，由此开展了浪潮的数据库之旅。 浪潮为什么一定要发展数据库？ 经过数月的融合，浪潮在上周发布了【一键K启-浪潮K-DB数据库发布会】，翻看浪潮数据库的合作家族中合作伙伴横跨国内外，南大通用，IBM DB2和Informix，以及达梦、人大金仓，其中鼎鼎大名的Oracle数据也位列其中，可能很多人会问浪潮为何一定要多此一举发展自已的数据库领地？ 这一点T哥也得
从oracle中ASM的发展来看，到今天的普及使用，应该可以算做一种文化，因为这体现的不仅是ASM技术在实际工作中的成功普及，而且从某种程度来说，都代表了一个新生事物的发展历程，无论是java的发展还是各种开源项目的普及，都有着相似的痕迹。 asm从Oracle 10g版本推出，是作为grid的一部分鼓励使用的。而在这段漫长的时间里面，其实asm就在逐渐完善。 就如同你去公司内部推广一套很新技术的时候，人家肯定得衡量你的东西是不是足够好，如果性能指标能够达到指数级的提升，或者操作能够简化到极致，而且稳定，
它仅基于 7 个基本命令： Migrate、 Clean、 Info、 Validate、 Undo、 Baseline和 Repair。
上周组内例会，提到不同数据库中大小写敏感的问题，问题很小，但是如果不注意，尤其是开发不规范的场景，很容易进坑。
在数据迁移中，除了跨平台，全量，增量数据迁移之外，还有一类会把已有的难度升级，那就是整合式迁移，比如原来有两个数据，迁移后是一个，类似这样的需求，如果再加上平滑升级数据库版本，那就值得我们好好想想方案了。 如果两个源库不大，其实直接使用Datapump不失为一种方法，最大的优点就是操作简单，可控性强，而瓶颈也很明显，随着数据量的增长，这个迁移时长就会线性增长，从逻辑迁移的角度来看，对于版本升级的依赖性不高。 而如果两个源库都很大，比如都是5T这样的级别，整合起来就是10T,这样的量级，给你一
Oralce 12c中的多租户数据库的启用，使得原来分布于多台服务器或者一台服务器上运行N多实例的情形需要进行整合。那就是将之前的N多非CDB数据库整合到CDB，原来的数据库将作为CDB数据库下一个PDB容器，各个PDB之间也可以通过快速dblink实现交互。常用的方法包括导出导入，DBMS_PDB包方式，以及GoldenGate复制方式等。本文主要描述使用DataPump方式实现迁移。
对于dataguard说，switchover,failover是一种互补可选的容灾解决方案。但是对于这种容灾思路还是存在着一些实践中的细节需 要，从数据层面而言，只能是最大程度保证了数据的不丢失，但是数据切换过去了，权限，配置这些信息还是需要考虑的，如果切换过程很快，收尾的补充工作很 慢，那么总体来看切换的时间就被拉长了。 在提出准备的需求之前，容我花一点时间来简单吐槽一下10g中的dataguard. 10g中的状态切换 10g中的dataguard没有adg的特性，在使用中还是有很大的限制，很多时候备
在Oracle PL/SQL中使用UTL_SMTP、UTL_MAIL、UTL_HTTP等包进行发邮件等操作，需要配置Oracle Network ACLs(Access Control List)。
还是继续昨天的任务。 前面的内容可以参见：迁移式升级的一点思考 （r10笔记第27天）、迁移式升级的新方案测试 (r10笔记第30天)、迁移式升级的测试（二）(r10笔记第35天) 今天会把剩下的工作都做完，给个交代。 昨天完成了Data Guard切换，然后Failover备库，导出了元数据信息作为TTS的准备，亮点就在于导入的部分。无需挪动数据文件，这是补充数据字典信息即可。 这个工作的一个重点内容就是如何保证数据字典信息的完整性。 在目标环境11g中需要创建相应的用户，这一点还是很有技巧的。如果采用i
之前写了一篇文章分析了目前存在的一个问题和改进思路。迁移式升级的一点思考 （r10笔记第27天） 当前的硬件环境是Solaris，Oracle 10gR2 单实例,数据量在800G左右。想迁移到另外一台服务器上。大体的需求如下： 1.借助这次维护的时机，能够把数据库升级至11g 2.升级的过程需要尽可能保留一个较短的时间窗口，计划在2个小时以内完成 3.有较好的解决方案去演练整个过程，多次总结，提高迁移的效率，保证质量 4.有完善的回退计划，能够支持回退场景下业务平滑过渡
Oracle 12c的多租户特性是Oracle Database历史上最重要的革新之一，在云时代这一特性展现出强大的整合威力。 基础简介 插接式数据库由一个使用 CDB（Container Datab
在日常的数据库维护中，经常出现SYSTEM表空间被撑满，在绝大多数情况下是因为数据库登录审计的功能被启动了，此时一般建议把SYS.AUD$相关对象迁移到其它表空间，从而避免SYSTEM被用完的风险。
Oracle Database 12c中加入了Data Redaction作为一个新的安全特性。（实际在11g的官方Database Advanced Security Administrator's
近期公司有个项目，需要将一套AIX上的rac 11g，迁移到华为云上，数据量大概4T，停机时间2小时，目前最大问题是本地磁盘空间不足。起初，想到的是OGG或XTTS，XTTS没啥问题，最适合做这类迁移了。对于OGG来说，OGG初始化需要导出和导入，仍然需要临时的本地磁盘空间，当时把该方案直接pass掉了，后来回头想想，似乎可以使用network_link来解决这个问题。使用impdp+network_link导入完成后，再配置OGG实时同步，即可实现AIX到Linux的迁移。
在很多Oracle文档中，可能大家都注意过Oracle用来进行测试的一个表空间，这个表空间中有一系列预置的用户和数据，可以用于数据库或BI的很多测试实验。 这个表空间在使用模板建库时是可以选择的，在如
Oracle随着版本的升级，逐渐将步骤缩减，进行封装，18C之后可谓是达到了所谓的一键刷新，恢复DG同步。
GoldenGate这些年在数据迁移中是大放光彩，简称OGG,对于很多DBA来说，学会这项技能也会给自己加分不少。 Oracle在10g开始推出的GRID的概念，分为了以下四个层面。 1）存储层面 ASM 2）数据库服务 RAC 3）应用 Stream 4）管理 Grid Control 现在来看看这四个方面的发展。 ASM如果说在10g是试水，那么在11g中是走向成熟，12c作为标配。 RAC呢，自不必说，其实已经远远超出了它本身的含义，数据库的组件那么多，唯独这个组件是很多大企业的首选，
作者 | 罗贵林： 云和恩墨技术工程师，具有8年以上的 Oracle 数据库工作经验，曾任职于大型的国家电信、省级财政、省级公安的维护，性能调优等。精通 Oracle 数据库管理，调优，问题诊断。擅长 SQL 调优，Oracle Rac 等维护，管理。
目前使用的是SonarQube 6.7,已经有超过100个项目在使用。近期开发同学反馈，IDEA+SonarLint结合使用非常好用，可以在代码编写和问题产生的第一现场解决问题。但是开发同学也希望，能使用IDEA+SonarLint+SonarQube，与最终“质量门禁”使用相同的规则，以促进质量内建。 但是在使用过程中发现，由于SonarQube6.7版本过低，新版本的IDEA+SonarLint无法与之配合使用。考虑之下，决定启动SonarQube的升级，也启动了踩坑之旅。
很多时候，大家工作中都会有一种被动的思维，那就是能不动就不动，从求稳的角度来看无可厚非，但是从风险的角度来说，还是有待商榷的。如果存在风险，还保持原样很可能就是一个不定时炸弹。 这不手头有一套环境，按照以前的标准是根本入不了我的法眼的，但是因为是测试环境，小问题比较多，存在容灾风险，但是这么多年一直这样，也就默然接受了。 这套环境硬件配置很低，基本上和我的笔记本配置差不多，可能还略差一些，在上面跑着3个数据库实例，其中一个是11g的，2个是10g的。两个10g的数据库实例数据量都不大，几十G而已。 看起来是
Oracle RAC One Node是Oracle Database 11.2引入的Oracle数据库企业版的一个选项。它为单实例Oracle数据库提供了增强的高可用性，可以保护计划内和计划外的停机时间。 本文来自Oracle白皮书翻译 Oracle RAC One Node有以下优点： 增强Oracle数据库的可用性 为Oracle数据库整合提供便利（提供对多租户的支持） 方便进行数据库虚拟化 Oracle RAC One Node还允许客户对其数据库部署和管理进行标准化，整合数据库存储，如果需要，可
前几日通过 ADG 的switchover 模式迁移了一套 19c 的 RAC 环境，迁移后一切正常，主备库均可正常提供服务，备库正常同步，不过为了节省资源，又是测试环境，则将其备库关机回收资源了，大约一周后的时间，有开发的小伙伴找来说他的程序执行报错了，扔来了如下的错误代码。ORA-28040:No matching authentication protocol 没有匹配的认证协议。
环境: RHEL5.4 + Oracle 10.2.0.4 目的: 在本机将数据库升级到11.2.0.4
将 Non-PDB 插入 CDB 在12c中，可以将一个非 CDB（也即NON-CDB）插入到 CDB 中，这个过程需要在只读模式下进行。 以下测试首先启动一个常规的 Non-CDB 数据库： 这个
许春植（Luocs） （阿里巴巴高级数据库管理员,7年以上数据库运维管理经验，擅长MySQL、Oracle及MongoDB数据库，目前主要研究并建设MongoDB一套完整的运维体系） 编辑手记：感谢许春植授权独家转载其精华文章，也欢迎读者朋友向我们投稿，本文是对Oracle SCAN特性的一些介绍和总结，编辑时略有节略。 Oracle 从11g 开始推出的 SCAN 特性在 Oracle RAC 高可用连接里占据着非常重要的地位，也是以后的重点推进方向。 说在前头：文章中核心内容来自官方，当然也参考了
XTTS（Cross Platform Transportable Tablespaces，跨平台迁移表空间）是Oracle推出的一个用来迁移单个表空间数据以及将一个完整的数据库从一个平台移动到另一个平台的迁移备份方法。在企业越来越大的数据量、相对停机时间要求日益减少的情况下，利用XTTS可以完成使用增量备份方式实现跨平台的数据迁移。XTTS能够减少停机时间、可以进行增量备份，并且能实现跨平台的数据迁移。在“去IOE”（即IBM、Oracle、EMC，其中，IBM代表硬件以及整体解决方案服务商；Oracle代表数据库；EMC代表数据存储。Oracle其实是很难去掉的，我国很多领域的核心业务系统都运行在“IOE”的软硬件架构之上。）的浪潮下，XTTS成为了如今U2L（Unix to Linux）迁移的最有效、最安全的解决方案之一。有关XTTS的使用在MOS文档“11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (文档 ID 1389592.1)”上有非常详细的介绍，这里不再详述。
Oracle数据库的10g版本在7月31日结束了Extended Support - 扩展支持阶段，正式进入Sustaining Support - 持续支持阶段，在这个阶段，Oracle将不再提供补丁支持。也即Oracle 10g开始退出主流版本舞台。 这一切伴随着Oracle 12c的发布，更加推动用户去更替数据库版本，如题图所示，Oracle 11g版本自2007年发布以来，已经过去了7个年头，这期间11g版本经受了时间和应用的考验，已经成熟，而且根据规划，11g的新的补丁集11.2.0.4原本应该在
本文主要演示通过 Tapdata Cloud 来进行 Oracle 数据同步。ヾ(◍°∇°◍)ﾉﾞ
OCM，Oracle Certification,Oracle Certified Master,11g,12c
需求：迁移部分表 11.2.0.3-->10.2.0.4，若迁移范围内的有些表在目标库已经存在，则替换。
说明：以下操作环境在CentOS 6.4 + Oracle 11gR2（Oracle安装在ORACLE_BASE=/opt/oracle中，其ORACLE_HOME=/opt/oracle/11g） 用OUI安装并配置Oracle数据库后，Oracle就开启了(包括：数据库实例、监听器、EM)。在重启操作系统之后，Oracle默认是没有启动的。使用如下命令查看Oracle相关服务是否已启动： ps aux | grep ora_ #若无ora_**_**相关的进程，则oracle数据库实例未启动 netst
今天，腾讯云企业级数据库迁移产品DBbridge正式发布啦！DBbridge通过提供一站式数据迁移平台以及专家服务，帮助企业实现异构数据库之间数据的迁移和同步。尤其在传统数据库迁移到分布式数据库场景下，DBbridge能够有效降低数据迁移的成本和复杂性，满足企业多样化的数据传输、数据汇聚、数据灾备等需求。 数据库迁移上云已经成为企业在推进数字化转型过程中的重要措施。相对于传统商业数据库集中式架构扩展性差、技术复杂、迭代慢等问题，云端分布式数据库不仅在成本上具有突出的优势，在灵活性和扩展性上也具有明显
oracle是非常强大的数据库软件，有很多朋友对oracle安装并不是很了解，因为除了安装还有一些变量需要设置，下面一起来看看oracle 11g安装图解，定能帮助你快速安装oracle 11g。
在/etc/sysconfig/network-scripts文件夹下的ifcfg-eth0中修改
题目 SYSTEM和SYSAUX表空间存储的内容有哪些区别？若SYSAUX表空间占用过大则应该如何处理？
如果每次重启操作系统都要进行以上操作好麻烦，那么如何让Oracle作为系统服务在开机的时候自动启动呢？ Oracle在$ORACLE_HOME/bin下提供许多对数据库进行操作的脚本，其中dbstart和dbshut可分别用来启动和关闭数据库。注意，这两个脚本已包含监听器的启动或关闭，但并未对EM进行相关的操作。使用如下命令： /opt/oracle/11g/bin/dbstart /opt/oracle/11g #启动数据库实例(包含监听器) /opt/oracle/11g/bin/dbshut /opt
说起数据迁移，感觉也算是有些感受了，但是最近参与的几个迁移案例还是和以前大大不同，以前的迁移项目是比拼停机维护时间，尽可能在短时间诶导入大批量的 数据，有参与表空间传输的场景，还有跨平台的数据迁移，数据库迁移式升级等等，相对难度大一些的算是增量数据的迁移场景。为此也算把 sqlldr,datapump和exp/imp玩了一圈，最后写了一个小的工具使用外部表迁移，也算是有了一些谈资。 最近的迁移项目还是有些特殊，有schema级别的迁移，这种情况数据库版本的影响就没有那么大了，基本就是schema级别
墨墨导读：Oracle 11g推出了自动内存管理（AMM）新特性，该特性引入后，虽然减轻了DBA手动设置共享内存的负担，但是会存在不稳定的情况，经常出现在shared pool和buffer cache之间发生频繁shrink/grow操作的现象，特别是shared pool的shrink操作，在一些高并发环境下，可能引发数据库性能问题的风险，极端情况下，会导致数据库性能短时间内极速下降，在生产环境建议使用ASMM，因为从以往的经验来看，ASMM的稳定性高于AMM。
目前一共包含6个脚本，若脚本的扩展名为“.sql”则表示该脚本为sql脚本，若脚本的扩展名为“.pl”则表示该脚本为perl脚本。
目前一共包含以下4个脚本，其中DB_healthcheck_lhr_v6.0.1_ALL_RW.sql 是读写版本，在脚本执行过程中会对数据库做DDL（创建一些用到的临时表）和DML操作（对自己创建的临时表DML操作），但是，在脚本执行后会清理掉创建的临时表，基本上不会留下任何痕迹。而脚本DB_healthcheck_lhr_v1.0.0_10g_RO.sql、DB_healthcheck_lhr_v1.0.0_11g_RO.sql和DB_healthcheck_lhr_v1.0.0_2c_RO.sql分别对应10g、11g和12c及其以上版本，这3个脚本都是只读版本，这3个脚本只会对数据库做查询操作，不会做DML和DDL操作，这也是很多朋友所期待的功能。
最近需要在不同的数据库之前迁移Oracle scheduler job，首先想到的办法是通过datapump来直接到导出Oracle scheduler job，然后使用dump file来生成ddl文件。使用这个方法可以成功完成导出并生成sqlfile。但是在目标数据库执行时收到ORA-24150 ORA-06512 during executed sql script错误。即使是在源数据库删除之前的job再执行ddl依旧有类似的错误。主要提示的是ORA-24150: evaluation context SCOTT.SCHED_EV_CTX$1 does not exist上下文环境不存在。这是因为是源库源Job被删除后，上下文环境不存在，新的目标库压根也不存在。注，这个错误是在创建chain规则时出现，且10g/11g都有这个现象。普通的scheduler job没有这个问题。最后直接使用Toad来导出ddl，这个方式简单易行，图形界面，供大家参考。 关于chain，可参考: Oracle Scheduler Chain 的用法 关于前面提到的ORA-24150 ORA-06512，可以参考帖子，有知情的大神们，劳请回帖，谢谢！ export scheduler job but chain step and chain rule failed with ORA-24150 ORA-06512 during executed sql script
Oushu Database（简称OushuDB）是新一代极速云数仓，让企业用户轻松构建核心数仓、数据集市、实时数仓以及湖仓一体数据平台。OushuDB由国人自主研发，符合国家信创标准；通过计算存储分离架构解决了传统数据仓库高成本、高门槛、难维护、难扩展的问题。同时支持各大公有云和私有云。
最近抽空练习了下手工建库，在10g的时候基本都在20分钟搞定，在11g中其实还可以更快，因为10g中需要配置的admin目录，需要创建bdump,udump之类的目录等等，在11g都被adr给默认替代了，只要提供了$ORACLE_BASE，就会默认在$ORACLE_BASE下生成对应的目录结构。 其它步骤完全可以按照10g的脚本来使用，没有任何问题，但是如果反过来，在11g里使用的一些语句在10g中可能会有一些问题，这一点也是在今天的测试中发现的一个小细节。 首先我在11g的库中创建了一个数据库实例，使用c
对于从Oracle 10g下迁移数据库到Oracle 11g，除了使用RMAN方式之外，我们可以使用带dblink的datapump方式来实现基于逻辑上的迁移。其步骤也相对简单，而且不会产生中间过程生成的dump文件。本文即针对如何使用该方法给出了示例，供大家参考。
https://education.oracle.com/oracle-certification-exams-list
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
