Feed aggregator

Oracle released VirtualBox 7.2.12 a couple of days ago. This comes hot on the heels of version 7.2.10, which I wrote about here. The downloads and changelog are in the usual places. I’ve done installations on Windows 11 and Linux Mint and both seem OK. As with the last version, on Windows 11 I got away with a straight upgrade, but … Continue reading "Oracle VirtualBox 7.2.12"

Posted by Pete On 25/06/26 At 10:53 AM

Posted by Pete On 02/06/26 At 12:49 PM

Posted by Pete On 28/05/26 At 02:17 PM

Coordinated vs parallel replicat for Oracle GoldenGate initial loads: why coordinated wins and scales a single table.

The post Coordinated Replicats: The Best Way to Do Initial Load appeared first on DBASolved.

Here’s an example that makes perfect sense if you know how Oracle handles data locking. It’s one that I thought I’d published years ago, but it’s not on the blog and the only reference I can find is in a reply to an old Oracle Forum note, so if you’ve seen it before please let me know where.

There are a few difference meanings to the meaning of the word savepoint in Oracle, the one I want to talk about is the one that you can use to set a named marker in the middle of a transaction, carry on modifying data, then “rollback to savepoint {name}” then carry on modifying data before committing. A simple example is the best aid to explanation:

rem
rem     Script:         savepoint_fun.sql
rem     Author:         Jonathan Lewis
rem     Dated:          Jan 2026
rem
rem     Last tested 
rem             23.26.0.0
rem


create table t1 (id number primary key);

insert into t1 values(1);

savepoint SP1;

insert into t1 values(2);
select * from t1;

pause Pausing for session 2, press return

rollback to savepoint SP1;
select * from t1;

pause Pausing for session 3, press return

insert into t1 values(3);
select * from t1;

rollback;
-- commit;
select * from t1;

We create a table with a primary key and insert one row into it, then we create a savepoint call SP1. After inserting a second row we pause to check that we can (from this session) see two rows in the table – ignore the reference to “session 2” for the moment.

We then issue a “rollback to savepoint SP1” and pause so that we can see that the second row has disappeared but the first row is still present – every data change we made between the creation of the savepoint and the rollback to that savepoint has no longer happened, history has been rewritten! (Again, ignore the reference to another session).

Then we insert a 3rd row (or second, second row, depending how you want to count) show that there are two rows in the table and at this point I could have issued a commit to preserve the rows, but I’ve actually issued a basic rollback to show that the creation of the savepoint didn’t affect the state of the first row … it wasn’t a hidden / “accidentally” commit that made it possible to rollback only the second insert.

Here’s the output from the demo – running from SQL*Plus on a Linux terminal session:

Table created.


1 row created.


Savepoint created.


1 row created.


        ID
----------
         1
         2

2 rows selected.

Pausing for session 2, press return


Rollback complete.


        ID
----------
         1

1 row selected.

Pausing for session 3, press return


1 row created.


        ID
----------
         1
         3

2 rows selected.


Rollback complete.


no rows selected

It’s time to look at the pause points where a second and third session come into play.

On the first pause, start up a second session and execute "insert into t1 values(2)". The session will hang because it has to wait for session 1 to commit (at which point session 2 will fail with a “duplicate key” error) or rollback (at which point session 2 will report “1 row created”).

Go back to session 1 and press return to allow it to continue – it performs the rollback to savepoint SP1, and row 2 no longer exists, in fact the row has now “never existed”. Do you think that the insert from session 2 should now succeed as the “ghost” duplicate key has ceased to have existed? (The grammar gets a little messy – I am reminded of the discussion in Goudlas Adams’ “Restaurant at the End of the Universe”.)

Session 2 is still waiting for session 1 to commit or rollback.

But session 1 is now at a pause – so start up a third session and execute "insert into t1 values(2)". This is, of course, the statement that has resulted in session 2 hanging; will session 3 also hang at this point?

Session 3 will succeed in inserting the row that has left session 2 (still) waiting on session 1.

