<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2012
»
SQL 2012 - General
»
AOG INDEXING
AOG INDEXING
Rate Topic
Display Mode
Topic Options
Author
Message
emile.milne
emile.milne
Posted Tuesday, January 22, 2013 9:46 AM
Valued Member
Group: General Forum Members
Last Login: Friday, February 22, 2013 9:22 AM
Points: 63,
Visits: 224
OK,
I don't have AOG setup yet, if I have a db that is part of my AOG. The indexes will be setup for OLTP operations.
I am not concerned about failing over the LIVE server to the AOG at any point. HA will be taken care of by the cluster. However in terms of indexes, if I wanted this db to be tuned for my reports can I still drop and create indexes to optimize my SSRS report execution on the AOG db without the sync having any issues.
This db although the data would be the same as LIVE would need to backed up separately as the schema would be different.
Post #1410130
Leo.Miller
Leo.Miller
Posted Tuesday, January 22, 2013 8:30 PM
SSC-Addicted
Group: General Forum Members
Last Login: Yesterday @ 2:32 PM
Points: 442,
Visits: 1,302
You need to think of Always On in terms of Log Shipping or Mirroring. The secondary databases can be configured to read from, but you can't update them directly, so you can't apply an alternate set of indexes. To do this you would need to use replication.
With replication you can replicate only the data (and the required Primary Key), and then configure alternate indexes on the subscriber database. This can be very effective, allowing you to exclude data you won't be reporting on since replication can be configured at fairly low level.
Cheers
Leo
Post #1410317
emile.milne
emile.milne
Posted Wednesday, January 23, 2013 2:30 AM
Valued Member
Group: General Forum Members
Last Login: Friday, February 22, 2013 9:22 AM
Points: 63,
Visits: 224
Thanks, thats not ideal. I think most people will use the replica for SSRS. Big flaw in the design then.
If I want to tweak the index for reports they need to be added to the LIVE db. Very poor oversight.
Post #1410419
Leo.Miller
Leo.Miller
Posted Wednesday, January 23, 2013 5:57 PM
SSC-Addicted
Group: General Forum Members
Last Login: Yesterday @ 2:32 PM
Points: 442,
Visits: 1,302
emile.milne (1/23/2013)
Thanks, thats not ideal. I think most people will use the replica for SSRS. Big flaw in the design then.
If I want to tweak the index for reports they need to be added to the LIVE db. Very poor oversight.
Not really, Always On is first a high availablity solution, and second an alternate data source for reporting etc. In most situations I've found Replication an excelent option for reporting.
Leo
Post #1410858
Lynn Pettis
Lynn Pettis
Posted Wednesday, January 23, 2013 8:52 PM
SSC-Insane
Group: General Forum Members
Last Login: Today @ 4:37 PM
Points: 21,627,
Visits: 27,480
emile.milne (1/23/2013)
Thanks, thats not ideal. I think most people will use the replica for SSRS. Big flaw in the design then.
If I want to tweak the index for reports they need to be added to the LIVE db. Very poor oversight.
Always On incorporates mirroring from 2005/2008 and makes the mirror database read only without having to create a database snapshot. Great for high availability and reporting that does not need different indexing than the principal database currently supporting an application.
If you were able to add indexes on one of the "mirrors" (Always On can have up to 4, 2 synchronous and 2 asynchronous) you would be changing the database structure. Not something one would want on a database that could become the principal database for an application if there was a failure of some sort.
Lynn Pettis
For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here
or
when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here
and
here
Managing Transaction Logs
SQL Musings from the Desert
Fountain Valley SQL
(My Mirror Blog)
Post #1410880
GilaMonster
GilaMonster
Posted Wednesday, January 23, 2013 11:44 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Today @ 4:11 PM
Points: 37,741,
Visits: 30,020
emile.milne (1/23/2013)
Thanks, thats not ideal. I think most people will use the replica for SSRS. Big flaw in the design then.
If I want to tweak the index for reports they need to be added to the LIVE db. Very poor oversight.
Not an oversight. The wrong tool for the job. Availability groups is primarily there so that if/when a disaster hits your primary database, you can switch to any of the secondaries and continue working with minimal to no interruption.
Availability groups, like mirroring (and log shipping), work by replaying the log records from the primary, not replaying the original. So an insert on the primary would result in log records that said 'insert this into allocation unit X and this into allocation unit Y'. The internal structure of the databases much be completely, 100% identical and the log records must match exactly (identical LSNs) or that replay of the log records will not be possible. That means that every operation done on the primary goes to the second and no other operations can be done on the secondary or the LSNs and internal structure will no longer match.
For a secondary server that has a different schema and is not log-sequence identical with your primary, you're looking for one of the replication forms, transactional most likely. That allows for as many different replicas as you like, with different indexing structures, possibly even different subsets of the data, with rollup and aggregation tables, different stored procs and views, etc.
Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass
Post #1410914
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
