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

Wednesday, March 21, 2012

Location of transaction log on another machine

Hi,
We have SQL server 2000 enterprise edition installed on a machine with
only one hard drive. On this server we have a small but critical
database. I have noticed that the person who created this database
placed the location of the transaction log on the same machine as the
data file.
Can I move the transaction log to another machine on the network that
doesn't have SQL server installed? Will there be a performance hit if
SQL Server has to write to this log over the network? If so will it be
major?
I know ideally we should be using a RAID setup of some sort, but for
finacial and political reasons this is not an option.
Cheers,
Steve
Basically, SQL Server doesn't support this. Doing it would be a big performance hit for
modifications. For the full story, check out
http://support.microsoft.com/default...b;en-us;304261
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Steve" <steve.hager@.gmail.com> wrote in message
news:d5c55fd1.0412012214.76710133@.posting.google.c om...
> Hi,
> We have SQL server 2000 enterprise edition installed on a machine with
> only one hard drive. On this server we have a small but critical
> database. I have noticed that the person who created this database
> placed the location of the transaction log on the same machine as the
> data file.
> Can I move the transaction log to another machine on the network that
> doesn't have SQL server installed? Will there be a performance hit if
> SQL Server has to write to this log over the network? If so will it be
> major?
> I know ideally we should be using a RAID setup of some sort, but for
> finacial and political reasons this is not an option.
> Cheers,
>
> Steve
|||Steve wrote:
> Hi,
> We have SQL server 2000 enterprise edition installed on a machine with
> only one hard drive. On this server we have a small but critical
> database. I have noticed that the person who created this database
> placed the location of the transaction log on the same machine as the
> data file.
> Can I move the transaction log to another machine on the network that
> doesn't have SQL server installed? Will there be a performance hit if
> SQL Server has to write to this log over the network? If so will it be
> major?
> I know ideally we should be using a RAID setup of some sort, but for
> finacial and political reasons this is not an option.
> Cheers,
>
> Steve
How about another hard drive. That's no too much money...
If it's a small database, it'll probably be fine.
David Gugick
Imceda Software
www.imceda.com

Location of transaction log on another machine

Hi,
We have SQL server 2000 enterprise edition installed on a machine with
only one hard drive. On this server we have a small but critical
database. I have noticed that the person who created this database
placed the location of the transaction log on the same machine as the
data file.
Can I move the transaction log to another machine on the network that
doesn't have SQL server installed? Will there be a performance hit if
SQL Server has to write to this log over the network? If so will it be
major?
I know ideally we should be using a RAID setup of some sort, but for
finacial and political reasons this is not an option.
Cheers,
SteveBasically, SQL Server doesn't support this. Doing it would be a big performa
nce hit for
modifications. For the full story, check out
http://support.microsoft.com/defaul...kb;en-us;304261
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Steve" <steve.hager@.gmail.com> wrote in message
news:d5c55fd1.0412012214.76710133@.posting.google.com...
> Hi,
> We have SQL server 2000 enterprise edition installed on a machine with
> only one hard drive. On this server we have a small but critical
> database. I have noticed that the person who created this database
> placed the location of the transaction log on the same machine as the
> data file.
> Can I move the transaction log to another machine on the network that
> doesn't have SQL server installed? Will there be a performance hit if
> SQL Server has to write to this log over the network? If so will it be
> major?
> I know ideally we should be using a RAID setup of some sort, but for
> finacial and political reasons this is not an option.
> Cheers,
>
> Steve|||Steve wrote:
> Hi,
> We have SQL server 2000 enterprise edition installed on a machine with
> only one hard drive. On this server we have a small but critical
> database. I have noticed that the person who created this database
> placed the location of the transaction log on the same machine as the
> data file.
> Can I move the transaction log to another machine on the network that
> doesn't have SQL server installed? Will there be a performance hit if
> SQL Server has to write to this log over the network? If so will it be
> major?
> I know ideally we should be using a RAID setup of some sort, but for
> finacial and political reasons this is not an option.
> Cheers,
>
> Steve
How about another hard drive. That's no too much money...
If it's a small database, it'll probably be fine.
David Gugick
Imceda Software
www.imceda.com

