Showing posts with label drive. Show all posts
Showing posts with label drive. Show all posts

Thursday, March 29, 2012

Does SQL Server support compressed drive?

Hi, all,

I try to start SQL Server, but I got the Error in "ERRORLOG":

Starting up database 'master'.

The file "C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\mastlog.ldf" is compressed but does not reside in a read-only database or filegroup. The file must be decompressed.

Error: 5118, Severity: 16, State: 1.

That means, I have to decompress the file "mastlog.ldf", right?

How can I do this?

Thanks in advance!

it means somebody has changed the OS level setting of this folder or it parent folder... In property of the folder

in General Tab Press Advance button and see whether "Compress Contents to Save disk " option is choosed ... if it is there then remove that

Madhu

|||

Thank you! Madhu,

yes, I have done, It works

sql

Does SQL Server save any metadata in registry or home folder?

I have my SQL Server installation on drive c: and the databases on another
drive. My c drive got corrupted and I am planning to restore it from an old
backup. This means drive c will not be up to date.

Is there anything that SQL Server saves in the registry or in its home
folder that changes frequently? I am hoping that nothing does which means
the old backup will be good enough.

Although I think the default databases are in the c drive, I will try to
get them back from a recent backup.

John DalbergHi

SQL Server does use the registry, but the locations of the user databases
are not held there. If you don't have any databases on the C drive then you
could just install the software again, service pack it, and then re-attach
the mdf and ldf files see http://support.microsoft.com/kb/224071/ for more
information. If you don't restore master then you will need to recreate the
logins and then reconcile the orphaned users
http://support.microsoft.com/kb/274188/. If you don't restore msdb you will
need to re-create jobs, dts packages etc.

If you do restore the C drive, then you could use the installation option
that allows you to rebuild the registry to specify new locations.

John

"John Dalberg" <nospam@.nospam.sss> wrote in message
news:20060115041931.065$4x@.newsreader.com...
>I have my SQL Server installation on drive c: and the databases on another
> drive. My c drive got corrupted and I am planning to restore it from an
> old
> backup. This means drive c will not be up to date.
> Is there anything that SQL Server saves in the registry or in its home
> folder that changes frequently? I am hoping that nothing does which means
> the old backup will be good enough.
> Although I think the default databases are in the c drive, I will try to
> get them back from a recent backup.
> John Dalberg

Sunday, March 11, 2012

does importing a trace file via FN_TRACE_GETTABLE use the tempDB?

i need to look at some large trace files (3 - 8 Gig). The drive that
has the tempDB on is is small..currently has < 2 G of free space on
it.
does the FN_TRACE_GETTABLE() function route the import through the
tempDB?
if so is there a way to avoid this?
I don't want to choke the root drive of the server importing this...I have not seen it being spooled on a simple select into from a trace file
but you might just want to keep an eye on it.
--
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
<kent@.kaeservices.com> wrote in message
news:29307ecd-75d3-42e1-ba4a-06d67f0c5c14@.d4g2000prg.googlegroups.com...
>i need to look at some large trace files (3 - 8 Gig). The drive that
> has the tempDB on is is small..currently has < 2 G of free space on
> it.
> does the FN_TRACE_GETTABLE() function route the import through the
> tempDB?
> if so is there a way to avoid this?
> I don't want to choke the root drive of the server importing this...

does importing a trace file via FN_TRACE_GETTABLE use the tempDB?

i need to look at some large trace files (3 - 8 Gig). The drive that
has the tempDB on is is small..currently has < 2 G of free space on
it.
does the FN_TRACE_GETTABLE() function route the import through the
tempDB?
if so is there a way to avoid this?
I don't want to choke the root drive of the server importing this...
I have not seen it being spooled on a simple select into from a trace file
but you might just want to keep an eye on it.
Jason Massie
Web: http://statisticsio.com
RSS: http://feeds.feedburner.com/statisticsio
<kent@.kaeservices.com> wrote in message
news:29307ecd-75d3-42e1-ba4a-06d67f0c5c14@.d4g2000prg.googlegroups.com...
>i need to look at some large trace files (3 - 8 Gig). The drive that
> has the tempDB on is is small..currently has < 2 G of free space on
> it.
> does the FN_TRACE_GETTABLE() function route the import through the
> tempDB?
> if so is there a way to avoid this?
> I don't want to choke the root drive of the server importing this...

