oracle系统

2018-01-18 10:01 AlfredZhao 阅读( 435) 评论( 0) 编辑 收藏 主题： 针对Oracle的审计方案 数据库环境： Oracle 11g 数据库审计需求： 1.需要对连接数据库的行为进行审计 2.需要对核心表的DML操作进行审计 3.需要迁移审计数据到指定表空间 4.需要清理历史审计数据的方案 1.需要对连接数据库的行为进行审计 需要对连接数据库的行为进行审计，其中包含例如审计那些错误密码登录等失败的登录行为。 主要关注查询的表就是 aud$ 。 比如查询最近一天使用错误密码登录的行为； --aud$ select sessionid, userid, userhost, comment$text, spare1, ntimestamp# from aud$ where returncode = 1017 and ntimestamp# > sysdate - 1; --dba_audit_trail select * from dba_audit_trail where returncode = 1017 and timestamp > sysdate - 1; 更多关于aud$的介绍可参考之前我总结过的文章： aud$定位错误用户密码登陆数据库的具体信息 2.需要对核心表的DML操作进行审计 需要对核心表的DML操作进行审计

 之前整理过一篇有关绑定变量的文章，不太详细，重新补充一下。 Oracle 绑定变量 http://www.cndba.cn/Dave/article/1275 一．绑定变量 bind variable ： A variable in a SQL statement that must be replaced with a valid value, or the address of a value, in order for the statement to successfully execute. 变量绑定是 OLTP 系统中一个非常值得关注的技术。良好的变量绑定会使 OLTP 系统数据库中的 SQL 执行速度飞快，内存效率极高；不使用绑定变量可能会使 OLTP 数据库不堪重负，资源被 SQL 解析严重耗尽，系统运行缓慢。 当一个用户与数据库建立连接后，会向数据库发出操作请求，即向数据库送过去 SQL 语句。 Oracle 在接收到这些 SQL 后，会先对这个 SQL 做一个 hash 函数运算，得到一个 Hash 值，然后到共享池中寻找是否有和这个 hash 值匹配的 SQL 存在。 如果找到了， Oracle 将直接使用已经存在的 SQL 的执行计划去执行当前的 SQL ，然后将结果返回给用户。 如果在共享池中没有找到相同 Hash 值的 SQL ， oracle

Buffer Cache与Shared Pool是SGA中的最重要和最复杂的两个部分。 5.1 Buffer Cache原理 当一个进程需要访问数据时，首先需要确定数据在内存中是否存在： 如果数据在buffer中存在，则需要根据数据的状态来判断是否可以直接访问还是需要构造一致性读取； 如果数据在buffer中不存在，则需要在buffer cache中寻找足够的空间以装载需要的数据，如果在buffer cache中找不到足够的空间，则需要触发dbwn去写脏数据，释放buffer空间。 5.1.1 LRU与Dirty List 在buffer cache中，oracle通过几个链表进行内存管理，其中最为人熟知的是LRU List和Dirty List。 数据库初始化时，所有的Buffer都被hash 到LRU List上管理，当需要从数据文件上读取数据时，首先要在LRU LIst上寻找Free的Buffer，然后读取数据到Buffer cache中；当数据被修改后，状态变为dirty，就可以被移动至dirty list（checkpoint queue），dirty list上的都是候选的可以被DBWR写出到数据文件的buffer，一个buffer要么在LRU List上，要么在Dirty List上存在，不能同时存在于多个List。 Buffer Cache的原理： （1

一、使用场景： 1、需要开放ERP数据给第三方系统对接，如APP手机端开发，MES，OA等； 2、接口按现在主流开发，restful风格，传JSON数据，跨平台，不限开发工具； 3、不限易飞ERP，支持大部分主流数据库，包括Microsoft SQL Server、Oracle、MySQL、MariaDB、PostgreSQL、DB2、SQL Anywhere、Firebird、SQLite等 二、优点 ： 1、只要会SQL就可以开放需要的数据，不需要编程基础。如图： ​ 三、测试DEMO： 下载地址： 点击 。 ​ ​ 来源： https://www.cnblogs.com/redhat588/p/11769392.html

本地环境 服务器：华为 V5885 8核16线程 操作系统：Windows Server 2012 R2 64-bit Oracle： 11.2.0.1.0 - Production 问题描述及解决方案 问题描述 在服务器上安装ORACLE11.2.0.1。安装过程没问题，创建数据库实例的时候,卡在2% ，如图： 等待很长时间（大概7、8个小时）之后，会报错，内容溢出，如图： 点击忽略，如图 点击确定，如图 上述表示Oracle并没有被成功安装。 解决办法 打开控制面板，选择管理工具 打开系统配置—引导—高级设置 处理器核数，选择16 ，重启服务器，然后再安装oracle11g. 即可成功。 分析原因 CPU核数太多 来源： CSDN 作者： yawpei 链接： https://blog.csdn.net/yawpei/article/details/78644417

