Manage Audit File Directory Growth with cron (Doc ID 1298957.1)

本文指导如何使用Linux cron工具管理Oracle ASM实例的审计文件目录,以避免因文件数量过多导致的磁盘空间不足、inode耗尽或系统运行缓慢等问题。

APPLIES TO:

Oracle Database Products > Exadata > Database Machine
Oracle Database - Enterprise Edition - Version 11.1.0.7 to 11.2.0.3 [Release 11.1 to 11.2]
Information in this document applies to any platform.
***Checked for relevance on 29-Apr-2013***

PURPOSE

The audit file destination directories for an ASM instance can grow to contain a very large number of files if they are not regularly maintained.  Having a very large number of files can cause the file system to run out of free disk space or inodes, or can cause Oracle to run very slowly due to file system directory scaling limits, which can have the appearance that the ASM instance is hanging on startup.

This document explains how to use the Linux cron(8) utility to manage the number of files in the audit file destination directories.

SCOPE

These steps must be performed for the ASM instance on every database server.

This document explains how to manage the audit file destination directories for ASM instances only.  For complete database auditing overview and instruction on managing and purging the database audit trail, refer to the Oracle Database Security Guide at http://download.oracle.com/docs/cd/E11882_01/network.112/e16543/auditing.htm#BCGIDBFI .

DETAILS

Step 1 - Identify the ASM audit directories

There are three directories that may contain audit files.  All three must be managed to control excessive growth.

Two default locations are based on environment variable settings when the ASM instance is started.  To determine the default locations for your system, login as the Grid Infrastructure software owner (typically either oracle or grid), set your environment so that you can connect to the ASM instance, then run the 'echo' commands provided below.  In this example, the two default audit directories are /u01/app/11.2.0.2/grid/rdbms/audit and /u01/app/oracle/admin/+ASM1/adump.

$ . /usr/local/bin/oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base for ORACLE_HOME=/u01/app/11.2.0.2/grid is /u01/app/oracle

$ echo $ORACLE_HOME/rdbms/audit
/u01/app/11.2.0.2/grid/rdbms/audit

$ echo $ORACLE_BASE/admin/$ORACLE_SID/adump
/u01/app/oracle/admin/+ASM1/adump



The third ASM audit directory can be found by logging into the ASM instance with SQL*Plus and running this statement:

$ sqlplus '/ as sysasm'

SQL> select value from v$parameter where name = 'audit_file_dest';

VALUE
--------------------------------------------------------------------------------
/u01/app/11.2.0.2/grid/rdbms/audit


All three ASM audit directories will be managed with cron(8).

Step 2 - Give Grid Infrastructure software owner permission to use cron

Audit files are owned by the Grid Infrastructure software owner, which is typically either oracle or grid.  Commands to move or remove audit files must be run as the Grid Infrastructure software owner.  As root, add the Grid Infrastructure software owner to /etc/cron.allow file.  The examples below use the user oracle.

# echo oracle >> /etc/cron.allow



Step 3 - Add command to crontab to manage audit files weekly

As the Grid Infrastructure software owner, add an entry to the crontab file.  The following command will start a vi(P) command edit session to edit the existing crontab file or create a new crontab file if one does not already exist.

$ crontab -e



 Add the following to this file as a single line:

0 2 * * sun /usr/bin/find /u01/app/11.2.0/grid/rdbms/audit /u01/app/11.2.0.2/grid/rdbms/audit /u01/app/oracle/admin/+ASM1/adump -maxdepth 1 -name '*.aud' -mtime +30 -delete


This crontab entry executes the find(1) command at 2AM every Sunday. The find(1) command deletes all audit files in the three ASM audit directories that are older than 30 days.

If you wish to retain audit files for a longer period of time, instead of deleting the audit files with the find(1) command, you can archive audit files to a different directory or storage device using a crontab entry like the following: 

0 2 * * sun /usr/bin/find /u01/app/11.2.0/grid/rdbms/audit /u01/app/11.2.0.2/grid/rdbms/audit /u01/app/oracle/admin/+ASM1/adump -maxdepth 1 -name '*.aud' -mtime +30 -execdir /bin/mv {} /archived_audit_dir \;


This crontab entry executes the find(1) command at 2AM every Sunday. The find(1) command moves all audit files in the three ASM audit directories that are older than 30 days to /archived_audit_dir.


Save and exit the crontab file using vi commands (<ESC> :wq), then verify crontab contents.

$ crontab -l
0 2 * * sun /usr/bin/find /u01/app/11.2.0/grid/rdbms/audit /u01/app/11.2.0.2/grid/rdbms/audit /u01/app/oracle/admin/+ASM1/adump -maxdepth 1 -name '*.aud' -mtime +30 -delete