Friday, March 9, 2012

Does Disk space affect Database performance

We have aroud 12 databases running on a live production server which is
segmented
into 3 physical drives.
The E drive is where data and logs are stored.
We have implemented a back up strategy over the past week. As a result , the
E
drive has shrunk in size.
Its a total of 135 GB but has 125 MB free.
Consequently we have noticed that various VB6 and MS Access applications are
suffering from slow performance.
But..the apps are merely querying data and bringing it back to the client.
My question is the lack of disk space affecting performance?
The lack of disk space will cause performance problems, iirc the MS
recommendation is to not exceed about 80% capacity on a disk/disk set.
Not sure what you mean by backing up causing the disk to shrink in
size? Also not a good idea to have log and data files on the same
physical drive.
ALI

Does Disk space affect Database performance

We have aroud 12 databases running on a live production server which is
segmented
into 3 physical drives.
The E drive is where data and logs are stored.
We have implemented a back up strategy over the past week. As a result , the
E
drive has shrunk in size.
Its a total of 135 GB but has 125 MB free.
Consequently we have noticed that various VB6 and MS Access applications are
suffering from slow performance.
But..the apps are merely querying data and bringing it back to the client.
My question is the lack of disk space affecting performance?The lack of disk space will cause performance problems, iirc the MS
recommendation is to not exceed about 80% capacity on a disk/disk set.
Not sure what you mean by backing up causing the disk to shrink in
size? Also not a good idea to have log and data files on the same
physical drive.
ALI

Does Disk space affect Database performance

We have aroud 12 databases running on a live production server which is
segmented
into 3 physical drives.
The E drive is where data and logs are stored.
We have implemented a back up strategy over the past week. As a result , the
E
drive has shrunk in size.
Its a total of 135 GB but has 125 MB free.
Consequently we have noticed that various VB6 and MS Access applications are
suffering from slow performance.
But..the apps are merely querying data and bringing it back to the client.
My question is the lack of disk space affecting performance?The lack of disk space will cause performance problems, iirc the MS
recommendation is to not exceed about 80% capacity on a disk/disk set.
Not sure what you mean by backing up causing the disk to shrink in
size? Also not a good idea to have log and data files on the same
physical drive.
ALI

Friday, February 17, 2012

Document Management - SQL Server 2005