在 windows Server 2008 R2 上安装 oracle 12C 参考文章： http://yunan.blog.51cto.com/4842211/1390937 按章上面的步骤一切顺利，当进度条进行了一大半的时候 接连出现幺蛾子：！！！！ 比如： Failed to create ... oracle home User ； Failed to add … or group to ... group ； 输入oracle服务的用户 的：实例已创建 ； 安装出现 "Oracle Database Configuration Assistant" 失败的错误 ； 。。。 Failed to create ... oracle home User ； Failed to add … or group to ... group ； 首先要去创建一个新用户 如图： 在新安装的AD里建立新用户时总会提示说“ 密码不满足密码策略的要求 ，检查最小密码长度、密码复杂性和密码历史的要求”。参考文章：http://zinhaak.blog.51cto.com/1698/131554 答： 1，打开 域安全策略 （ secpol.msc） -安全设置-账户策略-密码策略-密码必须符合复杂性要求。定义这个策略设置为:已禁用。/ 密码长度最小值：定义这个策略设置为0。 2

oracle 11.2.0.1 for windows server2012R2应用p12429529_112010_MSWIN-x86-64补丁集，也是oracle数据库安全加固的范畴。因为每次oracle数据库加固过程中 总会有些许意外发生，这里记录一次oracle 11.2.0.1 for windows server2012R2应用p12429529_112010_MSWIN-x86-64补丁集。 本次oracle安全加固使用的参考文档： 一、目的 针对windwos server 2012/2012R2平台上运行的oracle数据库 11.2.0.1应用目前可用最新的CPU补丁集p12429529，修复该版本数据库在日常应用中的风险漏洞， 减少应用系统架构非计划停机时间、屏蔽数据库风险漏洞被利用的可能。 二、安全加固基础信息 操作系统类型 数据库版本 预用补丁版本 备注 windows server 2012R2 oracle 11.2.0.1 p12429529_112010_MSWIN-x86-64 　最新CPU windows server 2012 oracle 11.2.0.1 p12429529_112010_MSWIN-x86-64 　最新CPU 三、安全加固操作步骤 1、 对预用补丁集数据库的应用进行关停； 2、 对预用补丁集数据库进行基础健康检查； 3、

1、环境准备（CentOS7.5已安装Development Tools） 创建用户和组 groupadd oinstall groupadd dba useradd -g oinstall -G dba oracle passwd oracle 配置内核参数 touch /etc/sysctl.d/97-oracledatabase-sysctl.conf fs.aio-max-nr = 1048576 fs.file-max = 6815744 kernel.shmall = 2097152 kernel.shmmax = 536870912 kernel.shmmni = 4096 kernel.sem = 250 32000 100 128 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_default = 262144 net.core.wmem_max = 1048576 sysctl --system 配置资源限制 /etc/security/limits.conf oracle soft nproc 2047 oracle hard nproc 16384 oracle soft

在使用sqoop增量抽取数据时，在不指定m的情况下，导出日志中可以看到添加了截止时间，但这个时间并不是系统时间，经过多次比较发现，这个时间比当前系统时间早8个小时。因此怀疑是时区问题。 检查Oracle中的回话时区和数据库时区： SQL> SELECTSESSIONTIMEZONE FROM DUAL; SESSIONTIMEZONE --------------------------------------------------------------------------- +08:00 会话时区是北京时区 SQL> SELECTDBTIMEZONE FROM DUAL; DBTIME ------ +00:00 可以看出正好相差8个小时，因此将数据库时区修改为东8区： 改变数据库时区 SQL> ALTER DATABASE SET TIME_ZONE = '+8:00'; 关闭数据库 SQL> shutdownimmediate 重启数据库 SQL> startup 再次检查时区，如下所示二者已经一致： SQL> SELECT TZ_OFFSET(SESSIONTIMEZONE),TZ_OFFSET(DBTIMEZONE) FROM DUAL; TZ_OFFS TZ_OFFS ------- ------- 再次执行sqoop脚本，此时已经可以正常抽取。 【参考

oracle数据库有两种运行方式：归档（ARCHIVELOG）方式和非归档（NO ARCHIVELOG）方式。在非归档模式下，日志切换时直接覆盖以前的重做日志文件，不产生归档日志。数据库在归档方式下运行，在日志切换后，ARCH进程会对已写满的重做日志文件进行存档，默认情况下，oracle采用非归档模式下运行，主要因为归档方式会给系统带来一定的性能问题。只有当数据库运行在归档方式时，ARCH进程才存在。ARCH进程是oracle的可选后台进程，将日志存档，以便保存对数据库的所有更改。这样即使在数据文件磁盘损坏的情况系下，数据库管理员也能将数据库恢复到故障发生时的状态。 配置数据库归档日志 配置数据库归档日志的方式包括以下3个步骤： 查询数据库的归档方式，确定当前不处于归档方式 以sys用户作为SYSDBA连接目标数据库，然后执行ARCHIVELOG LIST命令查看数据库归档模式： 关闭数据库并启动数据库到mount状态 使用ALTER DATABASE ARCHIVELOG命令将数据库设置为归档模式，并验证数据库的归档模式是否改变 获取归档日志信息 数据字典视图可帮助用户获取数据库配置信息。用户通过使用V$ARCHIVE_DEST和V$ARCHIVE_LOG视图获取归档日志信息 V$ARCHIVE_DEST：显示当前所有归档日志存储位置及其状态 V$ARCHIVE_LOG