Location of transaction log on another machine

Hi,
We have SQL server 2000 enterprise edition installed on a machine with
only one hard drive. On this server we have a small but critical
database. I have noticed that the person who created this database
placed the location of the transaction log on the same machine as the
data file.
Can I move the transaction log to another machine on the network that
doesn't have SQL server installed? Will there be a performance hit if
SQL Server has to write to this log over the network? If so will it be
major?
I know ideally we should be using a RAID setup of some sort, but for
finacial and political reasons this is not an option.
Cheers,
SteveBasically, SQL Server doesn't support this. Doing it would be a big performance hit for
modifications. For the full story, check out
http://support.microsoft.com/default.aspx?scid=kb;en-us;304261
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Steve" <steve.hager@.gmail.com> wrote in message
news:d5c55fd1.0412012214.76710133@.posting.google.com...
> Hi,
> We have SQL server 2000 enterprise edition installed on a machine with
> only one hard drive. On this server we have a small but critical
> database. I have noticed that the person who created this database
> placed the location of the transaction log on the same machine as the
> data file.
> Can I move the transaction log to another machine on the network that
> doesn't have SQL server installed? Will there be a performance hit if
> SQL Server has to write to this log over the network? If so will it be
> major?
> I know ideally we should be using a RAID setup of some sort, but for
> finacial and political reasons this is not an option.
> Cheers,
>
> Steve|||Steve wrote:
> Hi,
> We have SQL server 2000 enterprise edition installed on a machine with
> only one hard drive. On this server we have a small but critical
> database. I have noticed that the person who created this database
> placed the location of the transaction log on the same machine as the
> data file.
> Can I move the transaction log to another machine on the network that
> doesn't have SQL server installed? Will there be a performance hit if
> SQL Server has to write to this log over the network? If so will it be
> major?
> I know ideally we should be using a RAID setup of some sort, but for
> finacial and political reasons this is not an option.
> Cheers,
>
> Steve
How about another hard drive. That's no too much money...
If it's a small database, it'll probably be fine.
David Gugick
Imceda Software
www.imceda.com

Location of the Audit Log

This should be an easy one: when I turn on the Audit Log, what directory and
what is the log called? Can I send the log to a drive other than the drive
I have my data files on?SQL Server auditing is sent to the NT Event logs.
Is this what you are asking?
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||I need the name of the file SQL Server creates. I am looking in that config
folder and ther is at least 14 NT files in this thing!|||Errorlogs are sent to the drive specified by this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MS
SQLServer\MSSQLServer\Parameters
SQLArg1
Hope this helps.
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||got it! Thanks for all your help!

Location of SQL Server Express

Can i put sql sever on my computer and have the db on a mapped drive on our company network?

Mapped Drive -No;

Logical Drive (LUN) -Yes

Does your network have a NAS or SAN? (That would work.) Just mapping to a file server does not.

sql

Location of default instance SQL server 2005 files

I have just installed SQL Server 2005. I was not given a choice during installation (that I remember seeing anyway) about which drive I wanted to place the default SQL instance on.

It ended up on C: and I needed it on D:.

So my questions are:

    Is there a way to move it to D: that is easier than the way you had to go about it in SQL 2000?

    Is there a way to do it during setup so I can avoid this in the future?

Please refere to a previous posting called "How to specify default data location? " .. which talks about the exact place to change it.|||

There is a file called template.ini located at the same folder as setup.exe. In this file, all related command line parameters are discussed when SQL Server 2005 is installed under unattended mode, i.e., command line. You can specify paths to install SQL Server 2005 components.

Under attended mode, i.e., GUI mode, during selecting components to install, clicking the Advanced button will prompt to change paths to install SQL Server 2005 components.

|||

Jiongxiong,

There is no file "template.ini" with the SQL setup program (cd or installed location).

The SQL readme points to a generic windows deployment info page - which is unhelpful.

|||