I am researching a server for ProSystem fx Document Management.
System requirements break down the servers 40+ GB drive like this:
c:\ system = 10 GB
d:\ log files = 10 GB
e:\SQL DB = 15 GB
Would c, d and e be one RAID 5 array?
This is my first SQL server, so I'm learning as I go forward.
Thank you for your thoughts!First off 40GB is pretty small these days and doesn't go very far. It's hard
to say what you need without a lot more info. How much and what kind of
activity do you expect? Is it mostly reads or a lot of writes as well? You
generally want to separate your log files from your data files if you have
lots of writes or the transactions are large. But placing them all one
physical Raid drive and separating them into smaller logical drives does
nothing for performance and limits what can fit in any single partition.
--
Andrew J. Kelly SQL MVP
"Gene" <Gene@.discussions.microsoft.com> wrote in message
news:1CCE910E-6419-472C-AA98-00B249AF4579@.microsoft.com...
>I am researching a server for ProSystem fx Document Management.
> System requirements break down the servers 40+ GB drive like this:
> c:\ system = 10 GB
> d:\ log files = 10 GB
> e:\SQL DB = 15 GB
> Would c, d and e be one RAID 5 array?
> This is my first SQL server, so I'm learning as I go forward.
> Thank you for your thoughts!
>
>
>|||Thank you, Andrew,
I really suspected that would be the case. The drive sizes I mentioned were
the minimum recommended sizes for the specific document management program
I'm researching.
Just as a hypothetical, would it be appropriate to mirror the system drive
and put the log and SQL drives each on three or more drives using RAID 5?
In other words:
c:\ system - mirrored (pagefile.sys here, as well)
d:\ log - RAID 5 (three drives+)
e:\ SQL DB - RAID 5 (three drives+)
Or is there a better approach? Obviously, I've never configured a SQL server
before but do want good performance... I'm not sure if I can answer your
read/write question at this point. Let's say 50/50.
I appreciate any direction you can offer.
"Andrew J. Kelly" wrote:
> First off 40GB is pretty small these days and doesn't go very far. It's hard
> to say what you need without a lot more info. How much and what kind of
> activity do you expect? Is it mostly reads or a lot of writes as well? You
> generally want to separate your log files from your data files if you have
> lots of writes or the transactions are large. But placing them all one
> physical Raid drive and separating them into smaller logical drives does
> nothing for performance and limits what can fit in any single partition.
> --
> Andrew J. Kelly SQL MVP
> "Gene" <Gene@.discussions.microsoft.com> wrote in message
> news:1CCE910E-6419-472C-AA98-00B249AF4579@.microsoft.com...
> >I am researching a server for ProSystem fx Document Management.
> >
> > System requirements break down the servers 40+ GB drive like this:
> >
> > c:\ system = 10 GB
> > d:\ log files = 10 GB
> > e:\SQL DB = 15 GB
> >
> > Would c, d and e be one RAID 5 array?
> >
> > This is my first SQL server, so I'm learning as I go forward.
> >
> > Thank you for your thoughts!
> >
> >
> >
> >
> >
>
>|||RAID 5 has a sever penalty for writes and as such is the worst to put Log
files on. Raid 1 or 10 is great for log files. What you go with really
depends a lot on what you are going to do. 50 / 50 is a lot of writes in
relation to reads but if you only do 5 transactions a second it doesn't
matter as much as if it were 500 or 5000 a second. I would go with a Raid 1
for the OS / Swap file and a Raid 1 for the Logs. Then either a 4 disk Raid
5 or a 4 disk Raid 10 if your controller supports it. A Raid 10 will usually
outperform a comparable Raid 5 for heavy write operations.
--
Andrew J. Kelly SQL MVP
"Gene" <Gene@.discussions.microsoft.com> wrote in message
news:8ED269A3-AAF6-4712-85D6-15A5B62C5DCB@.microsoft.com...
> Thank you, Andrew,
> I really suspected that would be the case. The drive sizes I mentioned
> were
> the minimum recommended sizes for the specific document management program
> I'm researching.
> Just as a hypothetical, would it be appropriate to mirror the system drive
> and put the log and SQL drives each on three or more drives using RAID 5?
> In other words:
> c:\ system - mirrored (pagefile.sys here, as well)
> d:\ log - RAID 5 (three drives+)
> e:\ SQL DB - RAID 5 (three drives+)
> Or is there a better approach? Obviously, I've never configured a SQL
> server
> before but do want good performance... I'm not sure if I can answer your
> read/write question at this point. Let's say 50/50.
> I appreciate any direction you can offer.
>
> "Andrew J. Kelly" wrote:
>> First off 40GB is pretty small these days and doesn't go very far. It's
>> hard
>> to say what you need without a lot more info. How much and what kind of
>> activity do you expect? Is it mostly reads or a lot of writes as well?
>> You
>> generally want to separate your log files from your data files if you
>> have
>> lots of writes or the transactions are large. But placing them all one
>> physical Raid drive and separating them into smaller logical drives does
>> nothing for performance and limits what can fit in any single partition.
>> --
>> Andrew J. Kelly SQL MVP
>> "Gene" <Gene@.discussions.microsoft.com> wrote in message
>> news:1CCE910E-6419-472C-AA98-00B249AF4579@.microsoft.com...
>> >I am researching a server for ProSystem fx Document Management.
>> >
>> > System requirements break down the servers 40+ GB drive like this:
>> >
>> > c:\ system = 10 GB
>> > d:\ log files = 10 GB
>> > e:\SQL DB = 15 GB
>> >
>> > Would c, d and e be one RAID 5 array?
>> >
>> > This is my first SQL server, so I'm learning as I go forward.
>> >
>> > Thank you for your thoughts!
>> >
>> >
>> >
>> >
>> >
>>|||Thanks a bunch Andrew. That's very helpful and exactly what I need to know.
"Andrew J. Kelly" wrote:
> RAID 5 has a sever penalty for writes and as such is the worst to put Log
> files on. Raid 1 or 10 is great for log files. What you go with really
> depends a lot on what you are going to do. 50 / 50 is a lot of writes in
> relation to reads but if you only do 5 transactions a second it doesn't
> matter as much as if it were 500 or 5000 a second. I would go with a Raid 1
> for the OS / Swap file and a Raid 1 for the Logs. Then either a 4 disk Raid
> 5 or a 4 disk Raid 10 if your controller supports it. A Raid 10 will usually
> outperform a comparable Raid 5 for heavy write operations.
> --
> Andrew J. Kelly SQL MVP
> "Gene" <Gene@.discussions.microsoft.com> wrote in message
> news:8ED269A3-AAF6-4712-85D6-15A5B62C5DCB@.microsoft.com...
> > Thank you, Andrew,
> >
> > I really suspected that would be the case. The drive sizes I mentioned
> > were
> > the minimum recommended sizes for the specific document management program
> > I'm researching.
> >
> > Just as a hypothetical, would it be appropriate to mirror the system drive
> > and put the log and SQL drives each on three or more drives using RAID 5?
> >
> > In other words:
> >
> > c:\ system - mirrored (pagefile.sys here, as well)
> > d:\ log - RAID 5 (three drives+)
> > e:\ SQL DB - RAID 5 (three drives+)
> >
> > Or is there a better approach? Obviously, I've never configured a SQL
> > server
> > before but do want good performance... I'm not sure if I can answer your
> > read/write question at this point. Let's say 50/50.
> >
> > I appreciate any direction you can offer.
> >
> >
> >
> > "Andrew J. Kelly" wrote:
> >
> >> First off 40GB is pretty small these days and doesn't go very far. It's
> >> hard
> >> to say what you need without a lot more info. How much and what kind of
> >> activity do you expect? Is it mostly reads or a lot of writes as well?
> >> You
> >> generally want to separate your log files from your data files if you
> >> have
> >> lots of writes or the transactions are large. But placing them all one
> >> physical Raid drive and separating them into smaller logical drives does
> >> nothing for performance and limits what can fit in any single partition.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >> "Gene" <Gene@.discussions.microsoft.com> wrote in message
> >> news:1CCE910E-6419-472C-AA98-00B249AF4579@.microsoft.com...
> >> >I am researching a server for ProSystem fx Document Management.
> >> >
> >> > System requirements break down the servers 40+ GB drive like this:
> >> >
> >> > c:\ system = 10 GB
> >> > d:\ log files = 10 GB
> >> > e:\SQL DB = 15 GB
> >> >
> >> > Would c, d and e be one RAID 5 array?
> >> >
> >> > This is my first SQL server, so I'm learning as I go forward.
> >> >
> >> > Thank you for your thoughts!
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>

