I'm a beginner. How many number of tables are recommended in a SQL Server Express database? Mainly attaining best performance speedwise as an objective. Is it generally recommend to use two databases as compared to one for a single application?
SQL Express databases have a limit of 4GB in size. Within that limit, any number of tables is fair game. The number of tables makes absolutely no impact on performance. The only thing that drives performance of the application vis-a-vis the database is the proper design of the tables, both as logical model and as physical database structure (ie. correct choices of clustered indexes, non-clustered indexes, constraints, defaults, data types etc), and the proper querying and updating of the database ie. queries that can be satisfied (covered, efficiently) by the existing indexes.
Splitting an application database into multiple distinct databases is a bad idea. You are loosing consistency of the recovery unit (you can't backup/restore the two databases in a consistent state) and you need to replicate all the infrastructure around the database twice (security roles and permissions, maintenance activities and procedures etc). Also spliting an application database into distinct databases gaves absolutely no performance advantage.
What you can do to make things speedier:
-break up your databases so that they use multiple files across multiple, fast drives
-federate (not really something you'll do if you're running Express)
-Install memory, memory, memory
-I can't remember Express's limitations and I don't care to look them up, but on the configuration screen where you can assign the number of CPUs to dedicate to SQL, give it as many as you can. You should also be able to set affinity there (if not, then in Task Manager)
Don't run anything you don't need (scheduler, report engine, Server, DHCP Client) if you don't have to
Related
I've been reading through the excellent Developing Multi-tenant Applications for the Cloud, 3rd Edition and am trying to understand how partitioning impacts on query performance in Windows Azure SQL Database.
If you use the shared schema approach and put all tenants records in a single table and separate their data using partitions, is that always going to be slower than a separate schema approach due to the larger number of records in the table, or does the partitioning effectively make each partition act like its own table?
(I appreciate query execution speed is only one of many factors to consider when choosing a multi tenancy strategy, we're not basing our decisions on performance alone.)
The approach that uses different schemas for different tenants has its problems, too. For instance, it is very easy to bloat the plan cache with this approach since each tenant gets its own set of query plans. You may end up with more recompiles (and lower performance) with this approach because of that.
I would recommend to take a look at an approach where you place each tenant in its own database. That provides for great isolation and, in combination with Elastic Database Pools in Azure SQL DB, it actually becomes quite affordable. A good entry point into the documentation is this: https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-introduction/.
One of our customer is in manufacturing domain. He has multiple factories across the country. For the quality control, he is using window application deployed independently in all factories (approx 100 in count). Our customer is interested in replacing all the window applications with a single web application. Now the problem is volume of the data will be 100 times bigger and same as the velocity (in case we keep a single database for all the factories). There are lots of reporting use cases in this domain. Looking at the numbers, it looks like SQL will be not be able to handle this much load.
Is it a valid use case to move to NoSQL database?
Can Volume/Velocity alone be a deciding factor to move to NoSQL?
Would we be able to get all those reporting from NoSQL database efficiently?
Any kind of help will be appreciated.
Thanks In Advance
This is a usefull discussion.
In my opinion a well designed MS-SQL server 2012 (or Oracle server, but no experience for me) must be capable of handling 1000 complex transactions per second.
MS-SQL server 2014 with in-memory processing raises even higher expecations.
Consider multi processor, large memories, table partitioning, file mapping, multiple access paths to the SAN or to separate server discs. Use well designed transactions (consider to remove most indexes on transaction tables).
As an extra benefit you keep all functionality of the SQL server. In my opinion most NOSQL solutions are NOSQL because they are deprived of essential SQL functionality.
Switch to NOSQL databases is most usefull when you require functionality outside the transaction domain, e.g. document indexing or network indexing.
I want to make sure the stress to the server is minimal while running queries from a read only schema (a user can select data and create temp tables and variables, but can't execute SPs, write and other more advanced stuff). What db hints/other tricks could I use in this situation?
Currently I am:
Using the WITH (NOLOCK) hint for every table
Setting the DEADLOCK_PRIORITY for the whole batch to -10 (although I am not sure it's really needed, since I am using NOLOCK)
My goals is to take as little server resources as possible and allow other more important things to be processed by the server freely. The queries that I am going to send to the server are local (can't be saved as SPs) and there will be many of them coming from various users every 5 minutes. They are generally simple SELECTs and are cheap in isolation. Are there any other ways to make them even less expensive?
EDIT:
I am not the owner of the server I am connecting to, so I can only use the SQL query I am passing to the server to achieve what I want.
The two measures you have taken will have little impact. They are mostly used out of superstitiousness. They can have an impact in rare cases. Practically, READ UNCOMMITTED (which is 100% identical to NOLOCK) enables allocation order scans on B-trees. That is only important for tables that are not in-memory anyway.
If you want to minimize locking and blocking, snapshot isolation can be a simple and very effective solution.
In order to truly minimize the impact of a certain workload you need to use Resource Governor. Everything else are partial solutions/workarounds.
Consider limiting CPU usage, memory, IO and parallelism.
With Microsoft SQL Server 2005, is it possible to combine the processing power of multiple physical servers into a single logical sql server? Is it possible on SQL Server 2008?
I'm thinking, if the database files were located on a SAN and somehow one of the sql servers acted as a kind of master, then processing could be spread out over multiple physical servers, for instance even allowing simultaneous updates where there was no overlap, and in the case of read-only queries on unlocked tables no limit.
We have an application that is limited by the speed of our sql server, and probably stuck with server 2005 for now. Is the only option to get a single more powerful physical server?
Sorry I'm not an expert, I'm not sure if the question is a stupid one.
TIA
Before rushing out and buying new hardware, find out where your bottlenecks really are. Many locking problems can be solved with the appropriate indexes for your workload.
For example, I've seen instances where placing tempDB on SSD solved performance issues and saved the client buying an expensive new server.
Analyse your workload: How Can I Log and Find the Most Expensive Queries?
With SQL Server 2008 you can utilise the Management Data Warehouse (MDW) to capture your workload.
White Paper: SQL Server 2008 Performance and Scale
Also: please be aware that a SAN solution is not necessarily a faster I/O solution than directly attached storage. It depends on the SAN, number of Physical disks in a LUN, LUN subscription and usage, the speed of the HBA's and several other hardware factors...
Optimizing the app may be a big job of going through all business logic and lines of code. But looking for the most expansive query can easily locate the bottleneck area. Maybe it only happens to a couple of the biggest tables, views or stored procedures. Add or fine tune an index may help right the way. If bumping up the RAM is possible try that option as well. That is cheap and easy configure.
Good luck.
You might want to google for "sql server scalable shared database". Yes you can store your db files on a SAN and use multiple servers, but you're going to have to meet some pretty rigid criteria for it to be a performance boost or even useful (high ratio of reads to writes, small enough dataset to fit in memory or a fast enough SAN, multiple concurrent accessors, etc, etc).
Clustering is complicated and probably much more expensive in the long run than a bigger server, and far less effective than properly optimized application code. You should definitely make sure your app is well optimized.
What are the best options/recommendations and optimizations that can be performed when working with a large SQL Server 2005 table that contains anywhere from 100-200 Million records?
Since you didn't state the purpose of the database, or the requirements, here are some general things, in no particular order:
Small clustered index on each table. Consider making this your primary key on each table. This will be very efficient and save on space in the main table and dependent tables.
Appropriate non-clustered indexes (covering indexes where possible)
Referential Integrity
Normalized Tables
Consistent naming on all database objects for easier maintenance
Appropriate Partitioning (table and index) if you have the Enterprise Edition of SQL Server
Appropriate check constraints on tables if you are going to allow direct data manipulation in the database.
Decide where your business rules are going to reside and don't deviate from that. In most cases they do not belong in the database.
Run Query Analyzer on your heavily used queries (at least) and look for table scans. This will kill performance.
Be prepared to deal with deadlocks. With a database of this size, especially if there will be heavy writing, deadlocks could very well be a problem.
Take ample advantage of views to hide query join complexity and potential for query optimization and flexible security implementation.
Consider using schemas to better organize data and flexible security implementation.
Get familiar with Profiler. With a database of this size, you will more than likely be spending some time trying to determine query bottlenecks. Profiler can help you here.
A rule of thumb is if a table will contain more than 25 million records, you should consider table (and index) partitioning, but this feature is only available in the Enterprise edition of SQL Server (and correspondingly, developer edition).