If you're installing SQL Server Express edition you are running an executable called SQLEXPR.EXE. This is a compressed package that when run expands the contents to a temporary folder, runs the installation and then deletes the temporary folder. You can persist the uncompressed contents by running sqlexpr.exe /x - this will prompt you for a folder to save the uncompressed files. Once uncompressed you'll find the template.ini file in this folder (same folder as setup.exe). The parameters that can be passed to setup.exe can also be passed to sqlexpr.exe - the compression tool will pass the parameters to setup.exe when it runs it.

If you're installing an edition other than Express you will find template.ini in the same folder as setup.exe.

Cheers,
Dan

|||

Jiongxiong, you are right! Sorry, I missed the template.ini file somehow. I will see if it works for my clean install tests.

It is simply amazing that M$ can not do simple file management for installation. There are files, they have versions, they need to be copied to a folder from the CD, and some settings stored - how complicated is that? Well if you are M$ you make SQL05 installation into a mass of gobble-gook. SQL Server 05 is not ready for production use until its installation abomination is fixed!

|||

Most people think that SQL Server setup is just about copying files and writing some reg keys. While it's true it's only a small fraction of what setup does. Here is a small sampling of the other things SQL Server setup does.

SQL Server setup checks the configuration of the machine to determine if the machine is in a valid state - which improves the chances of a good installation. Windows Installer doesn't support this.

SQL Server is a multi-instance product. Windows Installer doesn't support this.

SQL Server requires configuration to happen as part of the setup process. Windows Installer doesn't support this. If you've ever performed a MySQL installation a separate tool is launched post setup to do the configuration - although at the end of setup you don't have a working server.

SQL Server cluster install is extremely robust. Every other product I've seen requires you to rerun setup on every node and make sure the configurations are the same. SQL does this for you. Windows Installer doesn't support cluster installs.

SQL Server requires a secure installation. This means that every file/directory/service/reg key is ACL'd to the appropriate service account. Windows Installer doesn't support this.

SQL Server setup supports version and edition upgrade. Windows Installer doesn't support this.

Windows Installer handles very well the copying of files and the writing of reg keys, but it doesn't handle any of the other complexities associated with SQL Server setup. Everywhere I mentioned that Windows Installer doesn't support something it means we've had to build it. I'm not using this as an excuse, but merely highlighting the fact that setup is much more than just copying files and writing reg keys. Anyone who's worked on the setup of a complex product (such as SQL or Visual Studio) will attest to this.

Is our setup perfect? No. But I certainly don't believe it deserves the criticism. There are millions of ways a user can hose their machine and it would be impossible for us to test for every single case. I'm sure you'll be tempted to compare SQL with other products - don't. There are very few products that come to mind that have the same level of complexity that SQL Server does. Again, this is not an excuse for any particular bug that remains in setup. The complexity of SQL Server has grown tremendously from SQL Server 7.0. The setup has had to embrace the increased complexity and deliver a stable and consistent experience. I believe this was achieved.

Cheers,
Dan

|||

Dan:

This is critical tidbit that surely belongs in Embedding SQL Server Express in Custom Applications. That's a 32-page article (from November 2005) at the Microsoft SQL Server Developer Centre, and while it obviously spends time on template.ini, it doesn't tell you how to find it. Luckily for me, I found your reply on this forum.

Please pass this on to Robert Walters, who wrote the article.

Regards
Josh Korn

Location of default instance SQL server 2005 files

I have just installed SQL Server 2005. I was not given a choice during installation (that I remember seeing anyway) about which drive I wanted to place the default SQL instance on.

It ended up on C: and I needed it on D:.

So my questions are:

    Is there a way to move it to D: that is easier than the way you had to go about it in SQL 2000? Is there a way to do it during setup so I can avoid this in the future?
Please refere to a previous posting called "How to specify default data location? " .. which talks about the exact place to change it.|||

There is a file called template.ini located at the same folder as setup.exe. In this file, all related command line parameters are discussed when SQL Server 2005 is installed under unattended mode, i.e., command line. You can specify paths to install SQL Server 2005 components.

Under attended mode, i.e., GUI mode, during selecting components to install, clicking the Advanced button will prompt to change paths to install SQL Server 2005 components.

