Stephen Wynkoop

Demo: Capture perfmon counters to binary logs and at the same time capture SQL Profiler. Then you can load both into profiler and see both at the same time. Great for troubleshooting what might be causing a problem or what is happening at a particular point in time.

Historical only (not real-time)

When things go Wrong

• What changed?
• What were you doing?
• What were you seeing?
• Answer: NOTHING.

Add all the counters you need. Don’t be skimpy. Start broad and then narrow down. If you don’t record it, you can’t see it.

Intro to SSAS 2008

Marc Beacom

• www.MarcBeacom.com
• twitter.com/MarcBeacom

You can import an existing cube into BIDS which will essentially create a copy of the project that was used to create the cube. (Probably only to a certain extent)

PerformancePoint Services 101

Craig Utley

• Craig Utley, Mentor with Solid Quality Mentors
  • Consultant specializing in development with Microsoft technologies and data warehousing
  • Published author of books, whitepapers, articles, and courseware
  • Operator of LearnMicrosoftBI.com

Performance Point Services

Monitoring, Analytics and Planning

Planning being removed in the next version

• Monitoring: Scorecards and dashboards.
• Analytics: Drill up, drill down, slicing, dicing, etc…

Performance Point ships only with MOSS. With MOSS 2010, 64-bit only, no 32-bit.

KPI Sources are usually cubes but can be other sources including SQL Server, Excel and other sources.

No Pie Charts until next version.

Financial analytics with SQL Server Analysis Services

Donald Farmer

@donalddotfarmer

Need to listen to the Scottish Starbucks analogy again. It was a great analogy but want to be sure I didn’t miss something.

Financial Calculations

• Currency Conversions
• Time Intelligence
• Account Intelligence

Resources

http://www.microsoft.com/sqlserver/2008/en/us/analysis-services.aspx
http://sqlblog.com/blogs/mosha/default.aspx
http://www.sqlserveranalysisservices.com/default.htm
http://sqlcat.com/Default.aspx

Full SpectrumBusiness Intelligence

Donald Farmer

@donalddotfarmer

These slides are masterful is telling the verbal story Donald is presenting. I am putting up a few of the key slides that will server as good reference to me.

Thanks Donald!

Data quality is “fitness for purpose”. IT cannot tell you is a record is good.

TJ Belt

http://tjaybelt.blogspot.com
http://www.twitter.com/tjaybelt

You are on-call, maybe middle of the night and you get a call and there’s a problem. What do you do?

• What tasks were last performed by what persons?
• Start documenting incidents if you don’t already. Great for helping resolve things later down the road.
• Document, document, document

Items to be sure of and continuously check

• Scan OS error events
• Check on backups
• System specific output files (xml, reports, files)
• Log and data file sizes
• Space available / Free space on drives
• Replication health
• SQL Server logs
• Other notes of interest

Work to get your logs clean over time so that problems become more apparent and you will spend less time chasing red herrings.

“You only need one. Either a good backup or a good resume.”

Only notify on error, not on success. (Of course there may be exceptions)

• What are Microsoft SQL Server operators and how to define them (Part 1)
• Undocumented SQL Server 2005 Database Maintenance Plan Stored Procedures
• DB2 and the Procedural DBA, Part 1

Dimension Table ETL with SSIS

Erik Veerman
Mentor, Solid Quality Mentors
SQL Server MVP

Dimension tables contain the “text descriptors” or attributes. Also organized as hierarchies of categories, levels and members.

Slowly Changing Dimension (Ralph Kimball)

• Type 0:No change (Fixed Attribute)
• Type 1:The value is overwritten (Changing Attribute)
• Type 2:Slow changes. A new row is added (Historical Attribute)

Type 2 – New surrogate key and Start Time/End Time updates so to add the new record.

Inferred Members

• Missing dimension member during Fact load later becomes available in the Dimension source
• Also known as late arriving dimensions
• Fact load, placeholder record added to dimension table with new surrogate key generated
• Dimension process, for inferred members, all dimension attribute columns are updated with new values (type 2 attributes are handled as type 1)

Additional SSWUG Articles

• Troubleshooting SQL Server 2005 Integration Services
• MSDN Webcast Summary: Introducing SQL Server Integration Services for SQL Server 2005
• Tips for using SQL Server 2005 Integration Services (Part 3)

Fact Table ETL with SSIS