Document Management - SQL Server 2005

I am researching a server for ProSystem fx Document Management.
System requirements break down the servers 40+ GB drive like this:
c:\ system = 10 GB
d:\ log files = 10 GB
e:\SQL DB = 15 GB
Would c, d and e be one RAID 5 array?
This is my first SQL server, so I'm learning as I go forward.
Thank you for your thoughts!First off 40GB is pretty small these days and doesn't go very far. It's hard
to say what you need without a lot more info. How much and what kind of
activity do you expect? Is it mostly reads or a lot of writes as well? You
generally want to separate your log files from your data files if you have
lots of writes or the transactions are large. But placing them all one
physical Raid drive and separating them into smaller logical drives does
nothing for performance and limits what can fit in any single partition.
Andrew J. Kelly SQL MVP
"Gene" <Gene@.discussions.microsoft.com> wrote in message
news:1CCE910E-6419-472C-AA98-00B249AF4579@.microsoft.com...
>I am researching a server for ProSystem fx Document Management.
> System requirements break down the servers 40+ GB drive like this:
> c:\ system = 10 GB
> d:\ log files = 10 GB
> e:\SQL DB = 15 GB
> Would c, d and e be one RAID 5 array?
> This is my first SQL server, so I'm learning as I go forward.
> Thank you for your thoughts!
>
>
>|||Thank you, Andrew,
I really suspected that would be the case. The drive sizes I mentioned were
the minimum recommended sizes for the specific document management program
I'm researching.
Just as a hypothetical, would it be appropriate to mirror the system drive
and put the log and SQL drives each on three or more drives using RAID 5?
In other words:
c:\ system - mirrored (pagefile.sys here, as well)
d:\ log - RAID 5 (three drives+)
e:\ SQL DB - RAID 5 (three drives+)
Or is there a better approach? Obviously, I've never configured a SQL server
before but do want good performance... I'm not sure if I can answer your
read/write question at this point. Let's say 50/50.
I appreciate any direction you can offer.
"Andrew J. Kelly" wrote:

> First off 40GB is pretty small these days and doesn't go very far. It's ha
rd
> to say what you need without a lot more info. How much and what kind of
> activity do you expect? Is it mostly reads or a lot of writes as well? Yo
u
> generally want to separate your log files from your data files if you have
> lots of writes or the transactions are large. But placing them all one
> physical Raid drive and separating them into smaller logical drives does
> nothing for performance and limits what can fit in any single partition.
> --
> Andrew J. Kelly SQL MVP
> "Gene" <Gene@.discussions.microsoft.com> wrote in message
> news:1CCE910E-6419-472C-AA98-00B249AF4579@.microsoft.com...
>
>|||RAID 5 has a sever penalty for writes and as such is the worst to put Log
files on. Raid 1 or 10 is great for log files. What you go with really
depends a lot on what you are going to do. 50 / 50 is a lot of writes in
relation to reads but if you only do 5 transactions a second it doesn't
matter as much as if it were 500 or 5000 a second. I would go with a Raid 1
for the OS / Swap file and a Raid 1 for the Logs. Then either a 4 disk Raid
5 or a 4 disk Raid 10 if your controller supports it. A Raid 10 will usually
outperform a comparable Raid 5 for heavy write operations.
Andrew J. Kelly SQL MVP
"Gene" <Gene@.discussions.microsoft.com> wrote in message
news:8ED269A3-AAF6-4712-85D6-15A5B62C5DCB@.microsoft.com...[vbcol=seagreen]
> Thank you, Andrew,
> I really suspected that would be the case. The drive sizes I mentioned
> were
> the minimum recommended sizes for the specific document management program
> I'm researching.
> Just as a hypothetical, would it be appropriate to mirror the system drive
> and put the log and SQL drives each on three or more drives using RAID 5?
> In other words:
> c:\ system - mirrored (pagefile.sys here, as well)
> d:\ log - RAID 5 (three drives+)
> e:\ SQL DB - RAID 5 (three drives+)
> Or is there a better approach? Obviously, I've never configured a SQL
> server
> before but do want good performance... I'm not sure if I can answer your
> read/write question at this point. Let's say 50/50.
> I appreciate any direction you can offer.
>
> "Andrew J. Kelly" wrote:
>|||Thanks a bunch Andrew. That's very helpful and exactly what I need to know.
"Andrew J. Kelly" wrote:

> RAID 5 has a sever penalty for writes and as such is the worst to put Log
> files on. Raid 1 or 10 is great for log files. What you go with really
> depends a lot on what you are going to do. 50 / 50 is a lot of writes in
> relation to reads but if you only do 5 transactions a second it doesn't
> matter as much as if it were 500 or 5000 a second. I would go with a Raid
1
> for the OS / Swap file and a Raid 1 for the Logs. Then either a 4 disk Rai
d
> 5 or a 4 disk Raid 10 if your controller supports it. A Raid 10 will usual
ly
> outperform a comparable Raid 5 for heavy write operations.
> --
> Andrew J. Kelly SQL MVP
> "Gene" <Gene@.discussions.microsoft.com> wrote in message
> news:8ED269A3-AAF6-4712-85D6-15A5B62C5DCB@.microsoft.com...
>
>