Moving a Full-Text Catalog from a single server to a Cluster

Hi,
I was wondering if anyone could point me in the right direction with a
problem I'm having moving a full-text catalog from one server to
another.
In a nutshell, I want to take a database with full-text indexing
enabled and move it and the catalog to a new server. The existing
system is a single server build but the new one will be clustered in
an active/passive configuration which complicates things a little.
Obviously I've read and tried the instructions in Q240867 but this
doesnt seem to have worked and a full population starts as soon as I
enable the funtionality again (so either I'm doing something wrong or
it's not possible to do it).
I've tried to follow the instructions on each of the nodes in the
cluster and on the virtual server but it doesnt seem to work.
Any help anyone can give me in this would be really appreciated.
Regards,
Mike
Are the database IDs identical on the server you are moving the catalogs to?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Mike" <mike.metcalf@.4projects.com> wrote in message
news:678e073d.0410180336.37c55f97@.posting.google.c om...
> Hi,
> I was wondering if anyone could point me in the right direction with a
> problem I'm having moving a full-text catalog from one server to
> another.
> In a nutshell, I want to take a database with full-text indexing
> enabled and move it and the catalog to a new server. The existing
> system is a single server build but the new one will be clustered in
> an active/passive configuration which complicates things a little.
> Obviously I've read and tried the instructions in Q240867 but this
> doesnt seem to have worked and a full population starts as soon as I
> enable the funtionality again (so either I'm doing something wrong or
> it's not possible to do it).
> I've tried to follow the instructions on each of the nodes in the
> cluster and on the virtual server but it doesnt seem to work.
> Any help anyone can give me in this would be really appreciated.
> Regards,
> Mike
|||Hi Hillary,
I've had a look and the DBID's are the same (I thought they were but
it's always worth double-checking), the only thing that should be
diffent is that the new build will be clustered (the old one isnt) and
the FTDATA directory is being moved from the c: to the shared d: (I've
updated the registry keys to reflect the new location)
What I'm really looking for is someone to tell me where I need to apply
the registry settings I took on the original system to (node 1, node 2,
virtual server, virtual SQL Server or some mix of everything), or
failing that if someone could say if and why it wasn't possible (I'm
fairly sure it is) that would be ok too.
There's probably something different (or extra) that needs doing on a
clustered installation that hasnt been documented yet.
Mike
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||Mike,
I researched and wrote the original KB article Q240867 (before it was
modified for SP3) and because you're moving from a non-clustered environment
to a clustered environment, this modified KB article's cluster related
procedures assumes that you are already in a clustered environment before
moving or copying the FT Catalog folder & files.
I'd recommend that you review KB article 812666 - "How to recover a failed
full-text search resource on a clustered instance of SQL Server 2000" at
http://support.microsoft.com/default.aspx?kbid=812666 if re-installation of
FTS is required. If not, I'd recommend that you consider setting up your
clustered environment first and then copy over the SQL000<dbid>000<ftcatid>
folder assuming the same dibd & ftcatid is on your clustered environment. If
this is not possible, then you most likely will have to run a Full
Population and take the hit on a long population period as I'm assuming that
is why you are copying to the new build from the old non-clustered build.
Regards,
John
"Mike Metcalf" <mike.metcalf@.4projects.com> wrote in message
news:uSzxk0StEHA.1400@.TK2MSFTNGP11.phx.gbl...
> Hi Hillary,
> I've had a look and the DBID's are the same (I thought they were but
> it's always worth double-checking), the only thing that should be
> diffent is that the new build will be clustered (the old one isnt) and
> the FTDATA directory is being moved from the c: to the shared d: (I've
> updated the registry keys to reflect the new location)
> What I'm really looking for is someone to tell me where I need to apply
> the registry settings I took on the original system to (node 1, node 2,
> virtual server, virtual SQL Server or some mix of everything), or
> failing that if someone could say if and why it wasn't possible (I'm
> fairly sure it is) that would be ok too.
> There's probably something different (or extra) that needs doing on a
> clustered installation that hasnt been documented yet.
> Mike
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!
|||Hi John,
Thanks for your suggestions, I had a look at the article over the
weekend and a combination of the two led me to the correct solution,
I've tested it 3 times and it's worked each time so I know it's not a
fluke.
Thanks again,
Mike
*** Sent via Developersdex http://www.codecomments.com ***
Don't just participate in USENET...get rewarded for it!
|||You're welcome, Mike,
I guess a little bit of persistence goes a long way!
John
"Mike Metcalf" <mike.metcalf@.4projects.com> wrote in message
news:#49OMjmuEHA.2832@.tk2msftngp13.phx.gbl...
> Hi John,
> Thanks for your suggestions, I had a look at the article over the
> weekend and a combination of the two led me to the correct solution,
> I've tested it 3 times and it's worked each time so I know it's not a
> fluke.
> Thanks again,
> Mike
> *** Sent via Developersdex http://www.codecomments.com ***
> Don't just participate in USENET...get rewarded for it!
>
sql

moving a database to another physical disk

I want to move 2 databases to another physical disk. They are both single file databases. It looks like a fairly straigtforward attach and detach procedure, but I have a couple of questions:

The log files (.ldf) currently reside on a separate physical disk from the data files, if I attach and reattach the data files will the logs remain where they are by default or do I have to re specify there location?

Is there any advantage to running the update statistics portion of the sp_detach_db?with the re-attach procedure you can specify the location of the log file as well. See the article in BOL and this is probably the quickest method. However the same thing can be done with backup and restore using the with move and replace arguments.

move/upgrade MSDE to SQL 2000

Need some help with moving/upgrading 3 MSDE databases (stored locally on 3 different servers) to a single SQL 2000 server (new instance). Can this be done? If so, how??

Thanks for any responsesStop the MSSQL service. Find the MDF and LDF files (C:\Program Files\Microsoft SQL Server\MSSQL\Data\ ) and copy them to the SQL Server. Then attach the databases on the destination. Watch not to overlay any MDF/LDF files on the destination server.sql

Move Row from One table to Another

Hi,
Is there any way i can move a single row to from one table to another [same database].
Basically what i am trying to achive is this. I allow the user to delete a row, but instead of actuall deleting the row, i want to place it into another table [like a recycle bin], which can be restored later.

I know i can simply use insert into statement to add it to the 2nd table and perform the delete statement on table1, but it becomes very tedious becaus there are a lot of fields in my table. I am looking for some other efficient way, if its possible at all.

Any ideas and help is appriciated.

Thanks

DanialOriginally posted by Danial
Hi,
Is there any way i can move a single row to from one table to another [same database].
Basically what i am trying to achive is this. I allow the user to delete a row, but instead of actuall deleting the row, i want to place it into another table [like a recycle bin], which can be restored later.

I know i can simply use insert into statement to add it to the 2nd table and perform the delete statement on table1, but it becomes very tedious becaus there are a lot of fields in my table. I am looking for some other efficient way, if its possible at all.

Any ideas and help is appriciated.

Thanks

Danial

I think the only way to do this to do something like this:

INSERT INTO table2 SELECT * FROM table1 where row = row id.

this will allow you to select all fields without having to type them all. I think this is the most efficent way.|||Thanks, Thats exactly what i was looking for.

Danial

move msdb

I am getting following error when moving msdb database to different drive.

“SQL SERVER is in SINGLE USER MODE and only one administrator can connect”

I followed steps menthioned in http://support.microsoft.com/kb/224071

Also, it was mentioned that even object browser is also one connection- http://deepakinsql.blogspot.com/2007/08/moving-system-databases-in-sql-2005.html , so I closed that but didn't work.

I am using SQL 2005 Enterprise non clustered with no service pack on windows 2003 server

Did anybody faced this problem and found any solution.

thanks,

Hi
This will help.
http://support.microsoft.com/kb/224071#
|||

I used the same KB article but still getting the error.

Thanks,

|||May be this help?
Stop the SQL Server Agent service before connecting to an instance of SQL Server in single-user mode; otherwise, the SQL Server Agent service uses the connection, thereby blocking it.
|||

After adding ;–c;-m;-T3608 at the end of starup, restart came with SQL Agent not running. So SQL Agent is not running . Moreover I stopped other services like sql browser , Integration service , Analysis service to make sure nobody is connecting. Can I see who is using administrator connection to figure out where it is getting used?

Thanks,

|||STOP SQL SERVICES.
START SQL FROM command prompt

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn>sqlservr.exe -m
Connect using SQL Management Studio.
|||I have tested above method and it is working on my SQL server 2005 developer edition.

Moving indexes from a filegroup to another

Hi,
I have a 65 Gb database stored on a single filegroup and I would like
to move non-clustered indexes to another filegroup.
I'm thinking of the following process:
_ Backup initial database
_ Create new empty database with two filegroups (one for data, one
for indexes) (the database is created by a software that defines all
the objects on a single filegroup)
_ Moving indexes (definition) from a filegroup to another while the
database is empty.
_ Restore data and indexes from the previous backup so that data go
the data filegroup and indexes go to the indexes filegroup.
Another solution would be to drop the indexes and recreate them on the
new filegroup but moving 65 Gb will probably take a very long time.
Any ideas ?
Thanks !> I have a 65 Gb database stored on a single filegroup and I would like
> to move non-clustered indexes to another filegroup.
The only index you can move is the clustered index (which effectively takes
the table and all the non-clustered indexes with it). You can do this by
dropping the clustered index and re-creating it on the new filegroup, by
using ON <filegroup>.|||If you want to separate the data (Heaps & Clustered indexes) from the
non-clustered indexes you will need to drop the non-clustered indexes and
recreate them on the new filegroup. YOu won't move all 65GB since the table
itself should be the majority of the data. There is no need to restore
anything.
Andrew J. Kelly SQL MVP
<florent.jeannot@.gmail.com> wrote in message
news:1139511741.514031.76310@.o13g2000cwo.googlegroups.com...
> Hi,
> I have a 65 Gb database stored on a single filegroup and I would like
> to move non-clustered indexes to another filegroup.
> I'm thinking of the following process:
> _ Backup initial database
> _ Create new empty database with two filegroups (one for data, one
> for indexes) (the database is created by a software that defines all
> the objects on a single filegroup)
> _ Moving indexes (definition) from a filegroup to another while the
> database is empty.
> _ Restore data and indexes from the previous backup so that data go
> the data filegroup and indexes go to the indexes filegroup.
> Another solution would be to drop the indexes and recreate them on the
> new filegroup but moving 65 Gb will probably take a very long time.
> Any ideas ?
> Thanks !
>|||Thanks Andrew. That was my first thought, but actually I was wondering
whether there would be a faster way to do it.