Finally, we press return on session 1 and (in this example) it rolls back – what happens to session 2? It’s still waiting, but now it’s waiting for session 3 to commit or rollback because it’s now session 3 that has inserted a row with a conflicting primary key. I’ve included statements before the session 1 rollback that insert id = 3 and report the rows that session 1 can see, and after the rollback I’ve again reported the rows that session 1 can see. This is just to confirm that id=1 and id=3 are both part of the same transaction and that id=1 wasn’t somehow committed as the sequence of events took place.

It’s a nice little enhancement in the 23.26 release (possibly a little earlier) that when I issued a commit from session 3 the error message reported from session 2 was rather thorough:

insert into t1 values(2)
*
ERROR at line 1:
ORA-00001: unique constraint (TEST_USER.SYS_C0013725) violated on table
TEST_USER.T1 columns (ID)
ORA-03301: (ORA-00001 details) row with column values (ID:2) already exists
Help: https://docs.oracle.com/error-help/db/ora-00001/

When session 2 starts waiting it is not paying any attention to the table or index entries for the row with id = 2; having discovered that there is an uncommitted insert of the same (unique) key value it puts itself into a queue that’s waiting for the owning transaction to commit or rollback.

When the “rollback to savepoint” is complete the database is in a state where session 1’s blocking insert has (logically) never happened. So when session 3 tries to insert a row with id = 2 there is nothing in the index leaf block to suggest that there is, or ever has been, a prior entry with that value. So the insert succeeds.

When session 1 finally rolls back, session 2 is posted and tries to perform its insert – and finds that there is an uncommitted insert of the same (unique) key value,, so once again it puts itself into a queue that’s waiting for the owning transaction (in this case the transaction started by session 3) to commit or rollback. From the client side we don’t notice that session 2 is now waiting for session 3 rather than waiting for session 1.

The long version started to get far too long, so I’ve just got a few extracts from block dumps of the index block that I took at a couple of key points in the demo, and these may give you a better visual understanding of what the “rollback to savepoint2 has achieved.

We start weith three pieces of a block dump taken just after session 1 has done its second insert:

Block dump from disk:
buffer tsn: 7 rdba: 0x0400008b (16/139)
scn: 0x23b7647 seq: 0x02 flg: 0x04 tail: 0x76470602



 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0x0002.002.0000061a  0x00000d72.014d.32  ----    2  fsc 0x0000.00000000



row#0[8021] flag: -------, lock: 2, len=11, data:(6):  04 00 00 85 00 00
col 0; len 2; (2):  c1 02
row#1[8010] flag: -------, lock: 2, len=11, data:(6):  04 00 00 85 00 01
col 0; len 2; (2):  c1 03

The 1st section tells us that this is block 139 of file 16, and shows its last change SCN to be 0x23b7647 – that SCN is worth remembering.

The 2nd section is the Itl (interested transaction list) and slot 0x02 on that list shows a transaction (Xid) 2.2.61a which is locking (Lck) 2 entries, and tells us that the first undo record (Uba) we need to visit if we want to start rolling back any changes made to this block by this transaction is record 0x32 in undo block 0xd72.014d – pointers like these allow a session to start building “read-consistent” versions of blocks, but you need to read Oracle Core if you want to appreciate the fine detail. (The record number 0x32is also worth remembering)

The 3rd section just shows you that there are currently two rows (index entries) in the block, holding the key values 1 (c1 02) and 2 (c1 03) respectively. Both rows are locked (lock:) by the transaction listed in Itl entry 0x02.

Now the corresponding extracts from the same block ump after session 1 has issued its rollback to savepoint:

Block dump from disk:
buffer tsn: 7 rdba: 0x0400008b (16/139)
scn: 0x23b7771 seq: 0x01 flg: 0x04 tail: 0x77710601



 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0x0002.002.0000061a  0x00000d72.014d.30  ----    1  fsc 0x0000.00000000



row#0[8021] flag: -------, lock: 2, len=11, data:(6):  04 00 00 85 00 00
col 0; len 2; (2):  c1 02

Again the 1st section tells us that this is block 139 of file 16, and shows its last change SCN to be 0x23b7771 – time has passed, actions have occured – the last change SCN has increased from 0x23b7647 since the previous dump.