Erik Veerman
Mentor, Solid Quality Mentors
SQL Server MVP

Identify Dimension Surrogate Keys

• Locate dimension candidate keys in transaction source
• Validate uniqueness and data integrity
• Considering historical changes
  • Identifying current dimension record, combine business keys with current identifying meta data (data identifier or boolean)
  • Handle missing dimension records
• SSIS Data Flow Options
  • Lookup transformation
  • Merge Join transformation
  • Fuzzy Lookup transformation
• SSIS Control Flow Option
  • Execute SQL Task

• Fact ETL involves surrogate keys, grain changes, and measure calculations
• SSIS handles these through several out-of-the-box transformations

Loading a Data Warehouse with SSIS

Brian Knight
bknight@pragmaticworks.com
CEO, Pragmatic Works

Why Data Warehouse?

• Get users off of transactional systems
• Keeping more data online
• Easier reporting
• Consolidate data sources

Data Separated into fact and dimension tables

• Dimension tables answer the pivot or where clause
  • Make as wide and descriptive as possible
  • Surrogate keys operate as unique ID for each row
  • Keep surrogate keys as small as possible
• Fact tables answer the what or select statement
  • Intersect all dimension tables
  • Surrogate keys from each dimension in this table
  • Measures are the “what” like Price, Quantity, Duration

Additional Articles

• MSDN Webcast Summary: Introducing SQL Server Integration Services for SQL Server 2005
• SQL Server 2008 Katmai Change Data Capture (CDC)
• Troubleshooting SQL Server 2005 Integration Services

• http://Blogs.pragmaticworks.com/brian_knight
• http://www.twitter.com/brianknight

Live – SQL Server Analysis Services – Real World Performance Tuning (4hrs)

Ted Malone

(I only caught a few minutes here and there of this marathon live session, but the parts I caught were good. We’ll have to watch the on demand once it goes up.)

• Recommends looking at a product called Performance Advisor from SQL Century for getting performance insight into SSAS.

DBA Checklist

Buck Woody, Microsoft SQL Server Specialist

http://blogs.msdn.com/buckwoody
http://www.informit.com/guides/guide.aspx?g=sqlserver
http://edge.technet.com/People/BuckWoody/

SSMS

• Object Explorer: Right click to see additional columns including Last Backup.
• Standard Reports available via right click
• Log Viewer

oSQL or SQLCMD

PowerShell – Latest and greatest

Post Installation

Daily, Weekly, Monthly and Yearly

Recommends being alerted of both error AND success in order to know that maintenance task really did run.

Maintenance tasks

• Do not run the auto-shrink option in your tasks.

Take a baseline with PerfMon. Email him for a list of counters.

Keep a SQL Server run book containing all configuration changes.

Solving Business Pains with SQL Server Integration Services

Jason Strate

SQL Server MVP
Enterprise Consultant with Digineer
Working with SQL Server since 1997

feeds2.feedburner.com/StrateSql
twitter.com/StrateSQL

• Consolidate packages and deployment
• Use ForEachwith ADO Enumerator for non-file looping
• Expressions on connections increase flexibility of package
• Store config type info in tables for easy retrieval and looping

Add It Up – Analysis Services Aggregations

Craig Utley, Mentor with Solid Quality Mentors
–craig@solidq.com

LearnMicrosoftBI.com

• Hierarchies must be natural to create aggregations at various levels
  • This means creating attribute relationships
• ProcessFulland ProcessIndexesbuild indexes and aggregations
• ProcessUpdateperforms adds, updates, and deletes to a dimension table
  • If a change is detected, flexible aggregations are dropped
• ProcessAddonly adds new records so both flexible and rigid aggregations are kept

OLAP and Data Warehousing – Data Warehousing Solution Architecture (Part 2)

Avoiding Common Analysis Services Mistakes

Craig Utley, Mentor with Solid Quality Mentors
–craig@solidq.com

LearnMicrosoftBI.com

• Dimensions appear to be especially problematic for companies
• The first thing companies should do is correctlyidentify attribute relationships
  • Not identifying them is bad
  • Incorrectly identifying them is worse
• Attribute relationships with flexible relationship types can cause problems with non-unique attributes (eg. Date hierarchy)
• Decide when IgnoreUnrelatedDimensions should be true
• In MDX explicitly reference cells when possible
  • Products.Printersinstead of Dimensions(2).Printers
  • Products.Printersinstead of Products.CurrentMember

