Тяги Тяги

Привет. В целом надо понимать, что абсолютно обезопасить свой код от вызова из инструментов разработчика не получится, можно скрыть, но назвать это эффективным подходом тоже нельзя.
Можно попробовать: IIFE (с пониманием того, что IIFE - это изживший себя способ вызова функций, рекомендую почитать о нем ), он должен скрыть код из глобального контекста и скорее всего достучаться к нему через инструменты будет невозможно.

(function() {
  // код
  function secretFunction() {
    console.log("Секрет!");
  }
  // код продолжается
})();

Безопасность чего?

Если каждый раз авторизовать каждого пользователя через его логин/пароль в oci_connect то это будет медленно, есть метод oci_pconnect, он кеширует данные подключения и для следующего вызова, т.е. не получится в разных вызовах скриптов использовать разные авторизации, в документации я этого не нашел, там вообще для изолированных подключений нужно использовать oci_new_connect().

В веб такой (пользователи веб приложения это пользователи oracle) практикой не пользуются (наверное именно из-за вопросов производительности, хотя я это все трогал так давно, еще во времена 7 и 8 версии, теперь есть и пул подключений и возможно еще какие то фичи)
Да, обычно пользователи веб приложения это просто идентификаторы в соответствующей таблице в базе данных приложения, а логин/пароль базы данных oracle - это логин приложения, единый на вес бакэнд (если есть отдельно бакэнд для веб и отдельно десктопное приложение, то тут можно разные логины использовать, но повторяю плохая).

p.s. oracle дорос до скоростей mysql/postgres веб? особенно если речь об мелких объемах

$_POST['SQL'];
Ой, вы доверяете клиенту настолько, что позволяете ему самому формировать текст запроса для бэкенда?
У такой модели взаимодействия уровень безопасности еще ниже, чем у подготовленных запросов со строковой склейкой параметров.
Идеология выполнения скриптов в PHP такая, чтобы выполнить все атомарные действия, зафиксировать результат (или откатиться), отдать ответ и умереть.

Есть какие-то примеры данного "фокуса"?

Есть. Технология называется web sockets, она представляет другую идеологию - называется длинные запросы. Когда клиент открывает соединение с сервером и ждет от сервера сообщений (или сам их отправляет в соккет), при этом скрипт сервера в бесконечном цикле опрашивает открытый соккет. Не завершая скрипт, на сервере можно либо ожидать появление сообщения в соккете, либо выполнять что-то по транзакции, если имеется принятое сообщение.
Проблема еще в том, что PHP не сильно приспособлен для этого режима. Вам придется делать бесконечную петлю обработки в скрипте:

while(true)
{
  // исполняемый код для всех клиентов соккетов
}

И вам нужно самим делать механизм сессий, чтобы отличать одного клиента от другого, поскольку запущенный скрипт будет принимать сообщения от всех клиентов.
Для этих целей больше годится NodeJS. Там все соккеты разбиты по обработчикам событий, можно выделить контекст одного конкретного клиента.
Резюмируя, могу сказать.
а) Вы пишите свой продвинутый редактор запросов (а-ля PHPMyAdmin но с поддержкой транзакций) и у вас неправильно выбран вид сервера для бэкенда (PHP вместо NodeJS). Технические требования для взаимодействия клиента и сервера не имеют подходящей реализации технологии на сервере (web sockets).
б) Либо у вас приложение не предполагает работы, связанной с редактированием запросов пользователем. Вы просто переносите опыт разработки desktop приложений на веб разработку.
В этом случае вы не правильно делаете то, что формируете запросы на клиенте. Толстую бизнес-логику, предполагающую взаимодействие с базой данных с фиксацией или не фиксацией транзакции нужно переносить на бэкенд, либо в хранимые процедуры и функции СУБД.

Непонятно что именно вы таким образом делаете, но в целом похоже на довольно распространенные случаи типа "незавершенная регистрация" или "неоплаченная корзина с покупками", "недописанный и неопубликованный пост" например.
Если эти данные вам не особо нужны можно вместо БД использовать какое-то другое хранилище - сессию или даже localStorage на клиенте.
Если нужны, лучше писать все-таки в базу, ставить пометку о том, что это незавершенная история, или устанавливать время жизни, чтобы потом по расписанию удалить просроченные.

Про сажаю/не сажаю вообще непонятно о чем речь.

select coalesce(t1.col1, t2.col2) as "группировка"
     , coalesce(t1.c, 0)          as "кол-во_1"
     , coalesce(t2.c, 0)          as "кол-во_2"
from (select col1, count(*) c from test group by col1) t1
full join
    (select col2, count(*) c from test group by col2) t2 on t1.col1 = t2.col2
order by 1
;

SELECT value,
       SUM(value = val1) total_1,
       SUM(value = val2) total_2
FROM ( SELECT val1 value FROM test
       UNION 
       SELECT val2 FROM test ) total
CROSS JOIN test
GROUP BY value
ORDER BY value;

DEMO

Само собой если некоего значения нет ни в одном из полей, его не будет и в результате.