|||

Jiongxiong,

There is no file "template.ini" with the SQL setup program (cd or installed location).

The SQL readme points to a generic windows deployment info page - which is unhelpful.

|||

If you're installing SQL Server Express edition you are running an executable called SQLEXPR.EXE. This is a compressed package that when run expands the contents to a temporary folder, runs the installation and then deletes the temporary folder. You can persist the uncompressed contents by running sqlexpr.exe /x - this will prompt you for a folder to save the uncompressed files. Once uncompressed you'll find the template.ini file in this folder (same folder as setup.exe). The parameters that can be passed to setup.exe can also be passed to sqlexpr.exe - the compression tool will pass the parameters to setup.exe when it runs it.

If you're installing an edition other than Express you will find template.ini in the same folder as setup.exe.

Cheers,
Dan

|||

Jiongxiong, you are right! Sorry, I missed the template.ini file somehow. I will see if it works for my clean install tests.

It is simply amazing that M$ can not do simple file management for installation. There are files, they have versions, they need to be copied to a folder from the CD, and some settings stored - how complicated is that? Well if you are M$ you make SQL05 installation into a mass of gobble-gook. SQL Server 05 is not ready for production use until its installation abomination is fixed!

|||

Most people think that SQL Server setup is just about copying files and writing some reg keys. While it's true it's only a small fraction of what setup does. Here is a small sampling of the other things SQL Server setup does.

SQL Server setup checks the configuration of the machine to determine if the machine is in a valid state - which improves the chances of a good installation. Windows Installer doesn't support this.

SQL Server is a multi-instance product. Windows Installer doesn't support this.

SQL Server requires configuration to happen as part of the setup process. Windows Installer doesn't support this. If you've ever performed a MySQL installation a separate tool is launched post setup to do the configuration - although at the end of setup you don't have a working server.

SQL Server cluster install is extremely robust. Every other product I've seen requires you to rerun setup on every node and make sure the configurations are the same. SQL does this for you. Windows Installer doesn't support cluster installs.

SQL Server requires a secure installation. This means that every file/directory/service/reg key is ACL'd to the appropriate service account. Windows Installer doesn't support this.

SQL Server setup supports version and edition upgrade. Windows Installer doesn't support this.

Windows Installer handles very well the copying of files and the writing of reg keys, but it doesn't handle any of the other complexities associated with SQL Server setup. Everywhere I mentioned that Windows Installer doesn't support something it means we've had to build it. I'm not using this as an excuse, but merely highlighting the fact that setup is much more than just copying files and writing reg keys. Anyone who's worked on the setup of a complex product (such as SQL or Visual Studio) will attest to this.

Is our setup perfect? No. But I certainly don't believe it deserves the criticism. There are millions of ways a user can hose their machine and it would be impossible for us to test for every single case. I'm sure you'll be tempted to compare SQL with other products - don't. There are very few products that come to mind that have the same level of complexity that SQL Server does. Again, this is not an excuse for any particular bug that remains in setup. The complexity of SQL Server has grown tremendously from SQL Server 7.0. The setup has had to embrace the increased complexity and deliver a stable and consistent experience. I believe this was achieved.

Cheers,
Dan

|||

Dan:

This is critical tidbit that surely belongs in Embedding SQL Server Express in Custom Applications. That's a 32-page article (from November 2005) at the Microsoft SQL Server Developer Centre, and while it obviously spends time on template.ini, it doesn't tell you how to find it. Luckily for me, I found your reply on this forum.

Please pass this on to Robert Walters, who wrote the article.

Regards
Josh Korn

Location of default instance SQL server 2005 files

I have just installed SQL Server 2005. I was not given a choice during installation (that I remember seeing anyway) about which drive I wanted to place the default SQL instance on.

It ended up on C: and I needed it on D:.

So my questions are:

    Is there a way to move it to D: that is easier than the way you had to go about it in SQL 2000? Is there a way to do it during setup so I can avoid this in the future?
Please refere to a previous posting called "How to specify default data location? " .. which talks about the exact place to change it.|||