Live Session – DBA Survivor II

Thomas LaRock

http://thomaslarock.com/presentations

• Know your RAIDs.
• HA vs. DR – Two different things. Glad he is reminding folks of this!
• Networks – Don’t forget this can cause “performance” problems.
• DBA = Default Blame Accepter (I know Network admins that might argue about that.)
• Be Nice! – #1 rule?
• Email – DON’T DO THIS.  hehe
  • “I have never, nor will I now, tolerate your foolishness.”
  • “I am done with your useless babble.”
• Development
  • “A development server is a production server to a developer”
  • Ask them if it is OK to lock down that server, should fix that response.
  • Manage expectations
    • Be responsive AND responsible
      • Own success AND mistakes (Amen!)
    • Results, not effort
    • Tangible output
  • Get used to developers being needy – They are undo pressure to deliver products on time and under budget.
• Time Management
  • Get in a routine
  • To-Do List
  • Chunking – Write those 6 blog articles at once and schedule publication over the week.
  • Know when to say No

Oh yeah, the sessions. I almost forgot.

If you are interested in knowing what sessions I plan to attend, here is the list.

Day 1

• Scheduled
  • Solving Business Pains with SQL Server Integration Services
  • Avoiding Common Analysis Services Mistakes
  • Live Session – DBA Survivor
  • Live Q&A
• On-Demand
  • Enriching the Design of an Analysis Services Cube
  • Embedding Reporting Into Applications with the ReportViewer Control
  • Add It Up: Analysis Services Aggregations
  • Aggravating Aggregations
  • On Call Duties
  • Configuring the Business Data Catalog

Day 2

• Scheduled
  • DW Dimension Table ETL with SSIS
  • 7 Extraordinary Things To Do With Integration Services
  • DW Fact Table ETL with SSIS
  • SSAS Cube and Dimension Processing with SSIS
  • Q&A
• On Demand
  • DBA Checklist
  • Administrating SQL Server Integration Services (SSIS)
  • ESB Toolkit 2.0 Overview
  • Database Change Process
  • Loading a Data Warehouse in SSIS
  • Implementing Messaging Solutions Using ESB Toolkit 2.0

Day 3

• Scheduled
  • Intro to SSAS 2008
  • PerformancePoint Services 101
  • Financial analytics with SQL Server Analysis Services
  • Full Spectrum Business Intelligence – aligning IT and Business in the new world of data
  • Q&A
• On Demand
  • Data mining for DBAs
  • Introduction to Sketch flow
  • SQL Statement Tuning with Showplan
  • Live Session- Get jQuery().ready; with Rachel Appel
  • SQL Statement Tuning with Indexing Strategies

So, that’s the plan. Obviously all the on-demands won’t be able to be completed each day but hopefully within the next week I can get a look at each of them. There is always the hope of that one golden nugget out of each session.

Blessings.

Came across this product again today to help with a particular need. I’ve used Red Gate products before at another employer and loved them. However, I never realized the SQL LogRescue product. On top of that, it is a free tool.

Kudos to the Red Gate folks for making this tool available to the SQL Server community. I know, your saying that there are other ways of dealing with transaction logs, and you’re right. But what I like about the SQL Log Rescue is the quick intuitive way to essentially create an audit trail, review the transactions in question and undo various transactions individually.

Now the downside….it is only for SQL Server 2000. I know. that’s two SQL versions ago. So hear is my question.

What are you using to handling transaction log, transaction restore and such? Let me know, add a comment.

In a Business Intelligence solution, the fact tables hold the core data that you are analyzing – facts (also called measures). Therefore, fact tables are a critical component to get right the first time. Poor fact table design will lead to poor performance and difficult calculations. This session dives into fact table and considers the basic column types, measure aggregation types, fact table types, and volume considerations.

Facts

• The fact itself
  • The “measure” that is being tracked. The thing
  • Quantity, count, amount, percent
  • Most always numerical, continuous values
    • e.g., price of a product, quantity sold, budget value, count of customers
• Facts (or measures) can be classified by…
  • Numerical data type
  • Aggregation type
  • Additive nature
  • Granularity – level of detail stored
• Fact tables
  • Capture measures/facts
  • Association with dimensions (using surrogate key as foreign key in fact table)
    • No dimensions attributes!
  • Some tracking information included
