transaction log in RAM or physical file?SQL Server - how transactions and transaction log work (simplified)How do I shrink the physical Transaction Log file when it's the principal in a mirror?Two Different Sources Taking Transaction Log BackupsCHECKPOINT or COMMIT writes to disk?What is the best storing device for DB transaction log?Is it possible to restore SQL Server DB from transaction log (no MDF)?Do SQL Server Transaction Logs get 'locked' when there is a non-zero log_reuse_wait?Transaction log records in sql serverLog file shrinking automatically due to UserShrinkSize property?MySQL: why undo log is required in the processes of database recovery?
Does a windmilling propeller create more drag than a stopped propeller in an engine out scenario?
What to call a small, open stone or cement reservoir that supplies fresh water from a spring or other natural source?
What city and town structures are important in a low fantasy medieval world?
How could the B-29 bomber back up under its own power?
How to play vs. 1.e4 e5 2.Nf3 Nc6 3.Bc4 d6?
Farthing / Riding
How would a physicist explain this starship engine?
Is my company merging branches wrong?
Why is this python script running in background consuming 100 % CPU?
1950s or earlier book with electrical currents living on Pluto
Why was Houston selected as the location for the Manned Spacecraft Center?
Way of refund if scammed?
Do dirty bird feeders make birds sick?
How can I prevent Bash expansion from passing files starting with "-" as argument?
What should I wear to go and sign an employment contract?
Hotel booking: Why is Agoda much cheaper than booking.com?
How do you cope with rejection?
Vehemently against code formatting
What is metrics.roc_curve and metrics.auc measuring when I'm comparing binary data with probability estimates?
Expand a hexagon
pwaS eht tirsf dna tasl setterl fo hace dorw
Eigenvalues of the Laplace-Beltrami operator on a compact Riemannnian manifold
Separate the element after every 2nd ',' and push into next row in bash
Presenting 2 results for one variable using a left brace
transaction log in RAM or physical file?
SQL Server - how transactions and transaction log work (simplified)How do I shrink the physical Transaction Log file when it's the principal in a mirror?Two Different Sources Taking Transaction Log BackupsCHECKPOINT or COMMIT writes to disk?What is the best storing device for DB transaction log?Is it possible to restore SQL Server DB from transaction log (no MDF)?Do SQL Server Transaction Logs get 'locked' when there is a non-zero log_reuse_wait?Transaction log records in sql serverLog file shrinking automatically due to UserShrinkSize property?MySQL: why undo log is required in the processes of database recovery?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I'm a beginner in transaction, just a question on transaction log.
We know that when we commit a transaction, the changes are written to the transaction log, but is transaction log in RAM or physical files? If it is in RAM and when system failure happens, obviously the RAM will be re-erased so we lose the transaction information, so how can we recover the commit?
sql-server transaction-log transaction
asked May 14 at 0:45
slowjamsslowjams
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I'm a beginner in transaction, just a question on transaction log.
We know that when we commit a transaction, the changes are written to the transaction log, but is transaction log in RAM or physical files? If it is in RAM and when system failure happens, obviously the RAM will be re-erased so we lose the transaction information, so how can we recover the commit?
sql-server transaction-log transaction
asked May 14 at 0:45
slowjamsslowjams
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I'm a beginner in transaction, just a question on transaction log.
We know that when we commit a transaction, the changes are written to the transaction log, but is transaction log in RAM or physical files? If it is in RAM and when system failure happens, obviously the RAM will be re-erased so we lose the transaction information, so how can we recover the commit?
sql-server transaction-log transaction
asked May 14 at 0:45
slowjamsslowjams
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I'm a beginner in transaction, just a question on transaction log.
We know that when we commit a transaction, the changes are written to the transaction log, but is transaction log in RAM or physical files? If it is in RAM and when system failure happens, obviously the RAM will be re-erased so we lose the transaction information, so how can we recover the commit?
sql-server transaction-log transaction
sql-server transaction-log transaction
asked May 14 at 0:45
slowjamsslowjams
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked May 14 at 0:45
slowjamsslowjams
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked May 14 at 0:45
slowjamsslowjams
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked May 14 at 0:45
slowjamsslowjams
411
asked May 14 at 0:45
slowjamsslowjams
411
411
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
slowjams is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
You can find a pretty comprehensive guide to this question here, but to summarise, SQL Server will not return control to the application that committed a transaction until that transaction has been hardened to disk. Specifically, once it has been hardened to the transaction log file, control can be returned.
The data, at this point, may not be hardened into the data file, it may still be in the data buffer cache, but because it has been hardened into the transaction log then database recovery, in the event of a failure, can recover this transaction and persist the changes safely.
There is a log buffer cache in memory used to reduce the performance impacts of the sequential writes to transaction logs. The buffer is flushed to disk on several conditions, but one of them is a transaction commit. Until this data has been hardened, control is not returned to the caller, so even if you have a failure during this buffer flush the transactional consistency is maintained because this transaction is not yet considered committed. You will lose the data changes in that transaction, but as it was not committed, your application would already consider those changes lost as the commit was never completed.
answered May 14 at 3:32
HandyDHandyD
2,1681218
2
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
add a comment |
A database is made up two files, a data file and a transaction log file. These are stored on disk.
Each database has a log cache in RAM, when a transaction is committed it gets moved to the log cache waiting to be flushed to disk. Therefore temporarily when a transform has been committed and waiting to be flushed to disk, it is in memory, however ultimately it is stored on disk in the file, not RAM.
I am oversimplifying here, I suggest you read up on transaction logs, I recommend one of Paul Randals lectures here
https://youtu.be/LvlFgxZZOj4
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
1
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
3
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
add a comment |
As written from the other people the transaction log will always be written to the disk, before a COMMIT returns control to your application. For this reason the log file should be always placed on a fast SSD.
But for the sake of completeness:
With at least Windows Server 2016 plus SQL Server 2016 you could add NVDIMMs (non-volatile DIMM = Flash or battery backed RAM) to your server. In this case SQL Server would use this NVDIMMs to place the "hot" transaction log tail on the NVDIMMs, since they survive a power-off-event per definition.
This would increase the speed of writes drastically (since RAM is much faster than even a SSD), but you will only mention it on a database with many small writes / commits (e.g. the database behind a busy online shop or an online game with many concurrent players).
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
1
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "182"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
slowjams is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f238070%2ftransaction-log-in-ram-or-physical-file%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can find a pretty comprehensive guide to this question here, but to summarise, SQL Server will not return control to the application that committed a transaction until that transaction has been hardened to disk. Specifically, once it has been hardened to the transaction log file, control can be returned.
The data, at this point, may not be hardened into the data file, it may still be in the data buffer cache, but because it has been hardened into the transaction log then database recovery, in the event of a failure, can recover this transaction and persist the changes safely.
There is a log buffer cache in memory used to reduce the performance impacts of the sequential writes to transaction logs. The buffer is flushed to disk on several conditions, but one of them is a transaction commit. Until this data has been hardened, control is not returned to the caller, so even if you have a failure during this buffer flush the transactional consistency is maintained because this transaction is not yet considered committed. You will lose the data changes in that transaction, but as it was not committed, your application would already consider those changes lost as the commit was never completed.
answered May 14 at 3:32
HandyDHandyD
2,1681218
2
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
add a comment |
You can find a pretty comprehensive guide to this question here, but to summarise, SQL Server will not return control to the application that committed a transaction until that transaction has been hardened to disk. Specifically, once it has been hardened to the transaction log file, control can be returned.
The data, at this point, may not be hardened into the data file, it may still be in the data buffer cache, but because it has been hardened into the transaction log then database recovery, in the event of a failure, can recover this transaction and persist the changes safely.
There is a log buffer cache in memory used to reduce the performance impacts of the sequential writes to transaction logs. The buffer is flushed to disk on several conditions, but one of them is a transaction commit. Until this data has been hardened, control is not returned to the caller, so even if you have a failure during this buffer flush the transactional consistency is maintained because this transaction is not yet considered committed. You will lose the data changes in that transaction, but as it was not committed, your application would already consider those changes lost as the commit was never completed.
answered May 14 at 3:32
HandyDHandyD
2,1681218
2
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
add a comment |
You can find a pretty comprehensive guide to this question here, but to summarise, SQL Server will not return control to the application that committed a transaction until that transaction has been hardened to disk. Specifically, once it has been hardened to the transaction log file, control can be returned.
The data, at this point, may not be hardened into the data file, it may still be in the data buffer cache, but because it has been hardened into the transaction log then database recovery, in the event of a failure, can recover this transaction and persist the changes safely.
There is a log buffer cache in memory used to reduce the performance impacts of the sequential writes to transaction logs. The buffer is flushed to disk on several conditions, but one of them is a transaction commit. Until this data has been hardened, control is not returned to the caller, so even if you have a failure during this buffer flush the transactional consistency is maintained because this transaction is not yet considered committed. You will lose the data changes in that transaction, but as it was not committed, your application would already consider those changes lost as the commit was never completed.
answered May 14 at 3:32
HandyDHandyD
2,1681218
You can find a pretty comprehensive guide to this question here, but to summarise, SQL Server will not return control to the application that committed a transaction until that transaction has been hardened to disk. Specifically, once it has been hardened to the transaction log file, control can be returned.
The data, at this point, may not be hardened into the data file, it may still be in the data buffer cache, but because it has been hardened into the transaction log then database recovery, in the event of a failure, can recover this transaction and persist the changes safely.
There is a log buffer cache in memory used to reduce the performance impacts of the sequential writes to transaction logs. The buffer is flushed to disk on several conditions, but one of them is a transaction commit. Until this data has been hardened, control is not returned to the caller, so even if you have a failure during this buffer flush the transactional consistency is maintained because this transaction is not yet considered committed. You will lose the data changes in that transaction, but as it was not committed, your application would already consider those changes lost as the commit was never completed.
answered May 14 at 3:32
HandyDHandyD
2,1681218
answered May 14 at 3:32
HandyDHandyD
2,1681218
answered May 14 at 3:32
HandyDHandyD
2,1681218
answered May 14 at 3:32
HandyDHandyD
2,1681218
2,1681218
2
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
add a comment |
2
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
2
2
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
Documented here: docs.microsoft.com/en-us/sql/relational-databases/…
– David Browne - Microsoft
May 14 at 16:10
add a comment |
A database is made up two files, a data file and a transaction log file. These are stored on disk.
Each database has a log cache in RAM, when a transaction is committed it gets moved to the log cache waiting to be flushed to disk. Therefore temporarily when a transform has been committed and waiting to be flushed to disk, it is in memory, however ultimately it is stored on disk in the file, not RAM.
I am oversimplifying here, I suggest you read up on transaction logs, I recommend one of Paul Randals lectures here
https://youtu.be/LvlFgxZZOj4
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
1
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
3
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
add a comment |
A database is made up two files, a data file and a transaction log file. These are stored on disk.
Each database has a log cache in RAM, when a transaction is committed it gets moved to the log cache waiting to be flushed to disk. Therefore temporarily when a transform has been committed and waiting to be flushed to disk, it is in memory, however ultimately it is stored on disk in the file, not RAM.
I am oversimplifying here, I suggest you read up on transaction logs, I recommend one of Paul Randals lectures here
https://youtu.be/LvlFgxZZOj4
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
1
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
3
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
add a comment |
A database is made up two files, a data file and a transaction log file. These are stored on disk.
Each database has a log cache in RAM, when a transaction is committed it gets moved to the log cache waiting to be flushed to disk. Therefore temporarily when a transform has been committed and waiting to be flushed to disk, it is in memory, however ultimately it is stored on disk in the file, not RAM.
I am oversimplifying here, I suggest you read up on transaction logs, I recommend one of Paul Randals lectures here
https://youtu.be/LvlFgxZZOj4
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
A database is made up two files, a data file and a transaction log file. These are stored on disk.
Each database has a log cache in RAM, when a transaction is committed it gets moved to the log cache waiting to be flushed to disk. Therefore temporarily when a transform has been committed and waiting to be flushed to disk, it is in memory, however ultimately it is stored on disk in the file, not RAM.
I am oversimplifying here, I suggest you read up on transaction logs, I recommend one of Paul Randals lectures here
https://youtu.be/LvlFgxZZOj4
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
answered May 14 at 1:26
kevinnwhatkevinnwhat
30717
30717
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
1
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
3
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
add a comment |
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
1
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
3
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
@kevinwhat Thanks for your answer. So if we commit one transaction and it is updated in the log cache then the system fails before the log cache flushes to disk, so how can we recovery the transaction?
– slowjams
May 14 at 1:37
1
1
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
@slowjams in that case the changes the transaction made would be rolled back, as it wasn't stable on disk in the log at the time when the crash occurred.
– Sean Gallardy
May 14 at 1:45
3
3
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
slowjamsm what you desrcibe doesn't happen. The commit is synchronous - it doesn't finish until all log record up until that point in time has been written to disk ("hardened").
– Tibor Karaszi
May 14 at 6:51
add a comment |
As written from the other people the transaction log will always be written to the disk, before a COMMIT returns control to your application. For this reason the log file should be always placed on a fast SSD.
But for the sake of completeness:
With at least Windows Server 2016 plus SQL Server 2016 you could add NVDIMMs (non-volatile DIMM = Flash or battery backed RAM) to your server. In this case SQL Server would use this NVDIMMs to place the "hot" transaction log tail on the NVDIMMs, since they survive a power-off-event per definition.
This would increase the speed of writes drastically (since RAM is much faster than even a SSD), but you will only mention it on a database with many small writes / commits (e.g. the database behind a busy online shop or an online game with many concurrent players).
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
1
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
add a comment |
As written from the other people the transaction log will always be written to the disk, before a COMMIT returns control to your application. For this reason the log file should be always placed on a fast SSD.
But for the sake of completeness:
With at least Windows Server 2016 plus SQL Server 2016 you could add NVDIMMs (non-volatile DIMM = Flash or battery backed RAM) to your server. In this case SQL Server would use this NVDIMMs to place the "hot" transaction log tail on the NVDIMMs, since they survive a power-off-event per definition.
This would increase the speed of writes drastically (since RAM is much faster than even a SSD), but you will only mention it on a database with many small writes / commits (e.g. the database behind a busy online shop or an online game with many concurrent players).
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
1
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
add a comment |
As written from the other people the transaction log will always be written to the disk, before a COMMIT returns control to your application. For this reason the log file should be always placed on a fast SSD.
But for the sake of completeness:
With at least Windows Server 2016 plus SQL Server 2016 you could add NVDIMMs (non-volatile DIMM = Flash or battery backed RAM) to your server. In this case SQL Server would use this NVDIMMs to place the "hot" transaction log tail on the NVDIMMs, since they survive a power-off-event per definition.
This would increase the speed of writes drastically (since RAM is much faster than even a SSD), but you will only mention it on a database with many small writes / commits (e.g. the database behind a busy online shop or an online game with many concurrent players).
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
As written from the other people the transaction log will always be written to the disk, before a COMMIT returns control to your application. For this reason the log file should be always placed on a fast SSD.
But for the sake of completeness:
With at least Windows Server 2016 plus SQL Server 2016 you could add NVDIMMs (non-volatile DIMM = Flash or battery backed RAM) to your server. In this case SQL Server would use this NVDIMMs to place the "hot" transaction log tail on the NVDIMMs, since they survive a power-off-event per definition.
This would increase the speed of writes drastically (since RAM is much faster than even a SSD), but you will only mention it on a database with many small writes / commits (e.g. the database behind a busy online shop or an online game with many concurrent players).
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
answered May 14 at 15:13
Thomas FranzThomas Franz
52548
52548
1
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
add a comment |
1
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
1
1
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
This not really an answer to the question, it is a plug for faster disks. Logs do not always need to be on fast storage, there are many business reason for them not to be. If you want fast buy fast, if you don't need speed....
– James Jenkins
May 14 at 16:40
add a comment |
slowjams is a new contributor. Be nice, and check out our Code of Conduct.
slowjams is a new contributor. Be nice, and check out our Code of Conduct.
slowjams is a new contributor. Be nice, and check out our Code of Conduct.
slowjams is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f238070%2ftransaction-log-in-ram-or-physical-file%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
