Database With SanGa

If you’ve ever had to recover a single table in Oracle without touching the rest of your database, you know it can feel like performing surgery on a live patient. That’s where RMAN ’s auxiliary destination comes to the rescue. What Is the Auxiliary Destination? In simple terms, it’s a temporary workspace where Oracle can safely restore and recover a table before it goes back into the main database. Think of it as a sandbox: everything happens there first, away from the production environment, so nothing breaks if something goes wrong. When I first started using it, I was worried about messing up live data. But once I understood the concept, it made table-level recovery so much smoother. Why You Need It You can’t just yank a table out of a backup and drop it into a running database—especially if users are working on it. RMAN needs a safe place to do its magic : It restores the table from backups. It applies redo logs to bring the table to the exact point-in-time you nee...

Recently, I faced a synchronization issue in one of our Oracle GoldenGate (OGG) environments. The setup was designed to extract table data from an Oracle database and replicate it into a Microsoft SQL Server target . After creating a new extract group using the begin now option, I noticed that a portion of the data had not synced correctly. Recovery was required to ensure the target database was fully consistent. Here’s the step-by-step process I followed to resolve the issue 👇 🧰 Step 1: Stop Existing Processes I began by stopping the currently running extract and replicat groups to prevent any further replication while investigating the issue. ⚙️ Step 2: Create a New Extract Group A new extract group was created on the source Oracle database, specifying a precise timestamp to capture all transactions from the point where data loss began. 📝 Step 3: Update the Parameter File The new extract group’s parameter file was updated with the required environment settings, dat...

Recently, I faced an interesting performance issue in one of our Oracle 10g databases running on IBM AIX . The system had become noticeably slow , and user operations were taking longer than usual. When I started investigating, I discovered that the database was holding a large number of inactive (idle) sessions — most of them left open by the application layer . These idle sessions were quietly consuming system resources, leading to overall slowness. ⚙️ The Immediate Fix As a temporary measure, I manually killed the inactive sessions to free up resources. This immediately improved system responsiveness, but it was only a short-term solution. I needed a more permanent fix to ensure that idle sessions wouldn’t keep piling up in the future. 🧠 The Long-Term Solution — Profile Configuration To automate the management of idle sessions, I decided to create a new Oracle profile with an idle time limit of 30 minutes . 🏗️ Step 1: Create a New Profile CREATE PROFILE IDLE_30MIN L...

Recently, I encountered an interesting challenge while working with Oracle Data Redaction . A database user had been granted the following privilege: GRANT EXEMPT REDACTION POLICY TO APP_SCHEMA; Naturally, I expected that the redacted data would now appear unmasked everywhere . But to my surprise — the data was clearly visible in SQL Developer , yet still masked inside the application . 🤔 🔍 Investigating the Behavior At first glance, this seemed like a strange inconsistency. If the user APP_SCHEMA already had the EXEMPT REDACTION POLICY privilege, why was the data still masked in the application? After checking with the client, they mentioned an important detail: “Our application does not connect directly as APP_SCHEMA — it connects through a connection pool using another database user.” 💡 That one line changed everything. 🧠 Understanding What Was Really Happening Oracle Data Redaction works per database session , not by the logical application user. Here’s w...

Recently, I came across an interesting situation while performing a space management task on one of our databases. The challenge involved a table that contained BLOB data distributed across multiple tablespaces . What seemed like a simple shrink operation ended up turning into a deeper learning experience that I’d like to share. 🧩 Background In this environment, the main table BINARY_ARCHIVE was stored in the MAIN_DATA tablespace. Its BLOB segment was placed separately in the ATTACHMENTS_DATA tablespace to improve performance and manage large object storage efficiently. Additionally, another table called BINARY_OBJECT_LINK maintained a foreign key reference to the BLOB data and resided in the LINK_DATA tablespace. When I attempted to reclaim space from the BLOB segment using the SHRINK SPACE command, Oracle returned the following error. ⚠️ The Error ORA -10635 : Invalid segment or tablespace type 10635. 00000 - " Invalid segment or tablespace type " *Ca...