There is a file called template.ini located at the same folder as setup.exe. In this file, all related command line parameters are discussed when SQL Server 2005 is installed under unattended mode, i.e., command line. You can specify paths to install SQL Server 2005 components.

Under attended mode, i.e., GUI mode, during selecting components to install, clicking the Advanced button will prompt to change paths to install SQL Server 2005 components.

|||

Jiongxiong,

There is no file "template.ini" with the SQL setup program (cd or installed location).

The SQL readme points to a generic windows deployment info page - which is unhelpful.

|||

If you're installing SQL Server Express edition you are running an executable called SQLEXPR.EXE. This is a compressed package that when run expands the contents to a temporary folder, runs the installation and then deletes the temporary folder. You can persist the uncompressed contents by running sqlexpr.exe /x - this will prompt you for a folder to save the uncompressed files. Once uncompressed you'll find the template.ini file in this folder (same folder as setup.exe). The parameters that can be passed to setup.exe can also be passed to sqlexpr.exe - the compression tool will pass the parameters to setup.exe when it runs it.

If you're installing an edition other than Express you will find template.ini in the same folder as setup.exe.

Cheers,
Dan

|||

Jiongxiong, you are right! Sorry, I missed the template.ini file somehow. I will see if it works for my clean install tests.

It is simply amazing that M$ can not do simple file management for installation. There are files, they have versions, they need to be copied to a folder from the CD, and some settings stored - how complicated is that? Well if you are M$ you make SQL05 installation into a mass of gobble-gook. SQL Server 05 is not ready for production use until its installation abomination is fixed!

|||

Most people think that SQL Server setup is just about copying files and writing some reg keys. While it's true it's only a small fraction of what setup does. Here is a small sampling of the other things SQL Server setup does.

SQL Server setup checks the configuration of the machine to determine if the machine is in a valid state - which improves the chances of a good installation. Windows Installer doesn't support this.

SQL Server is a multi-instance product. Windows Installer doesn't support this.

SQL Server requires configuration to happen as part of the setup process. Windows Installer doesn't support this. If you've ever performed a MySQL installation a separate tool is launched post setup to do the configuration - although at the end of setup you don't have a working server.

SQL Server cluster install is extremely robust. Every other product I've seen requires you to rerun setup on every node and make sure the configurations are the same. SQL does this for you. Windows Installer doesn't support cluster installs.

SQL Server requires a secure installation. This means that every file/directory/service/reg key is ACL'd to the appropriate service account. Windows Installer doesn't support this.

SQL Server setup supports version and edition upgrade. Windows Installer doesn't support this.

Windows Installer handles very well the copying of files and the writing of reg keys, but it doesn't handle any of the other complexities associated with SQL Server setup. Everywhere I mentioned that Windows Installer doesn't support something it means we've had to build it. I'm not using this as an excuse, but merely highlighting the fact that setup is much more than just copying files and writing reg keys. Anyone who's worked on the setup of a complex product (such as SQL or Visual Studio) will attest to this.

Is our setup perfect? No. But I certainly don't believe it deserves the criticism. There are millions of ways a user can hose their machine and it would be impossible for us to test for every single case. I'm sure you'll be tempted to compare SQL with other products - don't. There are very few products that come to mind that have the same level of complexity that SQL Server does. Again, this is not an excuse for any particular bug that remains in setup. The complexity of SQL Server has grown tremendously from SQL Server 7.0. The setup has had to embrace the increased complexity and deliver a stable and consistent experience. I believe this was achieved.

Cheers,
Dan

|||

Dan:

This is critical tidbit that surely belongs in Embedding SQL Server Express in Custom Applications. That's a 32-page article (from November 2005) at the Microsoft SQL Server Developer Centre, and while it obviously spends time on template.ini, it doesn't tell you how to find it. Luckily for me, I found your reply on this forum.

Please pass this on to Robert Walters, who wrote the article.

Regards
Josh Korn

sql

Location of Data Files

