Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie The SQL Stack Design And Configurations
Ähnlich wie The SQL Stack Design And Configurations (20)
The SQL Stack Design And Configurations
- 1. The SQL Stack -Design and Configuration for High Availability Presented by: Stephan Lawson Level 100
- 2. Bio SQL DBA at Nedbank Ltd. Managing large scale OLTP and OLAP environments. Performance Tuning & Optimization. Troubleshooting SQL Server, SSRS and SSIS. Follow me on Twitter @SQLArcher Blogger at lessthandot.com SQLArcher
- 3. Overview The Environment OLTP and OLAP Considering Configurations Stand alone servers Clusters SQL Server Reporting Services Analysis Services Summary Q&A
- 5. OLTP and OLAP Don’t access your OLTP directly!!! Spec your OLTP correctly, RAM, CPU and Disk. CPU intensive Short sub-second queries Fast disk throughput Benchmark You NEED to know when your environment is taking a hit when it shouldn’t.
- 6. OLTP and OLAP (continued) OLAP is where the magic of BI takes place. Spec your servers to cater for the incoming load. Memory intensive. Long queries. Huge disk consumption Get your OLTP data here. Replication Transactional replication for mission critical systems. Snapshot replication for important, but not critical data. HADRON New in SQL 11 codenamed Denali Uses mirroring with a readable secondary database.
- 8. Stand Alone Servers When the budget hits…
- 9. Stand Alone Servers All the SQL components are resource intensive in different ways. SQL Server CPU (OLTP) and RAM (OLAP). Fast and redundant disk, either RAID 5 or 10 Analysis Services SSAS prefers the cubes in RAM. Fusion-IO for paging.
- 10. Stand Alone Servers (continued) Reporting Services Use stored procedures to offload some of the CPU and RAM overhead to SQL Server. Reserve CPU and RAM for SSRS ( 2008 uses IIS internally).
- 11. Stand Alone Servers (continued) Additional settings for performance. Separate service accounts. Lock pages in memory. Service specific settings. SQL Server CPU Affinity. Min/Max Memory. Resource governor. Analysis Services Min/Max Memory. Enable shared memory. Max CPU Usage. Performance test all cubes in Visual Studio.
- 12. Stand Alone Servers (continued) Reporting Services Use stored procedures for reports. Lock pages in memory for service account. Reserve CPU and Memory for SSRS.
- 13. Stand Alone Servers Diagram
- 14. Clusters When a company thinks this solves everything…
- 15. Clusters Clusters are for High Availabilitynot a sudden onset of performance. Clusters as “SQL Solutions” would be: SQL on node 1. BI separate either sharing node 2, or a dedicated node. Without passive nodes, the cluster looses “High” availability. SSRS is not cluster aware. Load balancing is required to scale out SSRS effectively. MS KB970759 for a workaround.
- 16. Clusters Diagram
- 17. ! Summary
- 18. Closing notes SQL Server and Analysis Services both allow for settings to configure and in some cases optimize for performance when running on the same hardware. Stand alone servers can be used, when configured correctly without major performance impacts. Clusters are not the answer for any performance issues, they require diligent configurations for their purpose. Also, keep in mind when loading SSAS,SSRS and SSIS on separate servers other than SQL Server requires additional licensing!!!
- 19. ! Q & A
- 20. Thanks Enjoy the rest of SQL Saturday and the sessions. Please complete the speaker evaluation forms. Go performance tune your systems.
Hinweis der Redaktion
- OLTP:OLTP environments have thousands of incoming transactions.Small insert/update/delete queries.MAXDOP settings should be lowered, otherwise CPU contention can take place.
- OLAP:Requires large amount of memory for complex data mining or cubes.Complex queries are used for extracting the data, either in T-SQL or MDX/DMX.Reports can contain hundreds of queries, depending on complexity.Use replication to get the data from your OLTP to your OLAP environment.SQL 11 “denali” introduces HADRON, which relies on SQL mirroring. However the standby database in this case is read-only, instead of in standby.
- The SQL Engine requires resources depending how it is setup. In OLTP where short queries should be used, CPU’s will take preference due to the size of the query plans will be a lot smaller, and not need huge amounts of RAM. In a OLAP situation where multiple long running, and analytical queries will be executing the opposite is true. However, an OLAP environment will also hugely benefit from having multicore CPU’s ( this will also affect the MAXDOP of the server).The fastest disk you can afford, should be used to ensure that no IO bottlenecks occur, this holds true for both SQL and SSAS.If memory is a problem, or if the server has run out of DIMM slots; Fusion-IO drives should be put in place for paging where SSAS is concerned. It does not mitigate the IO bottleneck and speed sacrifices, but is however faster than any other local disk or SAN configuration.
- Reporting Services is only an engine. To mitigate some of the performance issues, stored procedures can be used to offload the memory workload to SQL Server. You should optimally configure the server in preference to SQL Server as it will always consume more resources than SSRS.For SSRS 2008 and later, the engine makes use of an internal IIS component for Web Services. Where possible, it should instead be considered to host the engine on a web farm instead.This has a licensing impact however. When the SSRS, SSAS or SSIS engine components are installed on a server other than the main SQL Server, additional licensing fees are applicable.
- Use separate service accounts for each service, to allow that the memory for those services are locked and cannot be paged out. This has a prerequisite of having enough memory allocated to the server for the desired workload.To alleviate additional performance issues, extra settings can be applied.Force SQL to only use a set amount of CPU’s.Configure min/max memory to ensure that it does not consume memory where it wants and to give control to the DBA.Resource governor can also be used, to mitigate performance risks between databases when some are more critical than others.For SSAS and SSRS, when residing on the same physical infrastructure, make use of the shared memory protocols. This will eliminate TCP round trips and unneeded waits on the requests.SSAS cubes can also be performance tested in Visual Studio to give you an indication of the time it will take to compile the cubes.
- Stored procedures should be used, as it will move all the query plans into the buffer cache for SQL, this is more robust than open or ad hoc queries. This also allows the DBA or support to test all procedures to ensure the code is optimized( you are running on a shared environment are you not).Lock pages will ensure that when memory is used by SSRS, that it will not page out and affect the response time of SSRS.To reserve memory for SSRS, ensure that all the required settings are set for SQL and SSAS, as there are none available for SSRS to specifically set it’s paramaters.
- SQL should be hosted on it’s own node to ensure that the resources are not consumed by the BI components.SSAS and SSRS can share on the same node IF he incoming load is not too big, and the servers are spec’d to handle it.When running SQL,SSAS and SSRS on the same cluster, if there is no passive node in the cluster to accommodate a failover; then the cluster “looses” it’s high availability as the combined resource consumption of SQL,SSAS and SSRS might be overwhelming to remaining node.SSRS is not cluster aware, but KB970759 gives an example to allow it to fail over in a clustered situation.