When we examine (and compare) the Itl in the second section we can see that entry 0x02 is still listing the same transaction (Xid), but the transaction is locking just one entry in the block, and the first undo record that would be needed to rollback the most recent change made by this transaction has gone backwards by 2 records to record 0x30 of undo block 0xd72.014d.

Finally looking at the list of rows (index entries) in the block we see that there is just one – the row that was stored at offset 8010 has vanished. Of course the fact that I haven’t printed “rows#1[8010]” doesn’t mean that it isn’t there (it can be quite hard to prove that something doesn’t exist!) so here’s a little corroborative evidence from the two versions of the block summary:

After the second insert
-----------------------
kdxconro 2
kdxcofbo 40=0x28
kdxcofeo 8010=0x1f4a
kdxcoavs 7970

After the rollback to savepoint
-------------------------------
kdxconro 1
kdxcofbo 38=0x26
kdxcofeo 8021=0x1f55
kdxcoavs 7983

• kxconro (number of current rows in the block) drops from 2 to 1
• kxcoavs (available free space in the block) increases from 7970 to 7983 .. . 11 bytes of row, 2 bytes for the row’s directory entry
• kdxcofbo (offset to beginning of free space) decreases from 40 to 38 – because the row directory is 2 bytes shorter
• kdxcofeo (offset to end of free space) increased from 8010 to 8021 – because the 11 bytes of the id=2 entry are now free space.

Everything about the block after the rollback to savepoint says “index entry with id = 2” never happened, so session 3 can do an insert when it wants to, while session 2 is looking in the wrong place waiting for some traffic lights to change.

If you’re wondering about the physical aspect of savepoints – they seem to exist only as entries in shared memory, there is no file-based information about them. If you want to see the all the (user defined) savepoints they are visible in x$ktcsp. Interestingly all the savepoint points defined during the course of a transaction seem to persist until the transaction commits or rollsback, even when a “rollback to savepoint X” has taken place. There’s probably a good technical reason for this – but it could simply be a common Oracle strategy: don’t bother to clear up a little bit of mess until you have to or when it’s easiest to do so.

You’ve seen the Uba pointer on the index block drop from 0x32 to 0x30 because of the rollback to savepoint. The two “missing” or “redundant” records still exist in the undo block, and the next change made by that transaction will create record 0x33 in the block (assuming it has enough space to do so). When a transaction rolls back it walks backwards through the undo records and uses them to reverse out (logically) the changes made in the reverse order to which they were made. One of the many tiny but critical details that Oracle code deals with internally is that record 0x33 will point to record 0x30 rather than record 0x32, similarly of course, record 0x30 will point forwards to record 0x33.

Finally – another little question: as a super-user with powers to bypass read-consistency and do block dumps: how many rows – or fossils of rows – would you be able to find in the table with id = 2? The answer is 3, though you may have to be a little subtle in how you go about finding all the fossils. Some people may have thought the answer was 2 – the one that was inserted and then rolled back by session 1, and the one finally inserted by session 3. I heard suggesions in the past that session 2 wouldn’t insert a row because it’s blocked waiting on the unique index; but (ordinday b-tree) index entries include a rowid so Oracle can’t create an index entry until it has inserted a row and found the rowid.

In IT, it is essential to stay up to date, as technology evolves at an ever-accelerating pace.

As consultants, we constantly face new challenges, many of which extend beyond purely technical matters, while adapting to diverse contexts and audiences.

That’s what makes this profession so exciting!

At dbi services, knowledge sharing is deeply embedded in our culture.

Over the past three months, I’ve had the opportunity to share my experience working on ECM projects for years.

This post concludes the series by highlighting the key insights that have shaped my approach to these projects.

In my previous roles, I was more of a product specialist than a solutions specialist. My job was to adapt clients’ needs to the software framework.

Now, working for a company that isn’t a “pure player” enables me to select the optimal solution from the beginning rather than having to adapt, of course I love M-Files, but alfresco is another solution we like!

For me, the right approach is certainly not:
“What can this ECM do?”

Rather, it is:
“What business problems do we need to solve first, and for whom?”

