Monday, March 26, 2012
Offline Reporting DB...
data in a second DB on a second server for reporting use only. We think
replication is overkill since they won't mind if the data is a day or two
old.
I like the idea of simply restoring their most recent full backup on the
reporting server, but I'm not sure if they do a full backup every night.
What are other approaches that folks use to accomplish this sort of thing?
Log shipping doesn't seem right; replication seems like overkill. DTS
possibly? Any thoughts, links, or words will be greatly appreciated!
Thanks in advance for your time,
James Hunter RossWithout details about the database size, your connection bandwidth, etc.,
it's hard to say what is the best way for your needs.
If the customer can tolerate data two days old, you can use snapshot
replication and set the snapshot interval as 48 hours. Yuo can also make use
of log shipping secondary server with restored databases being in read-only
mode. Then users can run reports off the databases from time to time. The
inconvenience with log shipping is to regularly kick users out of the
database so that restore of transaction logs can go on. The third option
will be increase full backup frequency so that there is a full backup every
two days, otherwise you will have to restore from a full backup more than 2
days ago and apply all subsequent transaction logs.
Other things you can consider: will copy database wizard apply? It requires
the database being shut down.
Richard
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining
>data in a second DB on a second server for reporting use only. We think
>replication is overkill since they won't mind if the data is a day or two
>old.
> I like the idea of simply restoring their most recent full backup on the
> reporting server, but I'm not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
> Log shipping doesn't seem right; replication seems like overkill. DTS
> possibly? Any thoughts, links, or words will be greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>|||Keep it simple, if possible. Backup restore is as simple as it gets, and you get your backups tested
each time.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining data in a second DB on a
>second server for reporting use only. We think replication is overkill since they won't mind if
>the data is a day or two old.
> I like the idea of simply restoring their most recent full backup on the reporting server, but I'm
> not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing? Log shipping doesn't
> seem right; replication seems like overkill. DTS possibly? Any thoughts, links, or words will be
> greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>|||We use log shipping for this as our main DB is too large to restore nightly.
Works well.
Mike Kruchten
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining
>data in a second DB on a second server for reporting use only. We think
>replication is overkill since they won't mind if the data is a day or two
>old.
> I like the idea of simply restoring their most recent full backup on the
> reporting server, but I'm not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
> Log shipping doesn't seem right; replication seems like overkill. DTS
> possibly? Any thoughts, links, or words will be greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>
Offline Reporting DB...
data in a second DB on a second server for reporting use only. We think
replication is overkill since they won't mind if the data is a day or two
old.
I like the idea of simply restoring their most recent full backup on the
reporting server, but I'm not sure if they do a full backup every night.
What are other approaches that folks use to accomplish this sort of thing?
Log shipping doesn't seem right; replication seems like overkill. DTS
possibly? Any thoughts, links, or words will be greatly appreciated!
Thanks in advance for your time,
James Hunter Ross
Without details about the database size, your connection bandwidth, etc.,
it's hard to say what is the best way for your needs.
If the customer can tolerate data two days old, you can use snapshot
replication and set the snapshot interval as 48 hours. Yuo can also make use
of log shipping secondary server with restored databases being in read-only
mode. Then users can run reports off the databases from time to time. The
inconvenience with log shipping is to regularly kick users out of the
database so that restore of transaction logs can go on. The third option
will be increase full backup frequency so that there is a full backup every
two days, otherwise you will have to restore from a full backup more than 2
days ago and apply all subsequent transaction logs.
Other things you can consider: will copy database wizard apply? It requires
the database being shut down.
Richard
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining
>data in a second DB on a second server for reporting use only. We think
>replication is overkill since they won't mind if the data is a day or two
>old.
> I like the idea of simply restoring their most recent full backup on the
> reporting server, but I'm not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
> Log shipping doesn't seem right; replication seems like overkill. DTS
> possibly? Any thoughts, links, or words will be greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>
|||Keep it simple, if possible. Backup restore is as simple as it gets, and you get your backups tested
each time.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining data in a second DB on a
>second server for reporting use only. We think replication is overkill since they won't mind if
>the data is a day or two old.
> I like the idea of simply restoring their most recent full backup on the reporting server, but I'm
> not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing? Log shipping doesn't
> seem right; replication seems like overkill. DTS possibly? Any thoughts, links, or words will be
> greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>
|||We use log shipping for this as our main DB is too large to restore nightly.
Works well.
Mike Kruchten
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining
>data in a second DB on a second server for reporting use only. We think
>replication is overkill since they won't mind if the data is a day or two
>old.
> I like the idea of simply restoring their most recent full backup on the
> reporting server, but I'm not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
> Log shipping doesn't seem right; replication seems like overkill. DTS
> possibly? Any thoughts, links, or words will be greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>
Offline Reporting DB...
data in a second DB on a second server for reporting use only. We think
replication is overkill since they won't mind if the data is a day or two
old.
I like the idea of simply restoring their most recent full backup on the
reporting server, but I'm not sure if they do a full backup every night.
What are other approaches that folks use to accomplish this sort of thing?
Log shipping doesn't seem right; replication seems like overkill. DTS
possibly? Any thoughts, links, or words will be greatly appreciated!
Thanks in advance for your time,
James Hunter RossWithout details about the database size, your connection bandwidth, etc.,
it's hard to say what is the best way for your needs.
If the customer can tolerate data two days old, you can use snapshot
replication and set the snapshot interval as 48 hours. Yuo can also make use
of log shipping secondary server with restored databases being in read-only
mode. Then users can run reports off the databases from time to time. The
inconvenience with log shipping is to regularly kick users out of the
database so that restore of transaction logs can go on. The third option
will be increase full backup frequency so that there is a full backup every
two days, otherwise you will have to restore from a full backup more than 2
days ago and apply all subsequent transaction logs.
Other things you can consider: will copy database wizard apply? It requires
the database being shut down.
Richard
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining
>data in a second DB on a second server for reporting use only. We think
>replication is overkill since they won't mind if the data is a day or two
>old.
> I like the idea of simply restoring their most recent full backup on the
> reporting server, but I'm not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
> Log shipping doesn't seem right; replication seems like overkill. DTS
> possibly? Any thoughts, links, or words will be greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>|||Keep it simple, if possible. Backup restore is as simple as it gets, and you
get your backups tested
each time.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining da
ta in a second DB on a
>second server for reporting use only. We think replication is overkill sin
ce they won't mind if
>the data is a day or two old.
> I like the idea of simply restoring their most recent full backup on the r
eporting server, but I'm
> not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
Log shipping doesn't
> seem right; replication seems like overkill. DTS possibly? Any thoughts,
links, or words will be
> greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>|||We use log shipping for this as our main DB is too large to restore nightly.
Works well.
Mike Kruchten
"James Hunter Ross" <james.ross@.oneilsoft.com> wrote in message
news:OYhK%23KdcFHA.3828@.tk2msftngp13.phx.gbl...
>A customer of ours was considering replication as a means of maintaining
>data in a second DB on a second server for reporting use only. We think
>replication is overkill since they won't mind if the data is a day or two
>old.
> I like the idea of simply restoring their most recent full backup on the
> reporting server, but I'm not sure if they do a full backup every night.
> What are other approaches that folks use to accomplish this sort of thing?
> Log shipping doesn't seem right; replication seems like overkill. DTS
> possibly? Any thoughts, links, or words will be greatly appreciated!
> Thanks in advance for your time,
> James Hunter Ross
>sql
Offline Data Mining
Hi,
I am currently working for a client that is interested in performing some data mining on their customer data. The plan was to build a data warehouse, cubes, RS reports etc. and serve this up over the web.
However, we now have the problem of having to cater for countries with a very low bandwidth where the Reporting Services approach would not deliver the required performance due to the dependency of the solution on the network bandwith.
I am therefore looking into processing offline cubes and copying them over the network as part of the overnight process to a server in the countries.
I noticed that PivotTable Services in 2000 had the CREATE MINING MODEL ...... DDL statement for creating offline mining models.
Is this capability still there with SSAS 2005?
Can anyone post any links to usefull resources on this subject?
Thanks in advance.
There a couple of ways to deal with offline scenarios:
1. AS 2005 does support creation of local mining models if you are connected to a .cub file (in the "local" mode formerly known as PivotTable Services) through the MSOLAP.3 OLE DB provider. Only the Decision Trees and Clustering algorithms are supported in this case. You can then export these models individually, ship the files over to your server and import them back into your server. See http://www.sqlserverdatamining.com/DMCommunity/TipsNTricks/129.aspx for more details.
2. If the clients have AS 2005 Standard Edition, they can create models using all algorithms and export as described above. In addition, you can also export server models, ship them over to the client and import them back in, allowing local querying without going over the network.
|||Yes, the capability is still there in SQL Server 2005.
This page contains some information about client scenarios with Analysis Services 2005, including local mining models: http://msdn2.microsoft.com/en-us/library/ms174518.aspx
More details specific for working with local mining models: http://msdn2.microsoft.com/en-us/library/ms345148.aspx#sqldmprgrm_topic7
The local mining models are limited in functionality. Major limitations:
- only 2 algorithms are supported (decision trees and clustering)
- BI Dev Studio cannot be used to explore local mining models
- server models cannot be exported and then imported in local cubes
|||Good stuff. Thanks for the help guys.sql