• Different types of fact tables
  • Transactional – Additive facts tracking events over time (Star Schema)
    • Most common type of fact table
      • Track the occurrence of events, each detailed event is captured into a row in the fact table
      • Measures are typically additive across all dimensions
      • Common transactional fact table types
        • Sales, Visits, Web-page hits, Account transactions
  • Snapshot or inventory – Pictures in time of levels or balances
    • Periodic
    • Accumulating
    • Known as inventory level fact tables
      • Time dimension used to identify grain
      • Non additive measures across time, but typically additive across all other dimensions
      • Common transactional fact table types
        • Inventory levels, Event booking levels, Chart of account balance levels
  • Factless – Dimensionality relationships
    • No measured facts!
      • Are useful to describe events and coverage
      • Information that something has or has not happened
        • Often used to represent many-to-many relationships
        • Contain only dimension keys
        • Common factless fact tables:
      • Class attendance, Event tracking, Coverage tables, Promotion or campaign facts
• Fact Table Granularity
  • Never mix the grain of the table!
  • The level of detail of data contained in the fact table
  • The description of a single instance (a record) of the fact table
  • Typically includes a time level and a distinct combinations of other dimensions
    • e.g. Daily item totals by product, by store, Weekly snapshot of store inventory by product

Maybe include ETL load date/time in the fact table.

Measures – Additive Nature

• Additive: Facts that can be summed up/aggregated across all of the dimensions in the fact table
  • e.g. discrete numerical measures of activity, i.e. quantity sold, dollars sold
• Semi-Additive: Facts that can be summed up for some of the dimensions in the fact table, but not the others
  • e.g. numerical measures of intensity, i.e. account balance, inventory level, distinct counts
• Non-Additive: Facts that cannot be summed up for any of the dimensions present in the fact table.
  • e.g. room temp

Aggregations

• Aggregation (Aggs): A summarization of base-level fact table records
  • Common aggregation scenarios
    • Category product by store by day
    • District store by product by day
    • Monthly sales by product by store
    • Category product by store district by day
    • Category product by store district by month
• Aggregations need to account for the additive nature of the measures
  • Aggregations can be created on-the-fly or by the process of pre-aggregation
  • Common aggregations
    • Sum
    • Count, Distinct Count
    • Max, Min
    • Average
    • Semi-additive: Last Child, Last Non-empty Child

http://www.microsoft.com/fasttrack
SQL Server Fast Track Data Warehouse accelerates your data warehouse roadmap with new SQL Server 2008 Enterprise scalable reference architectures for HP, Dell and Bull. Reduce costs, save time and reduce risk with reliable, pre-tested hardware and best practices for warehousing. Read more.

Design with Additive in Mind

• Think dimensionally!
• Complex requirements don’t need to be designed with complex queries
• Many times new fact tables can be designed that can answer specific questions, such as date attributes and ranges

Getting Started

• Step 1: Identify high-value business process to model (orders, invoices, shipments, inventory)
  • Confirm data source availability
  • Understand value vs. complexity
• Step 2: Identify reporting grain of the business process
  • The grains is the level of detail at which the data should be represented for analytics
  • This may not be the same grain as the source!
  • For snapshot facts, determine what time level will be captured for each snapshot (daily, weekly, monthly)
• Step 3: Identify dimensionality that will apply to each fact table
  • Time, product, customer, store, etc.
  • Some dimensions are not grain-identifying
  • Validate the source can associate to the fact table
• Step 4: Identify measured facts that will populate fact table
  • Validate the base measures are identifiable from the source
  • Some measures may be derived
  • Measure examples: product count, quantity sold, dollars sold, inventory quantity
• Identify business questions:
  • How much total business did my newly remodeled stores do compared with the chain average?
  • How did leather goods items costing less than $5 do with my most frequent shoppers?
  • What was the revenue comparison of non-holiday weekend days to holiday weekend days?
• Analyze questions to assist design!

I really like these “Getting There” bullets. Erik does a good job summarize and giving you something practical to walk away with. Nice stuff.

Dimension Tables are one of the core components in a dimensional design and it is critical to design your dimension tables correctly in order to lay a solid foundation to a Business Intelligence system. This session dives into the dimension design techniques and considers the core components of a dimension table, surrogate keys, attributes, and hierarchies. In addition, we will consider advanced hierarchy types such as parent-child hierarchies, snowflake designs and unbalanced hierarchies. Finally, we will consider the best practices in tracking changes historically.

