Best Practices?

Hi,

I am installing SQL 2005 in a cluster env and there is a section which asks you about the domina\group for each of the accounts. I am going to have 3 virtual server so does it mean I should have 3*3 structure.

Can anyone tell me what exactly the group does and can there be 3 groups with 9 accounts.

What is the best practices
Thanks

I would just create one Windows Group with three different user accounts, then use one account for all of the services on each instance.

Best Practices?

Hi,

I am installing SQL 2005 in a cluster env and there is a section which asks you about the domina\group for each of the accounts. I am going to have 3 virtual server so does it mean I should have 3*3 structure.

Can anyone tell me what exactly the group does and can there be 3 groups with 9 accounts.

What is the best practices
Thanks

I would just create one Windows Group with three different user accounts, then use one account for all of the services on each instance.

Best Practice for SQL Server security

Our database section is relatively new. The SQL Servers were setup
before our creation and the security is our first area of concern.
Currently, there is a .NET 1.1 COM layer that handles all database
access. It is using a single NT domain account with read/write to all
the databases and execute on the user stored procedures. From what I'm
told, all the business rules for applications (mostly web apps) are
handled in the COM layer.
Our section feels that this is not a secured model from a database
perspective. We want each application to have a unique login to SQL.
Each application would have read/write/execute on its main database as
it does currently, however data access to other databases would be
tightly controlled by the allowing only enough privileges to accomplish
the business objective.
We are hitting massive battles from a small section of our
application developers who insist that the current model is most
secure. Our stance is that we don't trust the middle tier because of
the amount of human coding involved and the lack of auditability on
database security. They have proposed a solution where each COM object
has it's own unique ID, but any application can call any COM object
with read/write/execute in any database - this is not acceptable to us.
My question is - what is the best practice? What are you doing for
security with a "trusted" middle-tier.Hi
http://vyaskn.tripod.com/sql_server...t_practices.htm --sec
urity
best practices
"PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
news:1165926885.850901.28250@.n67g2000cwd.googlegroups.com...
> Our database section is relatively new. The SQL Servers were setup
> before our creation and the security is our first area of concern.
> Currently, there is a .NET 1.1 COM layer that handles all database
> access. It is using a single NT domain account with read/write to all
> the databases and execute on the user stored procedures. From what I'm
> told, all the business rules for applications (mostly web apps) are
> handled in the COM layer.
> Our section feels that this is not a secured model from a database
> perspective. We want each application to have a unique login to SQL.
> Each application would have read/write/execute on its main database as
> it does currently, however data access to other databases would be
> tightly controlled by the allowing only enough privileges to accomplish
> the business objective.
> We are hitting massive battles from a small section of our
> application developers who insist that the current model is most
> secure. Our stance is that we don't trust the middle tier because of
> the amount of human coding involved and the lack of auditability on
> database security. They have proposed a solution where each COM object
> has it's own unique ID, but any application can call any COM object
> with read/write/execute in any database - this is not acceptable to us.
> My question is - what is the best practice? What are you doing for
> security with a "trusted" middle-tier.
>|||Thanks, that document helps. I think I'm more looking for an overall
approach to security. Are there other DBAs out there that are fully
trusting the COM objects? I confess I don't know much about COM, but
I feel really uneasy about allowing an object out of our control the
access that it has.
Even in their updated model (each COM has it's own Login) we still
wouldn't know if application A is using database A, database B,
database C, etc.. and which tables in those other databases.
I need ammo to go to our next meeting and show them how this isn't
secure from our perspective. We also have SQL Log Rescue, so we have
the ability to scour the logs for info - but we can't tell who is doing
what because it all shows that it's the COM account accessing the db.
Uri Dimant wrote:[vbcol=seagreen]
> Hi
> http://vyaskn.tripod.com/sql_server...t_practices.htm --s
ecurity
> best practices
>
>
>
>
> "PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
> news:1165926885.850901.28250@.n67g2000cwd.googlegroups.com...|||Wow. I had the exact discussion recently and would be very interested to
see other opinions and info on this also.
J
"PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
news:1165934077.707745.266260@.79g2000cws.googlegroups.com...
> Thanks, that document helps. I think I'm more looking for an overall
> approach to security. Are there other DBAs out there that are fully
> trusting the COM objects? I confess I don't know much about COM, but
> I feel really uneasy about allowing an object out of our control the
> access that it has.
> Even in their updated model (each COM has it's own Login) we still
> wouldn't know if application A is using database A, database B,
> database C, etc.. and which tables in those other databases.
> I need ammo to go to our next meeting and show them how this isn't
> secure from our perspective. We also have SQL Log Rescue, so we have
> the ability to scour the logs for info - but we can't tell who is doing
> what because it all shows that it's the COM account accessing the db.
> Uri Dimant wrote:
>|||No one has really weighed in, I'm surprised.
J wrote:[vbcol=seagreen]
> Wow. I had the exact discussion recently and would be very interested to
> see other opinions and info on this also.
> J
> "PSPDBA" <DissendiumDBA@.gmail.com> wrote in message
> news:1165934077.707745.266260@.79g2000cws.googlegroups.com...

Benchmarking Database Performance

First of all, sorry if this is in the wrong section, didn't know where to put it.

I'm doing a university paper comparing Microsoft Access versus SQL Server 2000 and I want to run a benchmark on them to see which is faster, does anyone know of any applications that will let me do this?

You may think this is silly since SQL Server is quite obviously faster, thing is a can't just say that in my paper, I have to be more specific so was hoping I could run some benchmarks and show the scores on the paper.

I know I can run an ASP script that can time how long the query takes to run, however this can't test multiple concurrent users accessing the system (useless I get all my friends computers around my house, bring up the page and get them to click on refresh all at the same time :) ).

I basically want to run a simple SQL SELECT statement on an identical database in both database systems (Northwind), but for mutliple users. Anyone know of any application?

Or does anyone know any performance tests that has been done on comparing Access with SQL Server? All I can find is material comparing high-end database against high-end database (Oracle vs SQL Server vs IBM DB2 etc.). If I can't do my own I can always use other peoples. Cheers!From the book "SQL Server Resource Kit", the CD that comes with the book contains a utility named "Database Hammer". The utility creates it's own database on SQL Server and performs a lot of transactions to test performance. It is most useful for comparing Server A to Server B, both running SQL Server.

Here's a link:

http://www.winnetmag.com/Article/ArticleID/26083/26083.html

Of course, this utility will not work against an Access database, but it should give you some ideas. Hope this helps...|||After some hunting around I found Quest Software's Benchmark Factory that seems to do the job really well. SQL Server 2000 handles about 21 transactions per second with 5 concurrent users, Access can only manage about 11. Does this seem right? This was from running a fairly complex SQL SELECT statement, performing mutliple inner joins on many tables in the Northwind sample database.

Would performing actual transactions on the Northwind database (INSERTs, UPDATEs etc) show bigger performance differences between Access and SQL Server?

Also does anyone have any experience with using Benchmark Factory? How do test more than 5 concurrent users? It only seems to let me select upto five, but the help files seem to indicate that you can test with as many as 100s of users.

Thanks for any help! :)|||From the book "SQL Server Resource Kit", the CD that comes with the book contains a utility named "Database Hammer". The utility creates it's own database on SQL Server and performs a lot of transactions to test performance. It is most useful for comparing Server A to Server B, both running SQL Server.

Here's a link:

http://www.winnetmag.com/Article/ArticleID/26083/26083.html

Of course, this utility will not work against an Access database, but it should give you some ideas. Hope this helps...

Thanks for the help, although my paper is on comparing Access and SQL Server, I'm building a system next year that uses an SQL Server backend database that handles tens thousands of records, and that utility will certainly help me with some optimisations.