All the database users are presently connected to the database instance and working. The HR user has opened three database sessions and executed the following command in one of his sessions: SQL>…

HR's other two open sessions cannot see the uncommitted changes because Oracle's transaction isolation is scoped to the individual session, not to the database user account - sibling sessions for the same user behave identically to sessions of any other user when reading committed data.

The SYS user's session cannot see the uncommitted changes because Oracle's default read committed isolation level prevents any session from reading another session's dirty data, regardless of the privilege level of the querying user.

Oracle enforces statement-level and transaction-level read consistency by using undo segments to serve older, committed versions of data to all sessions other than the one holding the transaction. Because HR has not issued a COMMIT, the UPDATE and DELETE changes exist only within that specific session's transaction context. Every other session - including HR's other two sessions and the newly opened SYS session - queries the last committed version of the PERSONS table and cannot see those pending changes.

Having SELECT privilege on the PERSONS table controls whether a user can access the table at all, but it has no bearing on transaction visibility - no amount of privilege grants a session the ability to read another session's uncommitted transaction data.