I have installed SQL Server 2000 with Master / Model /
MSDB databases in C Drive.
Since the size of C Drive is not sufficient, is it
possible for me to restore a database backup from another
SQL Server to D:\MSSQL\Data ?
ThanksThis article may help you
http://support.microsoft.com/?kbid=224071
--
--
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
"Roger Lee" <rogerlee@.nospam.com> wrote in message
news:06b101c36553$fd1b6db0$a101280a@.phx.gbl...
> I have installed SQL Server 2000 with Master / Model /
> MSDB databases in C Drive.
> Since the size of C Drive is not sufficient, is it
> possible for me to restore a database backup from another
> SQL Server to D:\MSSQL\Data ?
> Thankssql

Monday, March 19, 2012

Location for audit logs?

Hi,
I saw in this or the SQL Server Security news group that it's recommended to
store auditing logs on an unused disk drive because auditing logs could grow
wildly. But based on this article
http://www.microsoft.com/technet/security/prodtech/sqlserver/sql2kaud.mspx,
SQL Server doesn't let you log auditable events to an alternative location.
<QUOTE>After you enable C2 auditing for the default database or for an
instance, the database server will log all activity to the data directory
that you specified during the installation process. (SQL Server doesn't let
you log auditable events to an alternative location.) This directory holds
the databases that SQL Server initially created. This directory is also the
default location for all new databases and their transaction log
files.</QUOTE>
Now I'm confused. I have data/transaction logs on one drive, I'm planning
to add additional disk drive specifically for auditing. Is it possible to
direct auditing logs to the new drive?
Thanks,
Bing
Hi Bing
"bing" wrote:

> Hi,
> I saw in this or the SQL Server Security news group that it's recommended to
> store auditing logs on an unused disk drive because auditing logs could grow
> wildly. But based on this article
> http://www.microsoft.com/technet/security/prodtech/sqlserver/sql2kaud.mspx,
> SQL Server doesn't let you log auditable events to an alternative location.
>
> <QUOTE>After you enable C2 auditing for the default database or for an
> instance, the database server will log all activity to the data directory
> that you specified during the installation process. (SQL Server doesn't let
> you log auditable events to an alternative location.) This directory holds
> the databases that SQL Server initially created. This directory is also the
> default location for all new databases and their transaction log
> files.</QUOTE>
> Now I'm confused. I have data/transaction logs on one drive, I'm planning
> to add additional disk drive specifically for auditing. Is it possible to
> direct auditing logs to the new drive?
> Thanks,
> Bing
If you change the default data and log directories in the Database
properties task in Enterprise Manager on the properties page of the instance
(right click) do new audit files get created their (you may need to restart)?
If not you can move the databases away from this location using
sp_detach_db/sp_attach_db or backup/restore see
http://support.microsoft.com/kb/314546. When you do the initial install, the
default location is the system disc e.g. C:\Program Files\Microsoft SQL
Server... this should be changed as filling up the system disc with audit
logs will make the system unusable.
You can move system databases (possibly to different spindles!) as well as
user databases http://support.microsoft.com/kb/224071/ and using different
discs for full text catalogs will also be a way of improving performance
http://support.microsoft.com/kb/240867/ Database data files and log files
should be on separate drive arrays as they perform different types of I/O
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
You should also consider what RAID level and resilience you require for
these disc subsystems.
John

Location for audit logs?