This session was intense so I just could not keep up with the slides. Here are just notes apart from the slides once I fell behind. Erik presents excellently and at a level appropriate for a 101 session without being condescending. Great job!

Dimensions (review from Dimensional Modeling 101 Session)

Dimensions – Qualitative
Facts (Measures) – Quantitative

• Dimensions (Qualitative information)
  • Business perspective from which data is looked upon
  • Collection of text attributes that are highly correlated
  • e.g. Product, Store, Time, Manager of Store
• Conformity (How Dimensions relate to each other)
  • Shared with multiple fact relationships
  • Provides data correlation
• Attributes (many times is related to a table column, not always)
  • Descriptive characteristics of an entity
  • Building blocks of dimensions, describe each instance
  • Usually text fields, with discrete values
  • e.g., the flavor of a product, the size of a product
• Hierarchies
  • drill-paths within the dimension
  • Allows top-down analysis
  • Natural groupings of data relationships
  • e.g., date hierarchy is most common. Year to qtr to month to day for example)
• Dimension Keys
  • Surrogate Keys (Primary key, DW created)
  • Candidate Business Keys/Alternate key (Source system keys, uniqueness)
• Dimension Granularity
  • Granularity in general is the level of detail of data contained in an entity (lowest level detail)
  • A dimensions granularity is the lowest level object which uniquely identifies a member
  • Typically the identifying name of a dimension

Name surrogate key with SK_
Dimension naming DIM_
Fact naming FACT_

http://www.codeplex.com/MSFTDBProdSamples to download the AdventureWorksDW example.

Hierarchies

ALL level is usually the top level

All -> Region -> Country -> City -> Office

Seeing one we could use would related to the various Bible translation project locations currently under way. Need to keep in mind project sensitivities.

A dimension can have multiple hierarchies.

Standard Hierarchies

• All levels have values.

Ragged Hierarchies

• Missing members at the mid-levels.
  • All -> Country -> State -> City and then you might be missing a state is the country is Israel since there are not states there.

Unbalanced Hierarchies

• Multiple grains in the hierarchy
• May not always be able to drill down to the lowest detail level since the branch may stop short. (Think Org Chart)

Demo: SSMS connected to a SSAS Cube

Product – Standard hierarchy

Sales Territory – example of unbalanced hierarchy

Employee – another example of an unbalanced hierarchy

Dimension Keys

Business Keys

• Column(s) identify the unique instance of a business record form the source system.
• You may have multiple records with the same Business Key. This is right as it allows historical tracking.
• Used in the process that ties fact records with dimension members
  • Business key is used to find the right surrogate key reference

Surrogate Keys

• • Defined the dimension’s primary key
  • Usually an integer
    • Important to pick the right column width.
    • 2,4,8 byte
      • SmallInt – 2 bytes go for up to around 10k records
      • BigInt – 8 bytes, for REALLY large dimensions
  • Consolidate multi-value business keys
  • Allows tracking of dimension history
  • Standardizes dimension tables
    • All are structured in the same way
      • Business Key
      • Surrogate key

Don’t put attributes and business keys in your fact table.

Design Practices

• Avoid smart keys
• Avoid production keys
• production may decide to reuse keys
• the company may acquire a competitor and thereby change the key building rules changed record, but deliberately not changed key

Types of Dimensions

Different dimensions types should be used in different scenarios.

Basic Dimension Types

• Standard Star dimension
  • Single table
  • Usually date
• Snowflake
  • More than one table in a cascading
• Parent Child (unbalanced hierarchy)
  • Self referencing surrogate to parent surrogate key relationship
  • Self referencing business key relationship
  • e.g. Org Chart, Chart of Accounts

Advanced Types

• Degenerate (Seldom used. Be careful)
  • Dimensions business key with no corresponding dimension table
  • Are embedded in the fact table
  • Typically use only when your Dim record count is about the same as the fact table record count.
  • Usually in line item oriented tables like sales tables
• Profile or Junk Dimensions
  • Convenient grouping of flags and attributes to get them out of the fact table into a useful dimensional framework.
  • Good for one-off lookups. Put them into a single dimension rather than a bunch of small dimensions
    • True/False type attributes
• Role Playing Dimension
  • A single dimension used for multiple purposes
  • Typical example is the date dimension or the geography dimension (outrigger)
