Сообщения

SQL SERVER. Автономные транзакции. Autonomous transaction.

     При реализации процесса логирования произведенных операций возникает вопрос о необходимости сам процесс записи в лог проводить в автономной транзакции. В СУБД Oracle есть такой механизм вида:   pragma autonomous_transaction ;             СУБД MS SQL Server не поддерживает автономные транзакции, но есть 3 пути решения заданной задачи:            1. Вызов SQLCLR - процедуры в транзакции.            2. Использование табличной переменной (   table variable   ).         3. Вызов хранимой процедуры через Linked Server к этому же серверу со значением     "True" параметров RPC и RPC Out.      Очень хорошо про способы осуществить автономную транзакцию описаны в статье  http://blogs.msdn.com/b/sqlprogrammability/archive/2008/08/22/how-to-create-an-autonomous-transaction-in-sql-server-2008.aspx.      Только здесь не раскрыт вариант автономной транзакции с помощью SQLCLR. Его и постараюсь здесь привести в пример.          Подготовка сервера для выполнения CLR -

ORA-04043: object SYS_PLSQL_XXXXXXXX_XXX_X does not exist

В этой статье попытаюсь провести расследование на тему - почему появляется ошибка "ORA-04043: object SYS_PLSQL_XXXXXXXX_XXX_X does not exist" и как её решить. Началось всё с попытки перекомпилировать  пакет. Вот полный текст ошибки: ERROR at line 1: ORA-04045: errors during recompilation/revalidation of  TEST_SCHEMA.TEST_LIFE_PG  ORA-04043: object SYS_PLSQL_56A267A9_133_1 does not exist Проанализировав материал по ссылкам (см. Используемая литература), пришла к выводу, что пакет с функционалом PIPE требует внутренние типы Oracle вида "SYS_PLSQL_XXXXXXXX_XXX_X" при условия, А ВОТ ЭТО САМОЕ ИНТЕРЕСНОЕ: если такой, полностью идентичный, объект существует в другой схеме базы данных.  Вопрос: зачем вообще ему эти объекты, и создаёт ли он их сам, если нет в другой схеме. На данный момент пользуюсь временным решением - нахожу подобные объекты в других схемах БД, проверяю, что нет таких в целой схеме, и создаю их. После пересобираю пакет - успех. Пример временно

SQL SERVER Broker Priority

Изображение
           Случалось ли вам работать с механизмом Service Broker или, то бишь с очередями. Механизм очень интересный, первый пришёл, почти первый ушёл. Почему "почти": если в процедуре активации указать receive top n и сообщения будут с одним идентификатором диалога, то из очереди выходят сообщения раньше своей очереди. Но идея статьи не в этом.            Между двумя промышленными системами идёт обмен с помощью интеграционного решения и механизма очередей на базах данных всех трёх систем. При пиковых нагрузках выходит, что сообщение, наиболее важное по нашему мнению, застревает в очереди из несколько тысяч наименее важных. Соответственно неприятные ожидания и недовольства от бизнеса. Так подошли к решению об использовании приоритетов.           Расскажу только об одной части этой замечательной схемы, об  приоритетах в очередях MS SQL Server, по шагам. Приоритеты у нас будут 1, 4 и 8.          Шаг 1. Создаем XML-схему нашего сообщения.                    CREATE XML SC

SQL SERVER. Поиск символа CHAR(39) во всех таблицах.

           При создании отчетов в программном обеспечении возникла проблема с символом CHAR(39) в тексте. Возникла задача найти все таблицы и колонки, которые  содержат этот символ. Скрипт поиска по всем таблицам был найден очень давно. Но его пришлось чуть доработать: добавить информацию по схемам и задать поиск именно одного апострофа в поле. SET NOCOUNT ON DECLARE @name VARCHAR (128), @column VARCHAR (128), @schema   VARCHAR (128), @sql VARCHAR ( MAX ) CREATE TABLE #rslt (table_name VARCHAR (128), field_name VARCHAR (128), value NTEXT ) DECLARE s CURSOR FAST_FORWARD FOR SELECT table_schema, table_name FROM information_schema.tables WHERE table_type = 'BASE TABLE' OPEN s FETCH NEXT FROM s INTO @schema, @name WHILE @@fetch_status = 0 BEGIN   DECLARE c CURSOR FAST_FORWARD FOR SELECT quotename (column_name) AS column_name FROM information_schema.columns   WHERE data_type IN ( 'TEXT' , 'NTEXT' , 'VARCHAR' , 'CHAR'

SQL SERVER. Error Database is in Transition

Изображение
При переводе состояния базы данных в SET OFFLINE происходит такая ошибка: "Database is in Transition"  и далее практически ничего сделать не даёт. Пришлось уже выходить из положения обходными способами. Находим database_id (у меня 32): USE [master] SELECT [database_id] FROM sys.databases  WHERE [name] = 'DB_TEST' В другой сессии пробуем  пробуем вывысти базу данных в состояние OFFLINE^ ALTER DATABASE [DB_TEST] SET OFFLINE WITH ROLLBACK IMMEDIATE В третьей сессии с помощью sp_lock находим сессии, которые относятся к базе данных [DB_TEST] : Выполняем KILL этих сессий  KILL 146 до тех пор пока во 2-й сессии получится вывести базу данных OFFLINE.

SQL Server. Проблема с разделителем дробной части числовых данных при запросе данных через Linked Server

Изображение
             На днях состоялся перенос базы данных с одного физического сервера на другой. Параметры нового сервера: Windows Server русская версия, SQL Server 2008 R2 English Edition, Oracle Client 11.2.0.4. При работе с данными обнаружился казус: данные типа NUMBER с СУБД Oracle через Linked Server запрашиваются корректно: Если же попытаться сделать INSERT в таблицу  MS SQL Server, то разделитель дробной части игнорируется: Исправляется подобное добавлением строкового параметра NLS_NUMERIC_CHARACTERS в ветку реестра со значением ".,":