Hi,
I saw in this or the SQL Server Security news group that it's recommended to
store auditing logs on an unused disk drive because auditing logs could grow
wildly. But based on this article
http://www.microsoft.com/technet/security/prodtech/sqlserver/sql2kaud.mspx,
SQL Server doesn't let you log auditable events to an alternative location.
<QUOTE>After you enable C2 auditing for the default database or for an
instance, the database server will log all activity to the data directory
that you specified during the installation process. (SQL Server doesn't let
you log auditable events to an alternative location.) This directory holds
the databases that SQL Server initially created. This directory is also the
default location for all new databases and their transaction log
files.</QUOTE>
Now I'm confused. I have data/transaction logs on one drive, I'm planning
to add additional disk drive specifically for auditing. Is it possible to
direct auditing logs to the new drive?
Thanks,
BingHi Bing
"bing" wrote:
> Hi,
> I saw in this or the SQL Server Security news group that it's recommended to
> store auditing logs on an unused disk drive because auditing logs could grow
> wildly. But based on this article
> http://www.microsoft.com/technet/security/prodtech/sqlserver/sql2kaud.mspx,
> SQL Server doesn't let you log auditable events to an alternative location.
>
> <QUOTE>After you enable C2 auditing for the default database or for an
> instance, the database server will log all activity to the data directory
> that you specified during the installation process. (SQL Server doesn't let
> you log auditable events to an alternative location.) This directory holds
> the databases that SQL Server initially created. This directory is also the
> default location for all new databases and their transaction log
> files.</QUOTE>
> Now I'm confused. I have data/transaction logs on one drive, I'm planning
> to add additional disk drive specifically for auditing. Is it possible to
> direct auditing logs to the new drive?
> Thanks,
> Bing
If you change the default data and log directories in the Database
properties task in Enterprise Manager on the properties page of the instance
(right click) do new audit files get created their (you may need to restart)?
If not you can move the databases away from this location using
sp_detach_db/sp_attach_db or backup/restore see
http://support.microsoft.com/kb/314546. When you do the initial install, the
default location is the system disc e.g. C:\Program Files\Microsoft SQL
Server... this should be changed as filling up the system disc with audit
logs will make the system unusable.
You can move system databases (possibly to different spindles!) as well as
user databases http://support.microsoft.com/kb/224071/ and using different
discs for full text catalogs will also be a way of improving performance
http://support.microsoft.com/kb/240867/ Database data files and log files
should be on separate drive arrays as they perform different types of I/O
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
You should also consider what RAID level and resilience you require for
these disc subsystems.
John

Location for audit logs?

Hi,
I saw in this or the SQL Server Security news group that it's recommended to
store auditing logs on an unused disk drive because auditing logs could grow
wildly. But based on this article
http://www.microsoft.com/technet/se.../sql2kaud.mspx,
SQL Server doesn't let you log auditable events to an alternative location.
<QUOTE>After you enable C2 auditing for the default database or for an
instance, the database server will log all activity to the data directory
that you specified during the installation process. (SQL Server doesn't let
you log auditable events to an alternative location.) This directory holds
the databases that SQL Server initially created. This directory is also the
default location for all new databases and their transaction log
files.</QUOTE>
Now I'm confused. I have data/transaction logs on one drive, I'm planning
to add additional disk drive specifically for auditing. Is it possible to
direct auditing logs to the new drive?
Thanks,
BingHi Bing
"bing" wrote:

> Hi,
> I saw in this or the SQL Server Security news group that it's recommended
to
> store auditing logs on an unused disk drive because auditing logs could gr
ow
> wildly. But based on this article
> If you change the default data and log directories in the Databaseproperties task in Enterprise Manager on the properties page of the instance(right click) do new audit files get created their (you may need to restart)?If not you can move the databases away from this location usingsp_detach_db/sp_attach_db or backup/restore see[url]http://support.microsoft.com/kb/314546." target="_blank">http://www.microsoft.com/technet/se...com/kb/314546. When you do the initial install, the
default location is the system disc e.g. C:\Program Files\Microsoft SQL
Server... this should be changed as filling up the system disc with audit
logs will make the system unusable.
You can move system databases (possibly to different spindles!) as well as
user databases http://support.microsoft.com/kb/224071/ and using different
discs for full text catalogs will also be a way of improving performance
http://support.microsoft.com/kb/240867/ Database data files and log files
should be on separate drive arrays as they perform different types of I/O
[url]http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx[/u
rl]
You should also consider what RAID level and resilience you require for
these disc subsystems.
John

Friday, February 24, 2012

Local drive doesn't appear more !

