Webcast: Do It Right: Best Practices for Analysis Services 2005 and 2008
Are you seeking practical, in-depth technical advice for building a BI solution using SSAS? Analysis Services changed tremendously with the advent of SQL Server 2005. It introduced a new way of building dimensions and cubes that required a new way of modeling the solution. This session examines the best practices for properly designing cubes for performance and usability. It discusses some high-level topics but also looks at advanced topics such as alternative approaches to many-to-many dimensions, SCOPE statements, aggregation design, scalability issues, processing techniques, server properties, and more. Craig Utley has been working with Microsoft’s BI products for 11 years and is a former Program Manager with the SQL Server Customer Advisory Team (SQLCAT), where he worked with some of the largest Analysis Services installations worldwide. In this session he brings his real-world experience with large, complex SSAS projects and presents best practices uncovered as companies deploy and use Analysis Services.
Presented by: Craig Utley
> Register Now
> Live date: 12/8/2010 at 12:00 Pacific
Featured White Paper(s)
Free Poster – SQL Server Perfmon Counters of Interest
When you’re looking for a reliable tool to diagnose SQL Server issues, Perfmon is often the answer. No more wasting time trac… (read more)
Connecting Your Applications to SQL Server
How we connect to a SQL Server is the first line of defense for system security. However, it is generally one of the last things we consider or implement.
Many systems simply use the SA (System Administrator) account with Administration privileges in the SQL Service so they don’t have to debug why they can’t access a table, procedure, object, etc. We start out developing this way. Then, when it comes time to release the product in a production environment, we can’t deploy the application using an account with limited capacity.
Another problem is that development is performed where the application expects Database Owner (DBO) Rights on the database. Very few applications, or application features really require DBO credentials. However, if you develop all your code using DBO permissions, you will not have time to introduce a more restricted role.
Here is another list (I said I like lists) of things you should consider:
1) Start developing with an account that has limited access. The account may be a SQL Server account, a local user account, or an AD Account. I prefer AD because there is little to do when deploying.
2) Use a different account for creating database objects than the one used for your application. This way your application account starts out with the necessary restricted credentials.
3) Utilize Schemas for object ownership. It simplifies granting permissions, and can organize your objects for you too.
4) Use more than one application account if needed. Some applications may only need read access…if that is the case, an account with read only access can be greatly restricted.
5) Make sure that the connecting account credentials are only granting the necessary SQL Server Roles. Do not make it SYSADMIN so you don’t have to grant further rights.
Add to my list. Send your insights to btaylor@sswug.org and well post them here.
Cheers,
Ben