Ошибка во время исполнения транзакции linux

Поломались зависимости в Fedora 30

Последний мой rpm-дистрибутив был OpenSUSE 11.3, где особых проблем с зависимостями не было. А на Fedora я даже не знаю куда копать.

Через терминал получаю вот такое:

Если обновлять через гномовский центр приложений, то получаю вот такое:

Не обновлялся пару месяцев – не до того было. Сижу на ядре 5.0.17, ибо на ядрах 5.1.X черный экран после загрузки. i686 пакеты основных библиотек были для чего-то нужны, я уже не помню зачем, но хотелось бы оставить, чтоб ничего не отломалось.

Сижу на ядре 5.0.17, ибо на ядрах 5.1.X черный экран после загрузки.

Каким образом это реализовано? В смысле: ты просто всегда выбираешь старое ядро при загрузке или что-то хитрое сделал (или пытался) в dnf?

Вообще попробуй так:

Каким образом это реализовано? В смысле: ты просто всегда выбираешь старое ядро при загрузке или что-то хитрое сделал (или пытался) в dnf?

При загрузке выбираю.

Ты случайно не прерывал dnf во время установки? killall -9 , выдёргиванием компа из розетки или другим подобным способом? Обычно после такого похожие проблемы появляются.

Вот такое должно всё починить (ну или частично починить):

Но если dnf в прошлый раз убился прямо во время установки какого-то пакета, то этот пакет сам по себе может быть поломан и его надо переустановить.

Вообще, выложи куда-нибудь содержимое /var/log/dnf.log и /var/log/dnf.rpm.log на момент последнего запуска перед тем как всё сломалось. Более старые логи содержат дату в имени файла.

Я предлагаю тупо удалить пакеты kernel-5.1.5 и kernel-modules-extra-5.1.5 разу уж это ядро все равно не работает. После этого все должно наладится

rpm –rebuilddb

Не происходит ничего.

Центр приложений при обновлении через него вообще на glibc ругается. Мне кажется, пакеты с ядром – только вершина айсберга и если удалить их, то всплывут проблемы со следующими пакетами.

Эээ… Я, честно говоря, даже не знал, что dnf remove может предлагать что-либо установить. Не знаю: это баг или задуманное поведение в случае сломанных зависимостей.

Могу предложить только руками это всё чинить. Удалять/устанавливать отдельные пакеты из списка после «Ошибка: проверка транзакции на разрешение зависимостей» утилитой rpm пока система не придёт в состояние, от которого dnf’у не будет сходу становиться плохо.

Ну или переустановить с нуля, если ничего не помогает и никто не предложит что-нибудь более умное.

Ты точно во время работы dnf не выключал компьютер ударом ногой с разворота? Или может у тебя ФС недавно сыпалась? Может при «на ядрах 5.1.X черный экран после загрузки» на самом деле происходило что-то более страшное, чем проблемы с экраном?

Когда у меня последний раз отрубилась система во время установки, пришлось занятся страшным трахом с участием rpm и rm — после которых уже и удалось починиться средствами dnf.

Когда у меня последний раз отрубилась система во время установки, пришлось занятся страшным трахом с участием rpm и rm — после которых уже и удалось починиться средствами dnf.

Тут видимо похожий случай. Логи dnf очевидно битые.

Пакеты i686 можешь удалять без проблем, надо будет, потом поставишь.
Про ядро, похоже на то, что оно уже установлено, но юзаешь другое, покажи список установленных ядер и текущее

Ну или переустановить с нуля, если ничего не помогает и никто не предложит что-нибудь более умное.

Похоже, так и сделаю. Может быть для интересу накачу Silverblue. Либо RHEL 8.

Ты точно во время работы dnf не выключал компьютер ударом ногой с разворота? Или может у тебя ФС недавно сыпалась? Может при «на ядрах 5.1.X черный экран после загрузки» на самом деле происходило что-то более страшное, чем проблемы с экраном?

Честно сказать, не помню, что я там делал, возможно остановил dnf через ^C.

Честно сказать, не помню, что я там делал, возможно остановил dnf через ^C.

Не, ни ctrl-c, ни даже kill -9 такое (нули) в логе дать не могли. Мне кажется, там посыпалось серьёзно, возможно с привлечением ядра и файловой системы.

Кстати, на всякий случай запусти на ночь memtest. Мало ли что…

Что то ядро старовато. Я сей момент не помню точно но то что kernek-5.1.11 у меня уже стоит это точно. Fedora 30.

Кстати, на всякий случай запусти на ночь memtest. Мало ли что…

