Hi,
I'm trying to get up to speed on SQL Server and data storage solutions.
I've read many posts which indicate that the transaction log should be
placed on it's own dedicated volume. I think that I understand the
rationale: Writes to the log are sequential in nature and it's
counterproductive to have random I/O to the database interfere with these
sequential log writes.
Does this logic still hold true when using the Simple recovery model?
I've read a bit about this model and the documentation states that when
operating under the rules of this model, SQL Server will truncate the log
after each transaction. Doesn't this imply that writing to the log would NOT
be sequential in nature since each write begins at position x, the write
takes place, and then the drive must return to position x again for the next
write? Or is this protocol still considered a sequential write and should
therefore be isolated on a dedicated volume?
Thanks,
DavidLarry,
It holds for simple recovery mode as well. SQL Server doesn't truncate the log after each
transaction. It truncates after each time it performs a checkpoint (read about checkpoint in Books
Online).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Larry David" <invalid@.bogus.bum> wrote in message news:CsudnU16LPcHoqrfRVn-hA@.giganews.com...
> Hi,
> I'm trying to get up to speed on SQL Server and data storage solutions.
> I've read many posts which indicate that the transaction log should be
> placed on it's own dedicated volume. I think that I understand the
> rationale: Writes to the log are sequential in nature and it's
> counterproductive to have random I/O to the database interfere with these
> sequential log writes.
> Does this logic still hold true when using the Simple recovery model?
> I've read a bit about this model and the documentation states that when
> operating under the rules of this model, SQL Server will truncate the log
> after each transaction. Doesn't this imply that writing to the log would NOT
> be sequential in nature since each write begins at position x, the write
> takes place, and then the drive must return to position x again for the next
> write? Or is this protocol still considered a sequential write and should
> therefore be isolated on a dedicated volume?
> Thanks,
> David
>
>sql
Showing posts with label indicate. Show all posts
Showing posts with label indicate. Show all posts
Wednesday, March 21, 2012
Does placing the transaction log on dedicated RAID volume make sense with Simple Recovery
Hi,
I'm trying to get up to speed on SQL Server and data storage solutions.
I've read many posts which indicate that the transaction log should be
placed on it's own dedicated volume. I think that I understand the
rationale: Writes to the log are sequential in nature and it's
counterproductive to have random I/O to the database interfere with these
sequential log writes.
Does this logic still hold true when using the Simple recovery model?
I've read a bit about this model and the documentation states that when
operating under the rules of this model, SQL Server will truncate the log
after each transaction. Doesn't this imply that writing to the log would NOT
be sequential in nature since each write begins at position x, the write
takes place, and then the drive must return to position x again for the next
write? Or is this protocol still considered a sequential write and should
therefore be isolated on a dedicated volume?
Thanks,
David
Larry,
It holds for simple recovery mode as well. SQL Server doesn't truncate the log after each
transaction. It truncates after each time it performs a checkpoint (read about checkpoint in Books
Online).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Larry David" <invalid@.bogus.bum> wrote in message news:CsudnU16LPcHoqrfRVn-hA@.giganews.com...
> Hi,
> I'm trying to get up to speed on SQL Server and data storage solutions.
> I've read many posts which indicate that the transaction log should be
> placed on it's own dedicated volume. I think that I understand the
> rationale: Writes to the log are sequential in nature and it's
> counterproductive to have random I/O to the database interfere with these
> sequential log writes.
> Does this logic still hold true when using the Simple recovery model?
> I've read a bit about this model and the documentation states that when
> operating under the rules of this model, SQL Server will truncate the log
> after each transaction. Doesn't this imply that writing to the log would NOT
> be sequential in nature since each write begins at position x, the write
> takes place, and then the drive must return to position x again for the next
> write? Or is this protocol still considered a sequential write and should
> therefore be isolated on a dedicated volume?
> Thanks,
> David
>
>
I'm trying to get up to speed on SQL Server and data storage solutions.
I've read many posts which indicate that the transaction log should be
placed on it's own dedicated volume. I think that I understand the
rationale: Writes to the log are sequential in nature and it's
counterproductive to have random I/O to the database interfere with these
sequential log writes.
Does this logic still hold true when using the Simple recovery model?
I've read a bit about this model and the documentation states that when
operating under the rules of this model, SQL Server will truncate the log
after each transaction. Doesn't this imply that writing to the log would NOT
be sequential in nature since each write begins at position x, the write
takes place, and then the drive must return to position x again for the next
write? Or is this protocol still considered a sequential write and should
therefore be isolated on a dedicated volume?
Thanks,
David
Larry,
It holds for simple recovery mode as well. SQL Server doesn't truncate the log after each
transaction. It truncates after each time it performs a checkpoint (read about checkpoint in Books
Online).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Larry David" <invalid@.bogus.bum> wrote in message news:CsudnU16LPcHoqrfRVn-hA@.giganews.com...
> Hi,
> I'm trying to get up to speed on SQL Server and data storage solutions.
> I've read many posts which indicate that the transaction log should be
> placed on it's own dedicated volume. I think that I understand the
> rationale: Writes to the log are sequential in nature and it's
> counterproductive to have random I/O to the database interfere with these
> sequential log writes.
> Does this logic still hold true when using the Simple recovery model?
> I've read a bit about this model and the documentation states that when
> operating under the rules of this model, SQL Server will truncate the log
> after each transaction. Doesn't this imply that writing to the log would NOT
> be sequential in nature since each write begins at position x, the write
> takes place, and then the drive must return to position x again for the next
> write? Or is this protocol still considered a sequential write and should
> therefore be isolated on a dedicated volume?
> Thanks,
> David
>
>
Does placing the transaction log on dedicated RAID volume make sense with Simple Recov
Hi,
I'm trying to get up to speed on SQL Server and data storage solutions.
I've read many posts which indicate that the transaction log should be
placed on it's own dedicated volume. I think that I understand the
rationale: Writes to the log are sequential in nature and it's
counterproductive to have random I/O to the database interfere with these
sequential log writes.
Does this logic still hold true when using the Simple recovery model?
I've read a bit about this model and the documentation states that when
operating under the rules of this model, SQL Server will truncate the log
after each transaction. Doesn't this imply that writing to the log would NOT
be sequential in nature since each write begins at position x, the write
takes place, and then the drive must return to position x again for the next
write? Or is this protocol still considered a sequential write and should
therefore be isolated on a dedicated volume?
Thanks,
DavidLarry,
It holds for simple recovery mode as well. SQL Server doesn't truncate the l
og after each
transaction. It truncates after each time it performs a checkpoint (read abo
ut checkpoint in Books
Online).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Larry David" <invalid@.bogus.bum> wrote in message news:CsudnU16LPcHoqrfRVn-hA@.giganews.com.
.
> Hi,
> I'm trying to get up to speed on SQL Server and data storage solutions.
> I've read many posts which indicate that the transaction log should be
> placed on it's own dedicated volume. I think that I understand the
> rationale: Writes to the log are sequential in nature and it's
> counterproductive to have random I/O to the database interfere with these
> sequential log writes.
> Does this logic still hold true when using the Simple recovery model?
> I've read a bit about this model and the documentation states that when
> operating under the rules of this model, SQL Server will truncate the log
> after each transaction. Doesn't this imply that writing to the log would N
OT
> be sequential in nature since each write begins at position x, the write
> takes place, and then the drive must return to position x again for the ne
xt
> write? Or is this protocol still considered a sequential write and should
> therefore be isolated on a dedicated volume?
> Thanks,
> David
>
>
I'm trying to get up to speed on SQL Server and data storage solutions.
I've read many posts which indicate that the transaction log should be
placed on it's own dedicated volume. I think that I understand the
rationale: Writes to the log are sequential in nature and it's
counterproductive to have random I/O to the database interfere with these
sequential log writes.
Does this logic still hold true when using the Simple recovery model?
I've read a bit about this model and the documentation states that when
operating under the rules of this model, SQL Server will truncate the log
after each transaction. Doesn't this imply that writing to the log would NOT
be sequential in nature since each write begins at position x, the write
takes place, and then the drive must return to position x again for the next
write? Or is this protocol still considered a sequential write and should
therefore be isolated on a dedicated volume?
Thanks,
DavidLarry,
It holds for simple recovery mode as well. SQL Server doesn't truncate the l
og after each
transaction. It truncates after each time it performs a checkpoint (read abo
ut checkpoint in Books
Online).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Larry David" <invalid@.bogus.bum> wrote in message news:CsudnU16LPcHoqrfRVn-hA@.giganews.com.
.
> Hi,
> I'm trying to get up to speed on SQL Server and data storage solutions.
> I've read many posts which indicate that the transaction log should be
> placed on it's own dedicated volume. I think that I understand the
> rationale: Writes to the log are sequential in nature and it's
> counterproductive to have random I/O to the database interfere with these
> sequential log writes.
> Does this logic still hold true when using the Simple recovery model?
> I've read a bit about this model and the documentation states that when
> operating under the rules of this model, SQL Server will truncate the log
> after each transaction. Doesn't this imply that writing to the log would N
OT
> be sequential in nature since each write begins at position x, the write
> takes place, and then the drive must return to position x again for the ne
xt
> write? Or is this protocol still considered a sequential write and should
> therefore be isolated on a dedicated volume?
> Thanks,
> David
>
>
Friday, February 17, 2012
Document map on Mac
I have seen other posts which indicate issues with the document map
and issues with reporting output in general on the Mac. However, I
haven't seen that anyone is having the specific problem I am having.
I have a report which uses a document map. It works perfectly in IE
6.0 on a PC when rendered as HTML or PDF. The report displays as HTML
(but not PDF) on the Mac in both IE and Safari, however the document
map does not display. This functionality is crucial for me. My main
concern for this particular client is making this document map work
with IE on the Mac whether that be in HTML or PDF. I should note
that, long term, I expect to see reports work in both browsers on the
Mac.
So my question is specifically:
Has anyone succeeded in displaying the document map in a report
rendered as HTML or PDF in IE on a Macintosh running OS 9 or OS 10,
latest release of IE.I have more information which I am sharing with anyone else who is
having this problem. The HTML output seems to use an IFrame. The
IFrame is supported in IE 5.2.3 for the Mac and it is also supported
in Safari. So, I still don't know why the document map doesn't show
up in HTML.
However, the PDF problem was with the Preview application in the Mac.
By default, PDF files are opened by Preview, even when they are opened
from a web page. I have opened other PDF 1.3 files from the web with
Preview without any problems. However, for some reason, Preview could
not open my reports generated from SQLRS. I was able to use the
Finder, Get Info feature on the Mac to tell the OS to open PDF files
with Adobe Reader 6.0 instead of Preview. So, I can now provide a
solution for reports, including a document map(Bookmarks in a PDF), on
the Mac.
I would still prefer to use HTML, which is faster, and does not
require a 2nd window to open.
eppingerr@.software-answers.com (Randy Eppinger) wrote in message news:<abcba2fa.0407160715.65406a3d@.posting.google.com>...
> I have seen other posts which indicate issues with the document map
> and issues with reporting output in general on the Mac. However, I
> haven't seen that anyone is having the specific problem I am having.
> I have a report which uses a document map. It works perfectly in IE
> 6.0 on a PC when rendered as HTML or PDF. The report displays as HTML
> (but not PDF) on the Mac in both IE and Safari, however the document
> map does not display. This functionality is crucial for me. My main
> concern for this particular client is making this document map work
> with IE on the Mac whether that be in HTML or PDF. I should note
> that, long term, I expect to see reports work in both browsers on the
> Mac.
> So my question is specifically:
> Has anyone succeeded in displaying the document map in a report
> rendered as HTML or PDF in IE on a Macintosh running OS 9 or OS 10,
> latest release of IE.|||The document map is only supported on IE 5.5 and higher on Windows.
--
This posting is provided "AS IS" with no warranties, and confers no rights
"Randy Eppinger" <eppingerr@.software-answers.com> wrote in message
news:abcba2fa.0407200502.524abb87@.posting.google.com...
> I have more information which I am sharing with anyone else who is
> having this problem. The HTML output seems to use an IFrame. The
> IFrame is supported in IE 5.2.3 for the Mac and it is also supported
> in Safari. So, I still don't know why the document map doesn't show
> up in HTML.
> However, the PDF problem was with the Preview application in the Mac.
> By default, PDF files are opened by Preview, even when they are opened
> from a web page. I have opened other PDF 1.3 files from the web with
> Preview without any problems. However, for some reason, Preview could
> not open my reports generated from SQLRS. I was able to use the
> Finder, Get Info feature on the Mac to tell the OS to open PDF files
> with Adobe Reader 6.0 instead of Preview. So, I can now provide a
> solution for reports, including a document map(Bookmarks in a PDF), on
> the Mac.
> I would still prefer to use HTML, which is faster, and does not
> require a 2nd window to open.
>
> eppingerr@.software-answers.com (Randy Eppinger) wrote in message
news:<abcba2fa.0407160715.65406a3d@.posting.google.com>...
> > I have seen other posts which indicate issues with the document map
> > and issues with reporting output in general on the Mac. However, I
> > haven't seen that anyone is having the specific problem I am having.
> >
> > I have a report which uses a document map. It works perfectly in IE
> > 6.0 on a PC when rendered as HTML or PDF. The report displays as HTML
> > (but not PDF) on the Mac in both IE and Safari, however the document
> > map does not display. This functionality is crucial for me. My main
> > concern for this particular client is making this document map work
> > with IE on the Mac whether that be in HTML or PDF. I should note
> > that, long term, I expect to see reports work in both browsers on the
> > Mac.
> >
> > So my question is specifically:
> > Has anyone succeeded in displaying the document map in a report
> > rendered as HTML or PDF in IE on a Macintosh running OS 9 or OS 10,
> > latest release of IE.
and issues with reporting output in general on the Mac. However, I
haven't seen that anyone is having the specific problem I am having.
I have a report which uses a document map. It works perfectly in IE
6.0 on a PC when rendered as HTML or PDF. The report displays as HTML
(but not PDF) on the Mac in both IE and Safari, however the document
map does not display. This functionality is crucial for me. My main
concern for this particular client is making this document map work
with IE on the Mac whether that be in HTML or PDF. I should note
that, long term, I expect to see reports work in both browsers on the
Mac.
So my question is specifically:
Has anyone succeeded in displaying the document map in a report
rendered as HTML or PDF in IE on a Macintosh running OS 9 or OS 10,
latest release of IE.I have more information which I am sharing with anyone else who is
having this problem. The HTML output seems to use an IFrame. The
IFrame is supported in IE 5.2.3 for the Mac and it is also supported
in Safari. So, I still don't know why the document map doesn't show
up in HTML.
However, the PDF problem was with the Preview application in the Mac.
By default, PDF files are opened by Preview, even when they are opened
from a web page. I have opened other PDF 1.3 files from the web with
Preview without any problems. However, for some reason, Preview could
not open my reports generated from SQLRS. I was able to use the
Finder, Get Info feature on the Mac to tell the OS to open PDF files
with Adobe Reader 6.0 instead of Preview. So, I can now provide a
solution for reports, including a document map(Bookmarks in a PDF), on
the Mac.
I would still prefer to use HTML, which is faster, and does not
require a 2nd window to open.
eppingerr@.software-answers.com (Randy Eppinger) wrote in message news:<abcba2fa.0407160715.65406a3d@.posting.google.com>...
> I have seen other posts which indicate issues with the document map
> and issues with reporting output in general on the Mac. However, I
> haven't seen that anyone is having the specific problem I am having.
> I have a report which uses a document map. It works perfectly in IE
> 6.0 on a PC when rendered as HTML or PDF. The report displays as HTML
> (but not PDF) on the Mac in both IE and Safari, however the document
> map does not display. This functionality is crucial for me. My main
> concern for this particular client is making this document map work
> with IE on the Mac whether that be in HTML or PDF. I should note
> that, long term, I expect to see reports work in both browsers on the
> Mac.
> So my question is specifically:
> Has anyone succeeded in displaying the document map in a report
> rendered as HTML or PDF in IE on a Macintosh running OS 9 or OS 10,
> latest release of IE.|||The document map is only supported on IE 5.5 and higher on Windows.
--
This posting is provided "AS IS" with no warranties, and confers no rights
"Randy Eppinger" <eppingerr@.software-answers.com> wrote in message
news:abcba2fa.0407200502.524abb87@.posting.google.com...
> I have more information which I am sharing with anyone else who is
> having this problem. The HTML output seems to use an IFrame. The
> IFrame is supported in IE 5.2.3 for the Mac and it is also supported
> in Safari. So, I still don't know why the document map doesn't show
> up in HTML.
> However, the PDF problem was with the Preview application in the Mac.
> By default, PDF files are opened by Preview, even when they are opened
> from a web page. I have opened other PDF 1.3 files from the web with
> Preview without any problems. However, for some reason, Preview could
> not open my reports generated from SQLRS. I was able to use the
> Finder, Get Info feature on the Mac to tell the OS to open PDF files
> with Adobe Reader 6.0 instead of Preview. So, I can now provide a
> solution for reports, including a document map(Bookmarks in a PDF), on
> the Mac.
> I would still prefer to use HTML, which is faster, and does not
> require a 2nd window to open.
>
> eppingerr@.software-answers.com (Randy Eppinger) wrote in message
news:<abcba2fa.0407160715.65406a3d@.posting.google.com>...
> > I have seen other posts which indicate issues with the document map
> > and issues with reporting output in general on the Mac. However, I
> > haven't seen that anyone is having the specific problem I am having.
> >
> > I have a report which uses a document map. It works perfectly in IE
> > 6.0 on a PC when rendered as HTML or PDF. The report displays as HTML
> > (but not PDF) on the Mac in both IE and Safari, however the document
> > map does not display. This functionality is crucial for me. My main
> > concern for this particular client is making this document map work
> > with IE on the Mac whether that be in HTML or PDF. I should note
> > that, long term, I expect to see reports work in both browsers on the
> > Mac.
> >
> > So my question is specifically:
> > Has anyone succeeded in displaying the document map in a report
> > rendered as HTML or PDF in IE on a Macintosh running OS 9 or OS 10,
> > latest release of IE.
Subscribe to:
Posts (Atom)