• Time Dimension
  • Multiple calendars
    • Fiscal
    • Natural
  • Usually a single table

Tracking History

Industry best practices.

Changing Dimensions

• Slowly changing Dimensions
  • o – No change
    • Birthdate
  • 1 – Not interested in history (Updating a row/record)
  • 2 – Slow changes. Adds new row/record
  • 3 – Fast changes. Adds new column

• Rapidly changing Dimensions
  • Large dimensions
    • Limit type 2′s

Good example graphical slides of Type 1 versus Type 2

Getting There

• Understand dimension hierarchies and drill-paths
• Confirm historically tracked attribute req’s.
  • Don’t be afraid to push back a little
• Check source system data integrity, cleanliness
• Review current reports

DMV – Dynamic Management Views (and functions)

• Returns server state information that can be used to monitor the health of a server instance, diagnose problems, and tune performance.* MSFT – 2008 BOL

DMV Categories (Not all are going to be in this session)

• Change Data Capture
• Query Notifications
• Common Language Runtime
• Replication
• Database Mirroring
• Resource Governor
• Database Related
• Service Broker
• Execution
• SQL Server Extended Events
• Full-Text Search
• SQL Server Operating System
• Index
• Transaction
• I/O
• Security
• Object

DMV’s help with the ever growing infrastructure and complexities. Allow you to monitor and manage your environment.

Key DMV’s

• Sys.dm_os_sys_info
  • General Server Info
• Sys.dm_exec_requests
  • Sp_who(2)
• Sys.dm_db_index_operational_stats
  • Sp_lock
• Sys.dm_db_index_usage_stats
  • Base DMV for Index Analysis and Recommendations
• Msdb.dbo.backupset
  • Base table for backup history
• Sys.dm_exec_cached_plans
  • Shows query plans that are cached by SQL Server
  • For query plans, this DMV maps to the syscacheobjects table in SQL Server 2000
• Sys.dm_exec_query_stats
  • Performance statistics for cached query plans
  • Top 10
• Sys.dm_io_virtual_file_stats
  • I/O stats for data and log files
• Sys.dm_os_memory_pools
  • Monitors Cache memory
• Sys.dm_exec_sql_text
  • Returns the text of the SQL batch that is identified by the specified sql_handle.
  • This table-valued function replaces the system function fn_get_sql
  • Obtained from:
    • Sys.dm_exec_query_stats
    • Sys.dm_exec_requests
    • Sys.dm_exec_cursors
    • Sys.dm_exec_xml_handles
    • Sys.dm_exec_query_memory_grants
    • Sys.dm_exec_connections

“Use it early, use it often” – Jeremy 

Love it that every technical person presenting a demo has hit at least one minor glitch. Let’s me know it’s not just me. Ha!

Resources

• http://www.sswug.org
• Local User Group
• Books On Line
  • SQL Server 2008 Performance Studio
    • https://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032349947&CountryCode=US
    • http://www.microsoft.com/midsizebusiness/business-goals/business-operations/

craig@solidq.com
http://learnmicrosoftbi.com

General Design

• SSAS 2005 and 2008 are extremely different from SSAS 2000
• Upgrading from 200 might work on small simple cubes. Not recommended
• In almost all cases, expect to redesign the AS db to take advantage of new features
• For larger project, plan to have a hardware expert available who understands SAN, load balancing, etc…

Design – Data Sources and Data source Views

• DS should us Windows Authentication when connecting to SQL server and then impersonate a domain account created for this purpose
  • Account should have the least privileges possible to get to the data
• For SQL Server use the Microsoft OLE DB Provider for SQL Server or the SQL Server Native Client instead of the .NET Data provider
• In the Data Source View, create a new diagram for each fact table.
  • This helps make each view look like its own star or snowflake schema
• For simple calculations and concatenations, create new named calculations in the DSV

Design – Dimensions

• There are a number of design issues related to dimensions, including
  • Attribute relationships
  • Attribute key columns and name column
  • Multilevel hierarchies and attribute hierarchies
  • Other areas

Attribute Relationships

• Attribute relationships tell the Analysis Services engine how attributed are related so that it can build aggregations and speed queries (First thing you need to do)
• Ensure that attribute relationships are created and created correctly.
  • The visual designer in BIDS 2008 makes this much easier
• Set the RelationshipType to Rigid when possible.

Attribute KeyColumns and NameColumn