Оперативка вряд ли виновата. Планкам год, память довольно медленная 2400 МГц, не разгонял ни разу. Самая большая вероятность – винт накрывается потихоньку. Дешёвый Toshiba на 2 Тб.

У меня не обновляется система уже несколько недель или месяц.

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

Ошибки при apt-get dist-upgrade

Ошибки при apt-get dist-upgrade

Сообщение M31 » 26.05.2006 08:04

что эот означает? что делать?

Re: Ошибки при apt-get dist-upgrade

Сообщение k0da » 26.05.2006 10:40

Re: Ошибки при apt-get dist-upgrade

Сообщение void_false » 26.05.2006 12:59

Re: Ошибки при apt-get dist-upgrade

Сообщение M31 » 26.05.2006 22:08

Re: Ошибки при apt-get dist-upgrade

Сообщение k0da » 26.05.2006 23:56

Re: Ошибки при apt-get dist-upgrade

Сообщение M31 » 27.05.2006 08:34

Re: Ошибки при apt-get dist-upgrade

Сообщение k0da » 27.05.2006 14:35

Re: Ошибки при apt-get dist-upgrade

Сообщение vidliks » 27.05.2006 15:32

Re: Ошибки при apt-get dist-upgrade

Сообщение M31 » 27.05.2006 16:32

Re: Ошибки при apt-get dist-upgrade

Сообщение k0da » 27.05.2006 16:52

Re: Ошибки при apt-get dist-upgrade

Сообщение M31 » 27.05.2006 17:19

Re: Ошибки при apt-get dist-upgrade

Сообщение vidliks » 28.05.2006 20:59

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

• Темы без ответов
• Активные темы
• Поиск
• Статус форума

неизвестная ошибка транзакции при обновлении (обновление в fedore)

неизвестная ошибка транзакции при обновлении

Сообщение t3r » 03.08.2011 20:39

Re: неизвестная ошибка транзакции при обновлении

Сообщение broom » 03.08.2011 23:17

Re: неизвестная ошибка транзакции при обновлении

Сообщение t3r » 04.08.2011 06:14

Re: неизвестная ошибка транзакции при обновлении

Сообщение broom » 04.08.2011 08:30

Re: неизвестная ошибка транзакции при обновлении

Сообщение Vascom » 04.08.2011 10:13

Re: неизвестная ошибка транзакции при обновлении

Сообщение t3r » 04.08.2011 10:44

обновляю через gui ,
Репозитории rawhide умышленно включены? нет только недавно систему поставил еще новичок
yum repolist

Re: неизвестная ошибка транзакции при обновлении

Сообщение Vascom » 04.08.2011 12:02

Re: неизвестная ошибка транзакции при обновлении

Сообщение t3r » 04.08.2011 12:04

все разобрался сделал сначала yum remove rpmfusion*release*
потом yum update

все обновил, я правильно сделал?

я его уже отключил до обновления так что вроде все нормально

Источник

Ошибка во время исполнения транзакции linux

Профессионал

Группа: Пользователь
Сообщений: 2049
Регистрация: 14.9.2009
Вставить ник
Цитата
Из: Ленинград
Пользователь №: 1594
Страна: Россия
Город: Санкт-Петербург
Пол: Муж.

Репутация: 9

Строго говоря пробую с 8-ого Альта перейти на 9-й. Пытаюсь по https://www.altlinux.org/Update/p9
В терминале всплывает
E: Произошли ошибки при выполнении транзакции

И обновление перестаёт быть.
Попробовал перезагрузиться и продолжить из Синаптика где уже встал http://ftp.altlinux.org/pub/distributions/ALTLinux/p9/branch/i586.
Итог тот же самый.

Во время подготовки к установке:

file /etc/ImageMagick-6/coder.xml from install of libImageMagick6-common-6.9.10.94-alt1 conflicts with file from package libImageMagick-6.9.4.7-alt2.M80P.1
********************многабукаф
libImageMagick-6.9.4.7-alt2.M80P.1
E: Error while running transaction

Чтение списков пакетов. Завершено
Построение дерева зависимостей. Завершено
Некоторые пакеты установить невозможно. Это может означать, что Вы
потребовали невозможного, либо пользуетесь нестабильным репозиторием.
Часть необходимых пакетов либо ещё не создана, либо была удалена
из каталога ‘Входящие’.
Эти сведения могут помочь найти выход из ситуации:

Следующие пакеты имеют неудовлетворенные зависимости:
kernel-modules-nvidia-std-def#440.82-alt1.328748.1:p9+252713.2200.2.1<>1591627333: Требует: nvidia_glx_390.132
shadow-utils: Требует: pam0(system-auth-use_first_pass-local)
tcb-utils: Для установки требует: pam0_tcb (= 1.1-alt1)
E: Извините, `битые’ пакеты
update-kernel: failed to install kernel-image-std-def-1:5.4.44-alt1:p9+252713.100.2.1<>1591626094 with modules
[root<>comp-pentium

И чего теперь делать.

Сообщение отредактировал robinzoid — 23.6.2020, 22:40

Источник

Транзакции в T-SQL – основы для новичков с примерами

Приветствую всех посетителей сайта Info-Comp.ru! В этом материале мы с Вами подробно рассмотрим транзакции языка T-SQL, Вы узнаете, что это такое, для чего они нужны, а также какие команды управления транзакциями существуют в T-SQL.

Заметка! T-SQL – это расширение языка SQL, реализованное в Microsoft SQL Server. Более подробно об этом можете почитать в статье – Что такое T-SQL. Подробное описание для начинающих.

Транзакции в T-SQL

Транзакция – это команда или блок команд (инструкций), которые успешно завершаются как единое целое, при этом в базе данных все внесенные изменения фиксируются на постоянной основе, или отменяются, т.е. все изменения, внесенные любой командой, входящей в транзакцию, будут отменены. Другими словами, если одна команда или инструкция внутри транзакции завершилась с ошибкой, то все, что было отработано перед ней, также отменяется, даже если предыдущие команды завершились успешно.

Транзакции очень полезны и просто незаменимы в тех случаях, когда Вам необходимо реализовывать бизнес логику в базе данных Microsoft SQL Server, которая предполагает многошаговые операции, где каждый шаг логически связан с другими шагами.

По сути каждая отдельная инструкция языка T-SQL является транзакцией, это называется «Автоматическое принятие транзакций» или «Неявные транзакции», но также есть и явные транзакции, это когда мы сами явно начинаем транзакцию и также явно заканчиваем ее, т.е. делаем все это с помощью специальных команд.

Чтобы понять, как работают транзакции и для чего они нужны, давайте рассмотрим классический пример, который наглядно показывает необходимость использования транзакций.

Допустим, у Вас есть хранимая процедура, которая осуществляет перевод средств с одного счета на другой, соответственно, как минимум у Вас будет две операции в этой процедуре, снятие средств, и зачисление средств, например, две инструкции UPDATE.

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

Чтобы этого не допустить, все SQL инструкции, которые логически что-то объединяет, в данном случае все операции, связанные с переводом средств, пишут внутри транзакции, и тогда, если наступит подобная ситуация, все изменения будут отменены, т.е. деньги вернутся обратно на счет.

Транзакции можно сочетать с обработкой и перехватом ошибок TRY…CATCH, иными словами, Вы отслеживаете ошибки в Вашем блоке инструкций и если они появляются, то в блоке CATCH Вы откатываете транзакцию, т.е. отменяете все изменения, которые были успешно выполнены до возникновения ошибки в транзакции.

Транзакции – это отличный механизм обеспечения целостности данных.

Свойства транзакции

У транзакции есть 4 очень важных свойства:

• Атомарность – все команды в транзакции либо полностью выполняются, и соответственно, фиксируются все изменения данных, либо ничего не выполняется и ничего не фиксируется;
• Согласованность – данные, в случае успешного выполнения транзакции, должны соблюдать все установленные правила в части различных ограничений, первичных и внешних ключей, определенных в базе данных;
• Изоляция – механизм предоставления доступа к данным. Транзакция изолирует данные, с которыми она работает, для того чтобы другие транзакции получали только согласованные данные;
• Надежность – все внесенные изменения фиксируются в журнале транзакций и данные считаются надежными, если транзакция была успешно завершена. В случае сбоя SQL Server сверяет данные, записанные в базе данных, с журналом транзакций, если есть успешно завершенные транзакции, которые не закончили процесс записи всех изменений в базу данных, они будут выполнены повторно. Все действия, выполненные не подтвержденными транзакциями, отменяются.

Команды управления транзакциями в T-SQL

В T-SQL для управления транзакциями существуют следующие основные команды:

• BEGIN TRANSACTION (можно использовать сокращённую запись BEGIN TRAN) – команда служит для определения начала транзакции. В качестве параметра этой команде можно передать и название транзакции, полезно, если у Вас есть вложенные транзакции;
• COMMIT TRANSACTION (можно использовать сокращённую запись COMMIT TRAN) – с помощью данной команды мы сообщаем SQL серверу об успешном завершении транзакции, и о том, что все изменения, которые были выполнены, необходимо сохранить на постоянной основе;
• ROLLBACK TRANSACTION (можно использовать сокращённую запись ROLLBACK TRAN) – служит для отмены всех изменений, которые были внесены в процессе выполнения транзакции, например, в случае ошибки, мы откатываем все назад;
• SAVE TRANSACTION (можно использовать сокращённую запись SAVE TRAN) – данная команда устанавливает промежуточную точку сохранения внутри транзакции, к которой можно откатиться, в случае возникновения необходимости.

Примеры транзакций в T-SQL

Давайте рассмотрим примеры транзакций, реализованные на языке T-SQL.

Исходные данные для примеров

Но сначала нам необходимо создать тестовые данные для нашего примера.

Для этого выполните следующую инструкцию.

Простой пример транзакции в T-SQL

В данном примере у нас всего две инструкции, которые изменяют данные, но допустим, что они взаимосвязаны, т.е. они обе обязательно должны выполниться вместе или не выполниться также вместе.

Поэтому мы решили эти инструкции объединить в одну транзакцию.

Сначала мы открываем транзакцию командой BEGIN TRANSACTION, далее пишем все необходимые инструкции, которые мы хотим объединить в транзакцию.

После этого командой COMMIT TRANSACTION мы сохраняем все внесенные изменения.

В данном случае у нас нет никаких ошибок, все инструкции выполнились успешно. Как результат, транзакция завершена также успешно и все изменения сохранены на постоянной основе командой COMMIT TRANSACTION.

Однако, если в любой из инструкций возникнет ошибка, транзакция не завершится, и все изменения не сохранятся.

При этом, стоит помнить о том, что ошибки с определённым уровнем серьезности, например, ошибки, связанные с нарушением ограничений, не влекут за собой автоматический откат всех изменений внесенных текущей транзакцией, поэтому всегда необходимо использовать или инструкцию SET XACT_ABORT ON, или обработку ошибок (допускается и совместное использование).

Например, если во второй инструкции мы попытаемся записать в столбец Price какое-нибудь текстовое значение, то у нас возникнет ошибка, и изменения, внесённые первой инструкцией, не зафиксируются на постоянной основе.

Пример транзакции в T-SQL с обработкой ошибок

В языке T-SQL существует механизм перехвата и обработки ошибок – конструкция TRY… CATCH.

Эту конструкцию можно использовать для отслеживания появления возможных ошибок внутри транзакции и в случае появления таких ошибок предпринять определенные действия.

Сначала мы открываем блок для обработки ошибок, затем открываем транзакцию командой BEGIN TRANSACTION, далее пишем наши инструкции, например, те же самые две инструкции UPDATE.

После этого закрываем блок TRY, открываем блок CATCH, в котором в случае возникновения ошибки мы откатываем все изменения командой ROLLBACK TRANSACTION. Также мы принудительно завершаем нашу инструкцию командой RETURN.

Если ошибок нет, то в блок CATCH мы, соответственно, не попадаем и у нас выполнится команда COMMIT TRANSACTION, которая сохранит все изменения.

В этом примере нет ошибок, поэтому транзакция завершена успешно.

А в этом примере мы намерено допускаем ошибку во второй инструкции. Поэтому управление передается в блок CATCH, где мы откатываем все изменения, возвращаем номер и описание ошибки и принудительно завершаем всю инструкцию командой RETURN.

Первая инструкция отработала нормально, но ее изменения не были сохранены, так как вторая инструкция выполнена с ошибкой.

Уровни изоляции транзакций в T-SQL

Во время выполнения транзакции все данные, над которыми производятся изменения, блокируются, до завершения транзакции, так как, когда один процесс изменяет данные, другой процесс не может одновременно изменять их. В SQL сервере существует механизм, который блокирует (изолирует) данные во время выполнения транзакции. У данного механизма есть несколько уровней изоляции, каждый из которых определяет степень блокировки данных.

Давайте подробней рассмотрим уровни изоляции.

READ UNCOMMITTED

Самый низкий уровень, при котором SQL сервер разрешает так называемое «грязное чтение». Грязным чтением называют считывание неподтвержденных данных, иными словами, если транзакция, которая изменяет данные, не завершена, другая транзакция может получить уже измененные данные, хотя они еще не зафиксированы и могут отмениться.

READ COMMITTED

Этот уровень уже запрещает грязное чтение, в данном случае все процессы, запросившие данные, которые изменяются в тот же момент в другой транзакции, будут ждать завершения этой транзакции и подтверждения фиксации данных. Данный уровень по умолчанию используется SQL сервером.

REPEATABLE READ

На данном уровне изоляции запрещается изменение данных между двумя операциями чтения в одной транзакции. Здесь происходит запрет на так называемое «неповторяющееся чтение» или «несогласованный анализ». Другими словами, если в одной транзакции есть несколько операций чтения, данные будут блокированы и их нельзя будет изменить в другой транзакции. Таким образом, Вы избежите ситуации, когда вначале транзакции Вы запросили данные, провели их анализ (некое вычисление), в конце транзакции запросили те же самые данные, а они уже отличаются от первоначальных, так как они были изменены другой транзакцией.

Также уровень REPEATABLE READ, как и остальные, запрещает «Потерянное обновление» – это когда две транзакции сначала считывают одни и те же данные, а затем изменяют их на основе неких вычислений, в результате обе транзакции выполнятся, но данные будут те, которая зафиксировала последняя операция обновления. Это происходит потому, что данные в операциях чтения в начале этих транзакций не были заблокированы.

SERIALIZABLE

Данный уровень исключает чтение «фантомных» записей. Фантомные записи – это те записи, которые появились между началом и завершением транзакции. Иными словами, в начале транзакции Вы запросили определенные данные, в конце транзакции Вы запрашиваете их снова с тем же фильтром, но там уже есть и новые данные, которые добавлены другой транзакцией. Более низкие уровни изоляции не блокировали строки, которых еще нет в таблице, данный уровень блокирует все строки, соответствующие фильтру запроса, с которыми будет работать транзакция, как существующие, так и те, что могут быть добавлены.

SNAPSHOT и READ COMMITTED SNAPSHOT

Также существуют уровни изоляции, алгоритм которых основан на версиях строк, это

• SNAPSHOT
• READ COMMITTED SNAPSHOT

Иными словами, SQL Server делает снимок и хранит последние версии подтвержденных строк. В данном случае, клиенту не нужно ждать снятия блокировок, пока одна транзакция изменит данные, он сразу получает последнюю версию подтвержденных строк. Следует отметить, что уровни изоляции, основанные на версиях строк, замедляют операции обновления и удаления, так как перед этими операциями сервер делает и копирует снимок строк во временную базу данных.

SNAPSHOT – уровень хранит строки, подтверждённые на момент начала транзакции, соответственно, именно эти строки будут считаны в случае обращения к ним из другой транзакции. Данный уровень исключает повторяющееся и фантомное чтение примерно так же, как уровень SERIALIZABLE.

READ COMMITTED SNAPSHOT – этот уровень изоляции работает практически так же, как уровень SNAPSHOT, с одним отличием, он хранит снимок строк, которые подтверждены на момент запуска команды, а не транзакции, как в SNAPSHOT.

Побочные эффекты параллелизма

На основе вышеизложенного мы можем выделить несколько побочных эффектов, которые могут возникнуть в результате параллельного использования данных:

• Потерянное обновление (LostUpdate) – при одновременном изменении данных разными транзакциями одно из изменений будет потеряно;
• Грязное чтение (DirtyRead) – чтение неподтвержденных данных;
• Неповторяющееся чтение (Non-Repeatable Read) – чтение измененных данных в рамках одной транзакции;
• Фантомное чтение (Phantom Reads) – чтение записей, которые появились между началом и завершением транзакции.

Каждый из уровней изоляции устраняет определенные побочные эффекты. В таблице ниже приведены сводные данные.

Побочный эффект / Уровень изоляции	Потерянное обновление	Грязное чтение	Неповторяющееся чтение	Фантомные записи
READ UNCOMMITTED	Устраняет	Не устраняет	Не устраняет	Не устраняет
READ COMMITTED	Устраняет	Устраняет	Не устраняет	Не устраняет
REPEATABLE READ	Устраняет	Устраняет	Устраняет	Не устраняет
SERIALIZABLE	Устраняет	Устраняет	Устраняет	Устраняет
SNAPSHOT	Устраняет	Устраняет	Устраняет	Устраняет
READ COMMITTED SNAPSHOT	Устраняет	Устраняет	Устраняет	Устраняет

Включение уровня изоляции в T-SQL

Для того чтобы включить тот или иной уровень изоляции для всей сессии, необходимо выполнить команду SET TRANSACTION ISOLATION LEVEL и указать название уровня изоляции.

Также для уровней SNAPSHOT и READ COMMITTED SNAPSHOT предварительно необходимо включить параметр базы данных ALLOW_SNAPSHOT_ISOLATION для уровня изоляции SNAPSHOT и READ_COMMITTED_SNAPSHOT для уровня READ COMMITTED SNAPSHOT.

Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней язык SQL рассматривается как стандарт, чтобы после прочтения данной книги можно было работать с языком SQL в любой системе управления базами данных.

На сегодня это все, надеюсь, материал был Вам полезен, до новых встреч!

Источник