ECM initiatives often fail when they attempt to tackle everything at once rather than focusing on what truly matters. In practice, users don’t adopt tools just because they exist, they embrace solutions that directly address their daily pain points. That’s why achieving early, tangible success is critical. It builds credibility and helps secure continued investment.

Rather than implementing broad, I would focus on three to five high-impact use cases, such as invoice processing, contract lifecycle management, and quality documentation.

These cases should deliver measurable results within weeks rather than quarters. Each use case should be treated as its own product, with a clear value proposition and user-centric design, rather than as just another feature within a larger system.

I used to think: “If the solution is good, people will use it.”

That’s wrong.

Adoption requires preparation. It doesn’t just happen on its own.

The hard truth is that the best ECM solution with no adoption equals failure.

What I’d do differently:

• Identify the key users early on. They will help you get the solution adopted
• Design in collaboration with actual users, not with their representatives.
• Invest time and resources in on-boarding with in-app guidance, simple training paths, and internal champions.

Remember, if users need a manual to use the solution, you’ve already lost them.

One of the biggest mistakes I’ve seen (and made) is overengineering metadata and taxonomy.

We aimed for a perfect structure. We got complexity.

The reality is that users don’t care about your taxonomy. It adds complexity, makes classification difficult, slows down their work, and ultimately reduces user adoption.

Here’s what I’m doing now:

• I’m trying to limit the number of fields to seven or fewer.
• I take full advantage of automation features, such as default values, smart classification, and recognition.
• I use an iterative approach if it results in tangible improvements.

A good structure that is used consistently is better than a perfect one that nobody follows.

Projects often treat automation as a second phase. For me, that’s a mistake.

Today, without automation, ECM is just a digital archive.

Here are some things to do from day one:

• It is essential to pinpoint tasks that are repetitive in nature and convert them into workflows. Examples of such tasks include approvals, classification, team collaborations, and more. This conversion process must be incorporated into the initial release.
• Use AI carefully and for meaningful topics. AI is trendy and can benefit us if we use it to accelerate work in areas such as classification, translation, and summarization, not just because it’s hype.

The goal is to eliminate unnecessary work and allow users to focus on what is important.

Keep in mind that success metrics are not the number of documents migrated, users trained, or system uptime.

True success is measured by the positive impact the solution brings, such as reduced processing time, increased adoption, improved compliance, and saved time.

Measure the real impact to prove added value.

This is a common mistake that I still often see during ECM implementation, and it needs to change.
An ECM is not a static project consisting of analysis and implementation, and then it’s finished.

We must adopt an agile approach of building, learning, improving, and repeating.

As soon as users start using the solution, we must maintain a backlog of improvements, perform regular releases, and continuously gather user feedback.

An ECM project is never truly finished because it must evolve with business needs. Otherwise, businesses will adapt their work to the tool and slowly abandon it.

Although governance is essential, it can also become an obstacle.

I’ve seen governance frameworks delay projects by several months because they lack flexibility.

Nothing is perfect, so while you should meet compliance requirements, keep things simple.

Clearly define responsibilities from the start:

• Who is responsible for metadata?
• Who approves changes?

Ensure that governance remains light and practical.

Strike the right balance between control and ease of use.

Although IT leads this type of project, users are often not part of the team.

Therefore, establishing strong collaboration between IT and business users is crucial.

Involve users in the decision-making process.

Hold them accountable for adoption, this is a company-wide project, and its success depends on them.

To sum up my years of experience in ECM.

While it’s initially reassuring to master a product and understand its inner workings, ultimately, clients don’t care about that.

They have various problems and want a solution and very often, the specific product doesn’t matter.

They count on us to recommend the most suitable solution because they are busy running their business and don’t have time to compare products on the market.

ECM success isn’t just about managing documents; it’s about enabling better work.

• Help users work more efficiently.
• Provide business value.
• Improve the user experience over time.

If you’re about to start a project, ask yourself:

• Are we solving real problems?
• Are users involved from day one?
• Are we delivering value early on?

If not, now is the perfect time to ask us for help!

L’article After years of ECM projects, here’s how I do things differently nowadays est apparu en premier sur dbi Blog.