In the enterprise version of SQL there is the facility to do snapshot
replication which I have not tried.
How does this differ from snapshot replication?
What this does is capture a point in time image of a database which you can
connect to as a different database.
Database snapshots are local to the database and uses up considerable disk
space. Snapshot replication can replicate locally and/or remote. It can
replicate to multiple subscribers.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"PromisedOyster" <PromisedOyster@.hotmail.com> wrote in message
news:1170891510.578187.22220@.v33g2000cwv.googlegro ups.com...
> In the enterprise version of SQL there is the facility to do snapshot
> replication which I have not tried.
> How does this differ from snapshot replication?
>
|||Thanks Hilary
My client is considering using mirroring for fault tolerance under SQL
Server 2005 but they also require a version of the database that is
reasonably up to date for reporting purposes. They dont have the
Enterprise version of SQL, so I was wondering if mirroring and then
doing snapshot replication (from the mirror) would be a viable
solution. I suspect not as the database would be unavailable for too
long. In addition, I am not even sure if this is an available option.
NB: They are unable to use transactional or merge replication due to
the tables not having primary keys.
I know that snapshot replication can be extremely slow but I am not
sure how much faster database snapshots are? In addition, when you do
them, can you simply overwrite the previous one as you dont want the
clients to have to access a different database?
Bottom line, is it a viable solution to make multiple database
snapshots during the course of a production day (from the mirror)?
I dont want to propose going to Enterprise version if it isnt going to
work.
On Feb 8, 12:29 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> What this does is capture a point in time image of a database which you can
> connect to as a different database.
> Database snapshots are local to the database and uses up considerable disk
> space. Snapshot replication can replicate locally and/or remote. It can
> replicate to multiple subscribers.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "PromisedOyster" <PromisedOys...@.hotmail.com> wrote in message
> news:1170891510.578187.22220@.v33g2000cwv.googlegro ups.com...
>
>
> - Show quoted text -
|||One problem, you can't do snapshot replication off a mirror.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"PromisedOyster" <PromisedOyster@.hotmail.com> wrote in message
news:1170908921.373111.263690@.v33g2000cwv.googlegr oups.com...
> Thanks Hilary
> My client is considering using mirroring for fault tolerance under SQL
> Server 2005 but they also require a version of the database that is
> reasonably up to date for reporting purposes. They dont have the
> Enterprise version of SQL, so I was wondering if mirroring and then
> doing snapshot replication (from the mirror) would be a viable
> solution. I suspect not as the database would be unavailable for too
> long. In addition, I am not even sure if this is an available option.
> NB: They are unable to use transactional or merge replication due to
> the tables not having primary keys.
> I know that snapshot replication can be extremely slow but I am not
> sure how much faster database snapshots are? In addition, when you do
> them, can you simply overwrite the previous one as you dont want the
> clients to have to access a different database?
> Bottom line, is it a viable solution to make multiple database
> snapshots during the course of a production day (from the mirror)?
> I dont want to propose going to Enterprise version if it isnt going to
> work.
> On Feb 8, 12:29 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
>
|||Thanks, well I guess I can rule out snapshot replication.
However, what about database snapshots. How feasible is it to take
them once every half hour (say) and overwrite the existing one and
then use that as the reporting database server?
On Feb 8, 8:18 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> One problem, you can't do snapshot replication off a mirror.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "PromisedOyster" <PromisedOys...@.hotmail.com> wrote in message
> news:1170908921.373111.263690@.v33g2000cwv.googlegr oups.com...
>
>
>
>
>
>
>
>
>
> - Show quoted text -
Showing posts with label version. Show all posts
Showing posts with label version. Show all posts
Tuesday, March 27, 2012
Monday, March 19, 2012
Database schema ?
Hi!
I need SQL Script that works on database from 2000 in any higher version and generates FULL database schema. By full I mean all tables, all columns , all references , primary keys, foreing keys, contraints, and so on, with column types and their names. When I've said generates I meant just to display a table with all this features and their names, types and but not SQL that I can use it to regenerate such schema only display information about this schema ( hope it's clear now ).
I've found such script but it works only on SQL Server 2005, is it sth like this written for 2000 ?
Jarod
Its better to use DMO/SMO instead of TSQLFriday, February 17, 2012
Database patching.
Hi Everyone.
The company that I work for have a database, which needs patching every so
often from one version to the next. We've been trying different methods of
upgrading the database from one version to the next. But each idea that
we've tried has been difficult, clunky or just plain stressful. Anyway, in
order to ease the process of patching both Schema and data there must be a
way of doing this which is painless and easy to accomplish.
Does anyone have any suggestions that are worth checking out?
Regards
Colin Dawson
www.cjdawson.com"Colin Dawson" <newsgroups@.cjdawson.com> wrote in message
news:hzWLf.26203$wl.25912@.text.news.blueyonder.co.uk...
> Does anyone have any suggestions that are worth checking out?
Not too sure what your problem is... I do this sort of thing all the time
with nothing more than T-SQL. The only thing you need to be careful of is
making the schema and/or data modifications in the right order...|||Colin Dawson wrote:
> Hi Everyone.
> The company that I work for have a database, which needs patching every so
> often from one version to the next. We've been trying different methods
of
> upgrading the database from one version to the next. But each idea that
> we've tried has been difficult, clunky or just plain stressful. Anyway,
in
> order to ease the process of patching both Schema and data there must be a
> way of doing this which is painless and easy to accomplish.
> Does anyone have any suggestions that are worth checking out?
> Regards
> Colin Dawson
> www.cjdawson.com
What is your existing process and what exactly is the problem? For
incremental fixes one might expect:
- Unit-tested change scripts checked into source control
- Release script compiled from an amalgamation of the change scripts
- Release to a test environment for system and regression testing
- Release to a UAT environment (to include testing by production
support if appropriate)
- Release to production
If you need help compiling and validating the scripts then check out
some software like the RedGate compare tools: www.red-gate.com
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Hi all.
Just to elaborate a little, I'm an architech for a team of 20 developers.
They're always making stored procedure changes and schema changes, basically
the problem is that it's happening so fast that I'm not able to keep up.
What I want to be able to do is skip checking, diagnosing every single
little change, and pile them into one large change script which I can then
check quicker.
Ideally, I really suppose that I'm looking for some kind of Silver Bullet.
I know that there is rarely anything that will solve problems like this.
But there's always hope.
Regards
Colin Dawson
www.cjdawson.com
The company that I work for have a database, which needs patching every so
often from one version to the next. We've been trying different methods of
upgrading the database from one version to the next. But each idea that
we've tried has been difficult, clunky or just plain stressful. Anyway, in
order to ease the process of patching both Schema and data there must be a
way of doing this which is painless and easy to accomplish.
Does anyone have any suggestions that are worth checking out?
Regards
Colin Dawson
www.cjdawson.com"Colin Dawson" <newsgroups@.cjdawson.com> wrote in message
news:hzWLf.26203$wl.25912@.text.news.blueyonder.co.uk...
> Does anyone have any suggestions that are worth checking out?
Not too sure what your problem is... I do this sort of thing all the time
with nothing more than T-SQL. The only thing you need to be careful of is
making the schema and/or data modifications in the right order...|||Colin Dawson wrote:
> Hi Everyone.
> The company that I work for have a database, which needs patching every so
> often from one version to the next. We've been trying different methods
of
> upgrading the database from one version to the next. But each idea that
> we've tried has been difficult, clunky or just plain stressful. Anyway,
in
> order to ease the process of patching both Schema and data there must be a
> way of doing this which is painless and easy to accomplish.
> Does anyone have any suggestions that are worth checking out?
> Regards
> Colin Dawson
> www.cjdawson.com
What is your existing process and what exactly is the problem? For
incremental fixes one might expect:
- Unit-tested change scripts checked into source control
- Release script compiled from an amalgamation of the change scripts
- Release to a test environment for system and regression testing
- Release to a UAT environment (to include testing by production
support if appropriate)
- Release to production
If you need help compiling and validating the scripts then check out
some software like the RedGate compare tools: www.red-gate.com
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Hi all.
Just to elaborate a little, I'm an architech for a team of 20 developers.
They're always making stored procedure changes and schema changes, basically
the problem is that it's happening so fast that I'm not able to keep up.
What I want to be able to do is skip checking, diagnosing every single
little change, and pile them into one large change script which I can then
check quicker.
Ideally, I really suppose that I'm looking for some kind of Silver Bullet.
I know that there is rarely anything that will solve problems like this.
But there's always hope.
Regards
Colin Dawson
www.cjdawson.com
Subscribe to:
Posts (Atom)