log files

there is controversial topic in my dept. If we put log files of databases on
different mirrored drive we will improve the performance.
Is that true for system dbs too. What are your reccomendations, guys?
In my oppinion sys db should be secured on different mirrored drive with sql
executables.Eli Milkova wrote:
> there is controversial topic in my dept. If we put log files of
> databases on different mirrored drive we will improve the performance.
> Is that true for system dbs too. What are your reccomendations, guys?
> In my oppinion sys db should be secured on different mirrored drive
> with sql executables.
If by system database you mean tempdb, then the answer is yes. Ideally,
tempdb should be on an array with fast sequential write access (RAID 1
or RAID 10). If you're talking about master, model, and msdb, then the
answer is probably no. You can keep those databases on the array that
holds the rest of the DBs since are generally small and are accessed and
changed with less frequency that user databases. I would not generally
recommend they are on placed the OS array. The OS array is best for the
OS and applications, not database files.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com

log files

there is controversial topic in my dept. If we put log files of databases o
n
different mirrored drive we will improve the performance.
Is that true for system dbs too. What are your reccomendations, guys?
In my oppinion sys db should be secured on different mirrored drive with sql
executables.Eli Milkova wrote:
> there is controversial topic in my dept. If we put log files of
> databases on different mirrored drive we will improve the performance.
> Is that true for system dbs too. What are your reccomendations, guys?
> In my oppinion sys db should be secured on different mirrored drive
> with sql executables.
If by system database you mean tempdb, then the answer is yes. Ideally,
tempdb should be on an array with fast sequential write access (RAID 1
or RAID 10). If you're talking about master, model, and msdb, then the
answer is probably no. You can keep those databases on the array that
holds the rest of the DBs since are generally small and are accessed and
changed with less frequency that user databases. I would not generally
recommend they are on placed the OS array. The OS array is best for the
OS and applications, not database files.
David Gugick
Quest Software
www.imceda.com
www.quest.com

log files

there is controversial topic in my dept. If we put log files of databases on
different mirrored drive we will improve the performance.
Is that true for system dbs too. What are your reccomendations, guys?
In my oppinion sys db should be secured on different mirrored drive with sql
executables.
Eli Milkova wrote:
> there is controversial topic in my dept. If we put log files of
> databases on different mirrored drive we will improve the performance.
> Is that true for system dbs too. What are your reccomendations, guys?
> In my oppinion sys db should be secured on different mirrored drive
> with sql executables.
If by system database you mean tempdb, then the answer is yes. Ideally,
tempdb should be on an array with fast sequential write access (RAID 1
or RAID 10). If you're talking about master, model, and msdb, then the
answer is probably no. You can keep those databases on the array that
holds the rest of the DBs since are generally small and are accessed and
changed with less frequency that user databases. I would not generally
recommend they are on placed the OS array. The OS array is best for the
OS and applications, not database files.
David Gugick
Quest Software
www.imceda.com
www.quest.com

Log All SA events

Hello,
I have a person in my IT dept. that I suspect is using the SA account for a
SQL server that holds employee information(salary, etc.) that she should not
be accessing it. Is there a way that I can track where the Actual SA account
is coming from by IP address or machine name? I know I could change the SA
password, but we are not at a stage right now to do this.
Please advise?
KevHello,
SQL 2000:-
Query the MASTER..SYSPROCESSES and log it into a table frequently and look
into the hostname column.
SQL 2005
Query the system view sys.sysprocesses and log it into a table frequently
and look into the hostname column.
Thanks
Hari
"Kev" <Kev@.discussions.microsoft.com> wrote in message
news:0E274494-A8C6-4A48-AF72-1BD37FEF5336@.microsoft.com...
> Hello,
> I have a person in my IT dept. that I suspect is using the SA account for
> a
> SQL server that holds employee information(salary, etc.) that she should
> not
> be accessing it. Is there a way that I can track where the Actual SA
> account
> is coming from by IP address or machine name? I know I could change the SA
> password, but we are not at a stage right now to do this.
> Please advise?
> Kev|||What version of SQL Server? It really depends on what
version of SQL Server. At the very least on any version, you
could use a trace, filter on the Login Name sa and make sure
to capture the Host name. You may pick up the host computer
where the sa login is being used.
-Sue
On Wed, 28 Mar 2007 07:50:02 -0700, Kev
<Kev@.discussions.microsoft.com> wrote:

>Hello,
>I have a person in my IT dept. that I suspect is using the SA account for a
>SQL server that holds employee information(salary, etc.) that she should no
t
>be accessing it. Is there a way that I can track where the Actual SA accoun
t
>is coming from by IP address or machine name? I know I could change the SA
>password, but we are not at a stage right now to do this.
>Please advise?
>Kev|||It is SQL 2000. I have done some tracing and found the host name column and
found what I was looking for. Thanks for your response!
"Sue Hoegemeier" wrote:

> What version of SQL Server? It really depends on what
> version of SQL Server. At the very least on any version, you
> could use a trace, filter on the Login Name sa and make sure
> to capture the Host name. You may pick up the host computer
> where the sa login is being used.
> -Sue
> On Wed, 28 Mar 2007 07:50:02 -0700, Kev
> <Kev@.discussions.microsoft.com> wrote:
>
>