Transaction log
http://dbpedia.org/resource/Transaction_log an entity of type: WikicatComputerFileSystems
트랜잭션 로그(transaction log) 또는 데이터베이스 로그(database log, 바이너리 로그라고도 함)는 데이터베이스에서 충돌이나 하드웨어 고장이 있었다고 해도 데이터베이스 관리 시스템의 ACID 특성을 보장하기 위한 조작 이력을 가리킨다. 로그는 전원이 끊겨도 데이터를 저장할 수 있는 보조 기억 장치에 파일에 출력되는 경우가 많다. 데이터베이스를 시작한 후 일관성 없는 상태이거나 제대로 종료되지 않은 것을 감지하면, 데이터베이스 관리 시스템은 트랜잭션 로그를 읽고 다음과 같이 실시한다. 데이터 무결성과 지속성을 보장하기 위해 필요하다.
* 완료하지 않은 또는 롤백된 트랜잭션이 수행한 작업을 취소한다.
* 커밋하고 있지만 데이터베이스에 반영되지 않은 작업을 다시 수행한다.
* 트랜잭션 로그의 목표는 데이터 로그와는 다르다. 일반적으로 데이터 로그는 조작 이력을 쉽게 읽을 수 있는(human-readable) 표현으로 기록하기 위해 사용된다. 따라서 데이터베이스 관리 시스템은 트랜잭션 로그 및 데이터 로그를 모두 제공하는 경우가 일반적이다.
rdf:langString
計算機科学のデータベースの分野において、トランザクションログ（英: transaction log）（または データベースログ, バイナリログ とも呼ばれる）とは、クラッシュやハードウェア故障があったとしてもデータベース管理システムのACID特性を保障するための操作履歴を指す。ログは電源が途絶えてもデータを保持できる補助記憶装置上のファイルに出力される場合が多い。 データベースが起動後に、整合性の無い状態であるか、正常に終了されていないことを検知すると、データベース管理システムはトランザクションログを読み取り、以下の操作を行う。どちらも原子性と永続性を保障するために必要である。
* 完了していない または ロールバックされたトランザクションが行った操作を取り消す。
* コミットしているが、データベースには反映されていない操作を再実行する。 トランザクションログの目的は、データログとは異なる。一般にデータログは操作履歴を人間が読みやすい (human-readable) 表現で記録するために用いられる。そのため、データベース管理システムによってはトランザクションログとデータログの両方を提供している場合も多い。
rdf:langString
سجل الإجراءات (بالإنجليزية: Transaction Log) يمكن لمواقع التجارة الإلكترونية أن تعلم أكثر من قسم المخزون عن رغبات المستهلكين، إن المصدر الأساسي لمعلومات المستهلكين على الشبكة هو ملف سجل العمليات (الأوامر) الذي يحفظ على خوادم الشبكة.إن سجل العمليات (الأوامر) يقوم بتسجيل نشاطات المستخدم على الشبكة. هذا السجل يتم بناؤه ضمن برامج خادم الشبكة. كما أنه يتميز بأنه يقوم بمسح الاسم الحقيقي للمستخدم ويقوم بإظهار بعض المعلومات عن هذا المستخدم ونشاطاته على الموقع وأكثر مايجذب المستهلك وذلك لتساعده على تكوين قوائم بناء على المعلومات المقدمة من قبل المستخدم.أيضا ماذا عن الشركات بمختلف أنواعها كيف تقوم بحفظ بياناتها الخاصة بموظفيها، عملائها، أو أي من نشاطاتها. وكيف يتم استرجاع هذه المعلومات والمحافظة عليها. كيف يتم التأكد من سلامة المعلومات وأن أي تعديل أو تغييرقد تم بالشكل الصحيح؟ كيف يتم التعامل في حا
rdf:langString
Logging und Recovery bezeichnet in der Informatik eine Sammlung von Maßnahmen und Techniken, um bei Datenbanksystemen (DBS) nach einem Fehlerfall (z. B. nach einem Systemabsturz oder einem Ausfall von Festplatten) den Datenverlust zu verhindern und die Fehlerfreiheit (Konsistenz) der Datenbank weiterhin zu garantieren. Mögliche Fehlerarten sind: Transaktionsfehler (z. B. Abbruch einer laufenden Transaktion wegen Sperrung durch eine andere Transaktion), Systemfehler (z. B. Rechnerausfall), Geräte- bzw. Externspeicherfehler (z. B. Festplattenausfall durch einen Headcrash) oder die sogenannte Katastrophe (z. B. dem vollständigen Verlust des Rechenzentrums nach einem Erdbeben).
rdf:langString
En informatique, le journal des transactions (en anglais, transaction log, transaction journal, database log, binary log ou audit trail) est la liste des transactions informatiques exécutées sur une base de données. Cette liste de transactions est utilisée pour rétablir l'intégrité de la base de données dans les cas de problèmes logiciels ou matériels du système qui gère la base de données.
rdf:langString
In the field of databases in computer science, a transaction log (also transaction journal, database log, binary log or audit trail) is a history of actions executed by a database management system used to guarantee ACID properties over crashes or hardware failures. Physically, a log is a file listing changes to the database, stored in a stable storage format. This term is not to be confused with other, human-readable logs that a database management system usually provides. In database management systems, a journal is the record of data altered by a given process.
rdf:langString
Журнализация изменений — функция СУБД, которая сохраняет информацию, необходимую для восстановления базы данных в предыдущее согласованное состояние в случае логических или физических отказов. В простейшем случае журнализация изменений заключается в последовательной записи во внешнюю память всех изменений, выполняемых в базе данных. Записывается следующая информация: Формируемая таким образом информация называется журнал изменений базы данных. Журнал содержит отметки начала и завершения транзакции, и отметки принятия контрольной точки (см. ниже).
rdf:langString
Журналізація змін — функція СКБД, яка зберігає інформацію, необхідну для відновлення бази даних в попередній узгоджений стан в разі збою в роботі СКБД (програмного чи апаратного), а також для забезпечення можливості скасування транзакцій. У найпростішому випадку журналювання змін полягає в послідовному записі у зовнішню пам'ять всіх змін, які виконуються в базі даних. Записується наступна інформація: Формована таким чином інформація називається журнал змін бази даних. Журнал містить позначки початку і завершення транзакції, і позначки прийняття Контрольні точки програми (див. Нижче).
rdf:langString
rdf:langString
سجل الإجراءات
rdf:langString
Logging und Recovery
rdf:langString
Log (registro)
rdf:langString
Journal des transactions
rdf:langString
トランザクションログ
rdf:langString
트랜잭션 로그
rdf:langString
Transaction log
rdf:langString
Журнализация транзакций
rdf:langString
Журнал транзакцій
xsd:integer
245974
xsd:integer
1098930416
rdf:langString
سجل الإجراءات (بالإنجليزية: Transaction Log) يمكن لمواقع التجارة الإلكترونية أن تعلم أكثر من قسم المخزون عن رغبات المستهلكين، إن المصدر الأساسي لمعلومات المستهلكين على الشبكة هو ملف سجل العمليات (الأوامر) الذي يحفظ على خوادم الشبكة.إن سجل العمليات (الأوامر) يقوم بتسجيل نشاطات المستخدم على الشبكة. هذا السجل يتم بناؤه ضمن برامج خادم الشبكة. كما أنه يتميز بأنه يقوم بمسح الاسم الحقيقي للمستخدم ويقوم بإظهار بعض المعلومات عن هذا المستخدم ونشاطاته على الموقع وأكثر مايجذب المستهلك وذلك لتساعده على تكوين قوائم بناء على المعلومات المقدمة من قبل المستخدم.أيضا ماذا عن الشركات بمختلف أنواعها كيف تقوم بحفظ بياناتها الخاصة بموظفيها، عملائها، أو أي من نشاطاتها. وكيف يتم استرجاع هذه المعلومات والمحافظة عليها. كيف يتم التأكد من سلامة المعلومات وأن أي تعديل أو تغييرقد تم بالشكل الصحيح؟ كيف يتم التعامل في حالة حدوث تسجيل خاطيء أو فقدان المعلومات بسبب فشل النظام أو أي حدث طارئ؟ من يقوم بتنظيم كل هذه الأوامر والمحافظة عليها وتوفير إمكانية استعادة نسخ إحطياطية منها؟ للإجابة عن هذه التساؤلات وغيرها يجب علينا أن نتطرق إلى برامج تسجيل العمليات وخصائصها وأهم مميزاتها وعلى ماذا تعتمد في تسجيل البيانات وجدولتها والحفاظ عليها. في مجال قواعد البيانات التابع لعلوم الحاسب. «سجل الإجراءات» وأيضا يسمى «سجل قواعد البيانات أو سجل الشفرة الثنائية»هو عبارة عن تاريخ العمليات التي حدثت بواسطة نظام إدارة قواعد البيانات لكي يضمن خصائص الـ AICD والتي تشمل:
rdf:langString
Logging und Recovery bezeichnet in der Informatik eine Sammlung von Maßnahmen und Techniken, um bei Datenbanksystemen (DBS) nach einem Fehlerfall (z. B. nach einem Systemabsturz oder einem Ausfall von Festplatten) den Datenverlust zu verhindern und die Fehlerfreiheit (Konsistenz) der Datenbank weiterhin zu garantieren. Mögliche Fehlerarten sind: Transaktionsfehler (z. B. Abbruch einer laufenden Transaktion wegen Sperrung durch eine andere Transaktion), Systemfehler (z. B. Rechnerausfall), Geräte- bzw. Externspeicherfehler (z. B. Festplattenausfall durch einen Headcrash) oder die sogenannte Katastrophe (z. B. dem vollständigen Verlust des Rechenzentrums nach einem Erdbeben). Das Transaktionsprotokoll schreibt im laufenden Betrieb alle Änderungen auf der Datenbank mit und das Recovery stellt nach dem Fehlerfall (z. B. nach dem Reboot sofern ein Systemabsturz für den Fehler verantwortlich war) den letzten aktuellen (Verhinderung von Datenverlust) und fehlerfreien (konsistenten) Zustand der Datenbank wieder her. Das Logging und Recovery ist somit verantwortlich für die Einhaltung der Konsistenz, Dauerhaftigkeit und Atomizität in einer Datenbank, drei der ACID-Eigenschaften. Die Systemkomponenten, die für Logging und Recovery benötigt werden sind temporäre Logdateien (zur Sicherung des Log-Puffers eines DBS bzw. DBVS), das Archivlog (zur Sicherung des DB-Puffers eines DBS bzw. DBVS), und die Archivkopie der Datenbank (zur Sicherung der Datenbank eines DBS).
rdf:langString
En informatique, le journal des transactions (en anglais, transaction log, transaction journal, database log, binary log ou audit trail) est la liste des transactions informatiques exécutées sur une base de données. Cette liste de transactions est utilisée pour rétablir l'intégrité de la base de données dans les cas de problèmes logiciels ou matériels du système qui gère la base de données. Physiquement, le journal des transactions est un fichier contenant une copie des modifications apportées à la base de données. Ce fichier est conservé sur un support non volatil pour être accessible même dans un cas de mauvais fonctionnement de l'ordinateur qui le gère. Lors du démarrage d'une base de données, le système de gestion de la base de données s'assure que la base de données a été fermée correctement et que la base de données est dans un état cohérent. Si ce n'est pas le cas, le système de gestion de la banque de données utilise le journal des transactions pour faire un retour en arrière (rollback) sur les transactions qui ne sont pas validées (committed). De plus, toujours en utilisant le journal des transactions, il réapplique les transactions validées dont les changements n'apparaissent pas dans la base de données. Ces corrections sont faites pour assurer l'atomicité et la durabilité des transactions.
rdf:langString
In the field of databases in computer science, a transaction log (also transaction journal, database log, binary log or audit trail) is a history of actions executed by a database management system used to guarantee ACID properties over crashes or hardware failures. Physically, a log is a file listing changes to the database, stored in a stable storage format. If, after a start, the database is found in an inconsistent state or not been shut down properly, the database management system reviews the database logs for uncommitted transactions and rolls back the changes made by these transactions. Additionally, all transactions that are already committed but whose changes were not yet materialized in the database are re-applied. Both are done to ensure atomicity and durability of transactions. This term is not to be confused with other, human-readable logs that a database management system usually provides. In database management systems, a journal is the record of data altered by a given process.
rdf:langString
트랜잭션 로그(transaction log) 또는 데이터베이스 로그(database log, 바이너리 로그라고도 함)는 데이터베이스에서 충돌이나 하드웨어 고장이 있었다고 해도 데이터베이스 관리 시스템의 ACID 특성을 보장하기 위한 조작 이력을 가리킨다. 로그는 전원이 끊겨도 데이터를 저장할 수 있는 보조 기억 장치에 파일에 출력되는 경우가 많다. 데이터베이스를 시작한 후 일관성 없는 상태이거나 제대로 종료되지 않은 것을 감지하면, 데이터베이스 관리 시스템은 트랜잭션 로그를 읽고 다음과 같이 실시한다. 데이터 무결성과 지속성을 보장하기 위해 필요하다.
* 완료하지 않은 또는 롤백된 트랜잭션이 수행한 작업을 취소한다.
* 커밋하고 있지만 데이터베이스에 반영되지 않은 작업을 다시 수행한다.
* 트랜잭션 로그의 목표는 데이터 로그와는 다르다. 일반적으로 데이터 로그는 조작 이력을 쉽게 읽을 수 있는(human-readable) 표현으로 기록하기 위해 사용된다. 따라서 데이터베이스 관리 시스템은 트랜잭션 로그 및 데이터 로그를 모두 제공하는 경우가 일반적이다.
rdf:langString
計算機科学のデータベースの分野において、トランザクションログ（英: transaction log）（または データベースログ, バイナリログ とも呼ばれる）とは、クラッシュやハードウェア故障があったとしてもデータベース管理システムのACID特性を保障するための操作履歴を指す。ログは電源が途絶えてもデータを保持できる補助記憶装置上のファイルに出力される場合が多い。 データベースが起動後に、整合性の無い状態であるか、正常に終了されていないことを検知すると、データベース管理システムはトランザクションログを読み取り、以下の操作を行う。どちらも原子性と永続性を保障するために必要である。
* 完了していない または ロールバックされたトランザクションが行った操作を取り消す。
* コミットしているが、データベースには反映されていない操作を再実行する。 トランザクションログの目的は、データログとは異なる。一般にデータログは操作履歴を人間が読みやすい (human-readable) 表現で記録するために用いられる。そのため、データベース管理システムによってはトランザクションログとデータログの両方を提供している場合も多い。
rdf:langString
Журнализация изменений — функция СУБД, которая сохраняет информацию, необходимую для восстановления базы данных в предыдущее согласованное состояние в случае логических или физических отказов. В простейшем случае журнализация изменений заключается в последовательной записи во внешнюю память всех изменений, выполняемых в базе данных. Записывается следующая информация:
* порядковый номер, тип и время изменения;
* идентификатор транзакции;
* объект, подвергшийся изменению (номер хранимого файла и номер блока данных в нём, номер строки внутри блока);
* предыдущее состояние объекта и новое состояние объекта. Формируемая таким образом информация называется журнал изменений базы данных. Журнал содержит отметки начала и завершения транзакции, и отметки принятия контрольной точки (см. ниже). В СУБД с отложенной записью блоки данных внешней памяти снабжаются отметкой порядкового номера последнего изменения, которое было выполнено над этим блоком данных. В случае сбоя системы эта отметка позволяет узнать какая версия блока данных успела достичь внешней памяти. СУБД с отложенной записью периодически выполняет контрольные точки. Во время выполнения этого процесса все незаписанные данные переносятся на внешнюю память, а в журнал пишется отметка принятия контрольной точки. После этого содержимое журнала, записанное до контрольной точки может быть удалено. Журнал изменений может не записываться непосредственно во внешнюю память, а аккумулироваться в оперативной. В случае подтверждения транзакции СУБД дожидается записи оставшейся части журнала на внешнюю память. Таким образом гарантируется, что все данные, внесённые после сигнала подтверждения, будут перенесены во внешнюю память, не дожидаясь переписи всех изменённых блоков из . СУБД дожидается записи оставшейся части журнала так же при выполнении контрольной точки. В случае логического отказа или сигнала отката одной транзакции журнал сканируется в обратном направлении, и все записи отменяемой транзакции извлекаются из журнала вплоть до отметки начала транзакции. Согласно извлеченной информации выполняются действия, отменяющие действия транзакции, а в журнал записываются компенсирующие записи. Этот процесс называется откат (rollback). В случае физического отказа, если ни журнал, ни сама база данных не повреждена, то выполняется процесс прогонки (rollforward). Журнал сканируется в прямом направлении, начиная от предыдущей контрольной точки. Все записи извлекаются из журнала вплоть до конца журнала. Извлеченная из журнала информация вносится в блоки данных внешней памяти, у которых отметка номера изменений меньше, чем записанная в журнале. Если в процессе прогонки снова возникает сбой, то сканирование журнала вновь начнется сначала, но фактически восстановление продолжится с той точки, откуда оно прервалось.
rdf:langString
Журналізація змін — функція СКБД, яка зберігає інформацію, необхідну для відновлення бази даних в попередній узгоджений стан в разі збою в роботі СКБД (програмного чи апаратного), а також для забезпечення можливості скасування транзакцій. У найпростішому випадку журналювання змін полягає в послідовному записі у зовнішню пам'ять всіх змін, які виконуються в базі даних. Записується наступна інформація:
* Порядковий номер, тип і час зміни;
* Ідентифікатор транзакції;
* Об'єкт, що піддався зміні (номер зберігається файлу і номер блоку даних в ньому, номер рядка всередині блоку);
* Попередній стан об'єкта і новий стан об'єкта. Формована таким чином інформація називається журнал змін бази даних. Журнал містить позначки початку і завершення транзакції, і позначки прийняття Контрольні точки програми (див. Нижче). В блоки даних зовнішньої пам'яті забезпечуються позначкою порядкового номера останньої зміни, яке було виконано над цим блоком даних. У разі збою системи ця позначка дозволяє дізнатися яка версія блоку даних встигла досягти зовнішньої пам'яті. СУБД з відкладеним записом періодично виконує контрольні точки. Під час виконання цього процесу всі незаписані дані переносяться на зовнішню пам'ять, а в журнал пишеться відмітка прийняття контрольної точки. Після цього вміст журналу, записаний до контрольної точки може бути видалено. Журнал змін може не записуватися безпосередньо в зовнішню пам'ять, а акумулюватися в оперативній. У разі підтвердження транзакції СКБД очікує запису решти журналу на зовнішню пам'ять. Таким чином гарантується, що всі дані, внесені після сигналу підтвердження, будуть перенесені на зовнішній пам'ять, не чекаючи перепису всіх змінених блоків з . СКБД очікує запису решти журналу також і при виконанні контрольної точки. 'В разі логічної відмови' або сигналу відкату однієї журнал сканується в зворотному напрямку, і всі записи скасовуваної транзакції витягуються з журналу аж до позначки початку транзакції. Згідно витягнутої інформації виконуються дії, що скасовують дії транзакції, а в журнал записуються компенсувальні записи. Цей процес називається 'відкат' (rollback). 'В разі фізичного відмови' , якщо ні журнал, ні сама база даних не пошкоджена, то виконується процес прогону (англ. rollforward). Журнал сканується в прямому напрямку, починаючи від попередньої контрольної точки. Всі записи витягуються з журналу аж до кінця журналу. Витягнута з журналу інформація вноситься в блоки даних в зовнішній пам'яті, у яких позначка номера змін менше, ніж записана в журналі. Якщо в процесі прогону знову виникає збій, то сканування журналу знову почнеться спочатку, але фактично відновлення продовжиться з того моменту, звідки воно перервалося. Після успішного завершення прогону здебільшого виконується контрольна точка.
xsd:nonNegativeInteger
5756