• Ensure that the KeyColumns is set to identify unique values
  • For example, a month value of 1 is insufficient if the dimension contains more than a single year
• Set the NameColumn to a column that makes it clear what is being shown
  • For example, instead of just a month value of 1, combine the month and year

Other Dimension Design Issues

• Hide attribute hierarchies for attributes added to multilevel hierarchy
• A dimension should contain no more than one non-aggregatable attribute
• Use numeric key columns
  • Especially important for dimensions with more than 500,000 members
• Parent-child dimensions should not have more thank 500,000 members in the key attribute.
• Specify a dimension as type Time when possible.
  • Needed for some functions to work.

Design – Measure Groups

• Avoid having multiple measure groups with the same granularity and dimensionality
• Set IgnoreUnrelatedDimensions to False when possible to avoid repeating a value for all unrelated members!
  • Big pitfall for those new to Cubes.
• Don’t create a many-to-many relationship if the dimensions or intermediate fact table have more than one million members
  • Alternatives exist, check out Erik Veerman’s blog at http://blogs.solidq.com/EN/Erik

Design – Aggregations

• Rule of thumb. Start with 20% using aggregation wizard.
  • Then log queries during periods of normal activity and use the Usage Based Optimization wizard (UBO) to define better aggregations.
  • 2005 was a bit lacking, fixed in 2008
• Set approximate counts if there is too much data to let the wizard count the rows
• When creating custom aggregations, do not create aggregations below the measure group’s granularity
• Don’t create overlapping aggregations

Funny. He said “Agg”. Of course to me that means “Agriculture” not “Aggregations”. Ha!

So, wonder if they are going to give away some of those button down SSWUG.org shirts. Very nice! 

Design – Partitions (Ugh)

• Enterprise edition only feature.
• Create partitions for larger data sets in order to speed up queries.
• Partition by common usage, such as time
  • Current year, vs. historical
• Partitioning by more than one criteria is acceptable, but ensure fact records do not appear in more than one partition
• Cubes should have no more than 2,000 partitions with a max of 20,000,000 records each (2000 only)
• Partition the relational warehouse fact table the same way as the cube.

Processing

• Tweak the number of parallel tasks on the production server to see if a different value decreases processing time
• Use ProcessData and PRocessIndex instead of ProcessFull to get more consistent processing pattern
  • 3-5% slower but recommended
• Use ASCMD to manipulate and process objects, especially on very large databases
• Use the <Parallel></Parallel> block to process objects in parallel

Server Settings

• If running other apps or multiple instances of SSAS
  • Move Memory/LowMemoryLimit below 75%
  • Move Memory/TotalMemoryLimit below 80%
• Modify CoordinatorExecutionMode to increase parallelism
  • Negative numbers ……******************8

Querying Tips

• Learn how to monitor queries in action
  • See Identifying and Resolving MDX Query Performance Bottlenecks in SQL Server 2005 Analysis Services
• Make sure to understand the ThreadPool/Query settings
• See if data is coming from a cache, an aggregation, or a subcube query
• In high usage scenarios it can be useful to adjust MemoryHeapType
  • Call PSS for support
• Learn how to scale up and scale out

MDX Tips

• Set Non-Empty behavior property on calculations when possible.
  • Be careful can degrade performance
• Explicitly reference cells when possible
• Move simple calculations from calculations to the DSV
• Learn how to use the Scope statement.
  • Makes for easier to read queries where you typically would have lots of IIF.

Summary

• There are many best practices that must be applied during the design phase.
  • Dimensions
  • Measure Groups
  • Data sources and such
  • Processing can be tweaked through parallelism and memory adjustments
  • Querying can be tuned through proper MDX, memory adjustments and partitioning

Thanks to @swynk for the reminder that I can download the slides. So, my next posts should be just notes of things not on the slides. Whew! I can slow down.

Blessings.

Game Changing Announcement for Microsoft BI

Boy doesn’t this sound like other previous Microsoft endeavors. Hmmmm…. The post/video indicates the following end results.

• Supporting the democratization of BI (aka BI for the masses) with the consolidation of PerformancePoint Server Monitoring and Analytics functions into Office SharePoint Server Enterprise. The new capabilities will be called PerformancePoint Services.
• As I read the announcement, PerformancePoint Planning has been put out of our misery. Service Pack 3 will represent the end of the line for investment in a stand-alone PPS Planning product.