This article reviews a historical disk-capacity case involving ODI 12.2.1.2 integrated with Oracle Retail. Its paths and capacity figures describe that installation, not a standard layout or sizing requirement for all ODI environments.
Storage utilization in that case reached 99%. The review starts with identifying space consumers, then checking retention and recovery requirements before choosing cleanup targets. It does not guarantee the same outcome in a current environment.
Insufficient free space can interrupt integration jobs or prevent log and backup writes. Check the failed operation and its logs before attributing the failure to disk capacity.
- Failed data integrations due to insufficient temporary space
- Failed log writes and missing diagnostic records
- Failed backup writes or incomplete backup files
- Processing delays associated with temporary-file failures or space recovery
Start by checking used and available space on each filesystem.
The 80% utilization and 20% free-space figures are example alert thresholds, not universal Oracle ODI requirements. Set thresholds using growth rate, peak temporary-space needs, backups and the time needed to respond.
Compare utilization with recent growth and peak workload needs.
Review these indicators alongside utilization:
- Exceeding an environment-specific alert threshold (80% is the example here)
- Rapidly decreasing free space
- Large temporary file accumulation
This case groups RI Stage, RDE and OBIEE-related paths for capacity analysis. The diagrams and 20GB, 15GB and 80GB figures illustrate the historical case; they are not a standard ODI directory layout or product sizing specification.
1. RI Stage Area
The RI Stage area in this case held backups, configuration and log files. Review growth by file type and the retention needed for recovery rather than treating 20GB as a general requirement. Backup age alone is not a sufficient reason to delete a file.
2. RDE Area
The RDE area contained middleware and Java-related runtime files. Distinguish installation files, active runtime files and backups, then check which paths services depend on before selecting cleanup targets.
3. OBIEE Application Storage
For OBIEE-related paths, measure middleware, installed versions and caches separately. The 80GB figure is an illustration from this case. An apparently old version may still be needed by a service or recovery procedure; check dependencies before deleting it.
Check the filesystem and mount point for each path. Several application directories may share the same capacity limit.
An ODI repository database has its own storage and retention considerations. Filesystem cleanup and repository-log maintenance are separate tasks.
Step-by-Step Storage Optimization
Work through usage analysis, validation of cleanup procedures, and retention policy. Check recoverability as well as the space each action would release.
Phase 1: Problem Area Analysis
Identify paths and file types before considering cleanup. The first command selects .log files by modification age and sorts the listing; it is not a complete inventory of large files. The second summarizes directory usage. Confirm the example paths in your installation.
1. Inspect log files selected by modification age:
find /usr01 -name "*.log" -type f -mtime +30 -ls | sort -k7 | head -20
2. Find storage-heavy directories:
du -h --max-depth=3 /usr01/oracle/Middleware | sort -rh | head -10
Phase 2: Implement Regular Maintenance
The script below compresses and deletes rotated file logs matching .out[0-9]* and .log[0-9]*; it does not cover every .out or .log file. The +90 and +365 tests use modification age. A directory-existence check does not make deletion safe. Confirm paths, candidate files, active jobs, retention obligations and recoverable backups, and validate in non-production before running or scheduling it. File cleanup is separate from purging session and Load Plan history in the ODI work repository.
#!/bin/bash # Oracle ODI Storage Management Automation Script # This script automates log compression and deletion. TARGET_DIR="/usr01/oracle/Middleware/logs" # Check directory existence if [ ! -d "$TARGET_DIR" ]; then echo "Error: Directory $TARGET_DIR does not exist" exit 1 fi cd "$TARGET_DIR" || exit 1 echo "Working in directory: $TARGET_DIR" # Compress logs older than 90 days find "$TARGET_DIR" -name "*.out[0-9]*" -type f -mtime +90 -exec gzip {} \; find "$TARGET_DIR" -name "*.log[0-9]*" -type f -mtime +90 -exec gzip {} \; # Delete compressed logs older than 1 year find "$TARGET_DIR" -name "*.out[0-9]*.gz" -type f -mtime +365 -delete find "$TARGET_DIR" -name "*.log[0-9]*.gz" -type f -mtime +365 -delete echo "Cleanup completed in $TARGET_DIR"
These example checks do not prove cleanup safety:
- Directory existence validation
- Both .out and .log file handling
- Directory navigation with an exit on failure
- Status messages that do not verify every operation succeeded
The 02:00 crontab illustrates scheduling. Validate paths, permissions, retention, failure reporting and alerts before choosing a schedule.
# Run at 2 AM every day 0 2 * * * /path/to/odi_storage_cleanup.sh
Phase 3: Establish Storage Policies
Choose retention from recovery objectives, audit requirements and workload schedules. The 30-day and 90-day examples below differ from the earlier +90 and +365 script; do not combine them as one policy.
Set these key policies:
- Backup Management
Thirty-day retention and compression after seven days are historical examples, not recommended defaults. The code below only deletes .bak and .backup files by its 30-day test; it neither compresses nor copies them to another volume. The /*/backup pattern can expand to multiple paths. Confirm targets and recoverability before running it. A separate volume alone does not guarantee backup safety.
# Clean backup files older than 30 days
find /*/backup -name "*.bak" -mtime +30 -delete
find /*/backup -name "*.backup" -mtime +30 -delete
- Log Rotation
- This example compresses .log files matching the +30 modification-age test
- It deletes .gz files matching +90: check for required diagnostics and unrelated compressed files
- Review retention, expanded paths and growth before applying it
# Compress logs older than 30 days
find /*/logs -name "*.log" -mtime +30 -exec gzip {} \;
# Delete compressed logs older than 90 days
find /*/logs -name "*.gz" -mtime +90 -delete
- Temporary File Cleanup
- Check reprocessing and recovery needs after a successful load
- The example deletes /stage files using +30 modification age, not seven days
- Confirm active-file dependencies and candidate files before authorizing cleanup
# Remove temporary files older than 30 days
find /stage -type f -mtime +30 -delete
These commands illustrate different policies. Verify each selection pattern and retention rule before adoption.
A script does not replace monitoring, recovery testing or repository-log management. A successful schedule invocation does not prove every operation succeeded.
Storage Operations Checklist
The following diagram lists planning examples. Its 80% alert and 20% buffer are not universal requirements; choose values from measured growth, peak temporary space and response time.
Common Mistakes to Avoid
Include these checks in the maintenance plan:
- Temporary files: track growth during data loads and check active-job dependencies before cleanup.
- Backup retention: use recovery and audit requirements to choose what to retain; verify restoration before deleting older copies.
- Scheduled maintenance: review growth and failure records after scheduling cleanup, and revisit thresholds when workloads or retention requirements change.
When to Seek Help
Involve the DBA, application owner and storage team when recovery requirements or service dependencies are unclear. Review cleanup and capacity plans together, especially when:
- Utilization repeatedly exceeds the chosen alert threshold, or available space cannot support the workload (90% is an example)
- Experience frequent space issues
- Need to scale your environment
Conclusion
Storage management combines usage analysis, retention policy and recovery validation. The summary diagram describes goals, not guaranteed performance or prevention outcomes. This historical case does not establish a safe cleanup schedule or deletion policy for your current environment.
When sharing a question or operational case, include the ODI version, affected paths and file types, and observed growth. Use this case to review cleanup targets and recovery requirements rather than adopting its commands or retention periods unchanged.