Troubleshooting

If old audit files are not being removed, perform the following steps:

  • To monitor that cron(8) is executing the /usr/bin/find command on schedule and as the correct Grid Infrastructure software owner, review the /var/log/cron file as the root user for an entry like the following:
Feb 20 02:00:01 dm01db01 crond[6936]: (oracle) CMD (/usr/bin/find /u01/app/11.2.0/grid/rdbms/audit /u01/app/11.2.0.2/grid/rdbms/audit /u01/app/oracle/admin/+ASM1/adump -maxdepth 1 -name '*.aud' -mtime +60 -delete)

 

  • Log in as the user that owns the crontab entry (i.e. the Grid Infrastructure software owner).  Run the find(1) command manually to verify the correctness of the command syntax and that there are no errors reported.
内容概要:本文详细介绍了“秒杀商城”微服务架构的设计与实战全过程,涵盖系统从需求分析、服务拆分、技术选型到核心功能开发、分布式事务处理、容器化部署及监控链路追踪的完整流程。重点解决了高并发场景下的超卖问题,采用Redis预减库存、消息队列削峰、数据库乐观锁等手段保障数据一致性,并通过Nacos实现服务注册发现与配置管理,利用Seata处理跨服务分布式事务,结合RabbitMQ实现异步下单,提升系统吞吐能力。同时,项目支持Docker Compose快速部署和Kubernetes生产级编排,集成Sleuth+Zipkin链路追踪与Prometheus+Grafana监控体系,构建可观测性强的微服务系统。; 适合人群:具备Java基础和Spring Boot开发经验,熟悉微服务基本概念的中高级研发人员,尤其是希望深入理解高并发系统设计、分布式事务、服务治理等核心技术的开发者;适合工作2-5年、有志于转型微服务或提升架构能力的工程师; 使用场景及目标:①学习如何基于Spring Cloud Alibaba构建完整的微服务项目;②掌握秒杀场景下高并发、超卖控制、异步化、削峰填谷等关键技术方案;③实践分布式事务(Seata)、服务熔断降级、链路追踪、统一配置中心等企业级中间件的应用;④完成从本地开发到容器化部署的全流程落地; 阅读建议:建议按照文档提供的七个阶段循序渐进地动手实践,重点关注秒杀流程设计、服务间通信机制、分布式事务实现和系统性能优化部分,结合代码调试与监控工具深入理解各组件协作原理,真正掌握高并发微服务系统的构建能力。
从错误信息 `stat of /etc/var/log/audit/audit.log failed: No such file or directory` 可知,系统在尝试获取 `/etc/var/log/audit/audit.log` 文件的状态时,发现该文件或目录不存在。可参考以下方法解决: ### 检查路径是否正确 要确认 `/etc/var/log/audit/audit.log` 路径是否准确,因为 `/etc` 通常用于存放系统配置文件,而日志文件一般存于 `/var/log` 目录。正确路径或许是 `/var/log/audit/audit.log`。 ### 创建缺失的目录和文件 若路径无误,但目录或文件缺失,可按如下步骤创建: 1. **创建目录**:使用 `mkdir` 命令创建 `/var/log/audit` 目录。若权限不足,需使用 `sudo` 提升权限。示例如下: ```bash sudo mkdir -p /var/log/audit ``` 这里的 `-p` 选项可确保在父目录不存在时一并创建。 2. **创建文件**:使用 `touch` 命令创建 `audit.log` 文件。示例如下: ```bash sudo touch /var/log/audit/audit.log ``` ### 检查文件权限 确保当前用户对 `/var/log/audit/audit.log` 文件有足够的访问权限。可使用 `chmod` 命令修改文件权限,使用 `chown` 命令修改文件所有者和所属组。示例如下: ```bash sudo chmod 640 /var/log/audit/audit.log sudo chown root:audit /var/log/audit/audit.log ``` 上述命令将文件权限设置为 640(即所有者可读写,所属组可读,其他用户无权限),并将文件所有者设为 `root`,所属组设为 `audit`。 ### 检查服务配置 若该文件由某个服务生成和使用,要检查服务配置文件,确认日志文件路径是否正确。例如,若使用 `auditd` 服务,可检查 `/etc/audit/auditd.conf` 文件中的 `log_file` 参数。 ### 重启相关服务 创建目录和文件后,重启相关服务使配置生效。若使用 `auditd` 服务,可使用以下命令重启: ```bash sudo systemctl restart auditd ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值