Hi,
I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
partitions (C, D, E). This happened unexpectedly when I was deleting a
database.
I can see normally the letter E in windows explorer, but it doesn't appear
and permit me more create a database em that letter.
Any idea ?
Regards,
Vitor Mauricio
Check file permissions to ensure the SQL Server service account has full
permissions to the root folder.
Hope this helps.
Dan Guzman
SQL Server MVP
"Vitor Mauricio de N. Silva" <vitor_mauricio@.hotmail.com> wrote in message
news:e4yjo36ZEHA.3112@.tk2msftngp13.phx.gbl...
> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>
|||Vitor,
Adding to Dan's post, deleting a database would not have done anything
to your partitions, or your file system security settings. This would
have been a separate operation.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Dan Guzman wrote:
> Check file permissions to ensure the SQL Server service account has full
> permissions to the root folder.
>
|||Check event viewer for any information on this behaviour.
--
Satya SKJ
"Vitor Mauricio de N. Silva" wrote:

> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>
>
|||All,
I check the file permission and everything is ok. In the event viewer I
cant see any error.
I never see this before, but the problems continue.
Thanks in advance for any suggestions,
Vitor Mauricio
"Vitor Mauricio de N. Silva" <vitor_mauricio@.hotmail.com> wrote in message
news:e4yjo36ZEHA.3112@.tk2msftngp13.phx.gbl...
> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>

Local drive doesn't appear more !

Hi,
I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
partitions (C, D, E). This happened unexpectedly when I was deleting a
database.
I can see normally the letter E in windows explorer, but it doesn't appear
and permit me more create a database em that letter.
Any idea ?
Regards,
Vitor MauricioCheck file permissions to ensure the SQL Server service account has full
permissions to the root folder.
Hope this helps.
Dan Guzman
SQL Server MVP
"Vitor Mauricio de N. Silva" <vitor_mauricio@.hotmail.com> wrote in message
news:e4yjo36ZEHA.3112@.tk2msftngp13.phx.gbl...
> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>|||Vitor,
Adding to Dan's post, deleting a database would not have done anything
to your partitions, or your file system security settings. This would
have been a separate operation.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Dan Guzman wrote:
> Check file permissions to ensure the SQL Server service account has full
> permissions to the root folder.
>|||Check event viewer for any information on this behaviour.
--
--
Satya SKJ
"Vitor Mauricio de N. Silva" wrote:

> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>
>|||All,
I check the file permission and everything is ok. In the event viewer I
cant see any error.
I never see this before, but the problems continue.
Thanks in advance for any suggestions,
Vitor Mauricio
"Vitor Mauricio de N. Silva" <vitor_mauricio@.hotmail.com> wrote in message
news:e4yjo36ZEHA.3112@.tk2msftngp13.phx.gbl...
> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>

Local drive doesn't appear more !

Hi,
I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
partitions (C, D, E). This happened unexpectedly when I was deleting a
database.
I can see normally the letter E in windows explorer, but it doesn't appear
and permit me more create a database em that letter.
Any idea ?
Regards,
Vitor MauricioCheck file permissions to ensure the SQL Server service account has full
permissions to the root folder.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Vitor Mauricio de N. Silva" <vitor_mauricio@.hotmail.com> wrote in message
news:e4yjo36ZEHA.3112@.tk2msftngp13.phx.gbl...
> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>|||Vitor,
Adding to Dan's post, deleting a database would not have done anything
to your partitions, or your file system security settings. This would
have been a separate operation.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Dan Guzman wrote:
> Check file permissions to ensure the SQL Server service account has full
> permissions to the root folder.
>|||All,
I check the file permission and everything is ok. In the event viewer I
can´t see any error.
I never see this before, but the problems continue.
Thanks in advance for any suggestions,
Vitor Mauricio
"Vitor Mauricio de N. Silva" <vitor_mauricio@.hotmail.com> wrote in message
news:e4yjo36ZEHA.3112@.tk2msftngp13.phx.gbl...
> Hi,
> I have a SQL Server 7.0 (SP4) with 1 phisical disk drive and 3 logical
> partitions (C, D, E). This happened unexpectedly when I was deleting a
> database.
> I can see normally the letter E in windows explorer, but it doesn't appear
> and permit me more create a database em that letter.
> Any idea ?
> Regards,
> Vitor Mauricio
>