I'm having a problem with the full text index rebuild process. Previously
when I did a full rebuild the process stopped, then the server rebooted and
the rebuild started over and completed. I had hoped this was just a fluke
but this last time I set up an indexing job to run at 2 am and the same
thing happened. About an hour into the rebuild the server reboots, then
restarts and the job restarts and takes about two hours to complete.
@.@.version:
Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
The server is a Compaq 5500 proliant with 1/2 gig of RAM, the main drive is
RAID 5 with the logs on a smaller RAID 0 drive.
In looking at the logs the only thing I found that I thought were relevant -
except the entries where the server comes online and looks for transactions
to rollback - were these:
Project <SQLServer$SERIALS_SQL SQL0000900005> has been shut down as
requested by user
and
Compaq System Information Agent: Compaq Health: The server is
operational again, the server has previously been shutdown by the Automatic
Server Recovery (ASR) featuer and has just become operational again. [SNMP
TRAP: 6025 in CPQHLTH.MIB]
The indexed tables are not extremely large, about 250,000 records each. One
of the indexed fields is 5,000 characters long, but I wouldn't think that
would be a problem.
Has anyone seen this before? I am going to pursue the compaq automatic
server recovery feature and see if that yeilds any clues, but I was hoping
someone else had run into this and had a hint or two to share.
Thanks in advance;
David Craig
ABC-CLIO
"DCraig" <dcraig@.nospam.com> wrote in message
news:OD1VNjsNEHA.3420@.TK2MSFTNGP11.phx.gbl...
> I'm having a problem with the full text index rebuild process. Previously
> when I did a full rebuild the process stopped, then the server rebooted
and
> the rebuild started over and completed. I had hoped this was just a fluke
> but this last time I set up an indexing job to run at 2 am and the same
> thing happened. About an hour into the rebuild the server reboots, then
> restarts and the job restarts and takes about two hours to complete.
> @.@.version:
> Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05
> Copyright (c) 1988-2003 Microsoft Corporation
> Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)
> The server is a Compaq 5500 proliant with 1/2 gig of RAM, the main drive
is
> RAID 5 with the logs on a smaller RAID 0 drive.
Correction, the logs are on a mirrored (RAID 1) drive.
|||DCraig,
It is not a common occurrence that running a Full Population (full rebuild)
will cause a server reboot to occur.
Could you review your System Event log for any low free disk space available
on either your system disk (usually c:\ drive) or the drive array where you
have placed the FT Catalogs. Again this is not common, but one think to keep
in mind is that the MSSearch service requires that at least 15% of disk
space always be available on the disk drive where the FT Catalog resides as
well as enough disk space on the system drive to write tmp files when FT
Indexing MS Word document files.
Also, search your Application event log for any MssCi source events
(warnings & errors) and post them here.
Regards,
John
"DCraig" <dcraig@.nospam.com> wrote in message
news:OtGCZctNEHA.1908@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> "DCraig" <dcraig@.nospam.com> wrote in message
> news:OD1VNjsNEHA.3420@.TK2MSFTNGP11.phx.gbl...
Previously[vbcol=seagreen]
> and
fluke
> is
> Correction, the logs are on a mirrored (RAID 1) drive.
>
|||"John Kane" <jt-kane@.comcast.net> wrote in message
news:%23d9nsWwNEHA.2708@.TK2MSFTNGP11.phx.gbl...
> DCraig,
> It is not a common occurrence that running a Full Population (full
rebuild)
> will cause a server reboot to occur.
> Could you review your System Event log for any low free disk space
available
> on either your system disk (usually c:\ drive) or the drive array where
you
> have placed the FT Catalogs. Again this is not common, but one think to
keep
> in mind is that the MSSearch service requires that at least 15% of disk
> space always be available on the disk drive where the FT Catalog resides
as
> well as enough disk space on the system drive to write tmp files when FT
> Indexing MS Word document files.
>
John, thanks for your reply. The array with the full text index (also the
same as sql server and the data files) has 50 gigs free of 62.
Here are the system log entries, nothing before the server starts coming
back up:
5/9/2004 3:01:12 AM Server Agents Information Events 1090 N/A SERVER8
Compaq System Information Agent: Compaq Health: The server is operational
again. The server has previously been shutdown by the Automatic Server
Recovery (ASR) feature and has just become operational again.
[SNMP TRAP: 6025 in CPQHLTH.MIB]
5/9/2004 3:00:42 AM Foundation Agents Information Service 400 N/A SERVER8
The Compaq Foundation Agents service version 5.00 has started.
5/9/2004 3:00:39 AM SNMP Information None 1001 N/A SERVER8 The SNMP Service
has started successfully.
5/9/2004 3:00:38 AM Storage Agents Information Service 400 N/A SERVER8 The
Compaq Storage Agents service version 5.00 has started.
5/9/2004 3:00:37 AM Server Agents Information Service 400 N/A SERVER8 The
Compaq Server Agents service version 5.00 has started.
5/9/2004 3:00:36 AM NIC Agents Information Service 277 N/A SERVER8 The
Compaq NIC Management Agent version 5.00 has started.
5/9/2004 3:00:17 AM EventLog Information None 6005 N/A SERVER8 The Event log
service was started.
5/9/2004 3:00:17 AM EventLog Information None 6009 N/A SERVER8 Microsoft (R)
Windows 2000 (R) 5.0 2195 Service Pack 4 Multiprocessor Free.
5/9/2004 3:00:17 AM EventLog Error None 6008 N/A SERVER8 The previous system
shutdown at 2:42:16 AM on 5/9/2004 was unexpected.
So far I haven't been able to figure out if the automatic server recovery is
the cause or effect of the reboot.
> Also, search your Application event log for any MssCi source events
> (warnings & errors) and post them here.
Here are the application event log entries with MssCi in them:
5/9/2004 4:57:08 AM MssCi Information None 4103 N/A SERVER8 Master merge has
completed on
d:\mssql2000_data\mssql\data\mssql$serials_sql\ftd ata\sql0000900005\build\in
dexer\cifiles.
5/9/2004 3:04:24 AM MssCi Information None 4138 N/A SERVER8 Content index
corruption detected in component SmartBuffer1 in catalog
d:\mssql2000_data\mssql\data\mssql$serials_sql\ftd ata\sql0000900005\build\in
dexer\cifiles. Stack trace is 0x01165041
0x011DAD4B
0x011DADEE
0x011D8D45
0x011E8DED
0x011E57F0
0x011DF5F7
0x011DFD10
0x7C57438B
..
I noticed there were some virus definitions being downloaded about the same
time, could that have anything to do with it? I suppose I could turn off
live update while the index is being rebuilt but these days timely virus
protection is pretty important.
I'm assuming the corruption above is the result of the server rebooting
during indexing, as I said after that it went ahead and built the indexes
successfully. If I hadn't checked the logs I would have thought all was
well.
Thanks again for your help,
David Craig.
[vbcol=seagreen]
> Regards,
> John
>
> "DCraig" <dcraig@.nospam.com> wrote in message
> news:OtGCZctNEHA.1908@.TK2MSFTNGP12.phx.gbl...
> Previously
rebooted[vbcol=seagreen]
> fluke
same[vbcol=seagreen]
then[vbcol=seagreen]
14:22:05[vbcol=seagreen]
drive
>
|||DCraig,
The error "Content index corruption detected in component SmartBuffer1 in
catalog" could be the source of your re-boot, depending upon how you have
your Compaq Info Agents setup. The error by itself should not (and normally
does not) re-boot the server.. You should place a support call with
Microsoft PSS SQL Server support to identify the source of this error and
get it resolved first.
I doubt if the virus definitions being downloaded about the same time is a
cause, but if you can turn off the definition download (and not the virus
protection) briefly (for a day or two), and continue to run your Full
Population, this should determine if this is involved with the above error
as well.
Regards,
John
"DCraig" <dcraig@.nospam.com> wrote in message
news:#TTLvE4NEHA.1616@.TK2MSFTNGP12.phx.gbl...
> "John Kane" <jt-kane@.comcast.net> wrote in message
> news:%23d9nsWwNEHA.2708@.TK2MSFTNGP11.phx.gbl...
> rebuild)
> available
> you
> keep
> as
> John, thanks for your reply. The array with the full text index (also the
> same as sql server and the data files) has 50 gigs free of 62.
> Here are the system log entries, nothing before the server starts coming
> back up:
> 5/9/2004 3:01:12 AM Server Agents Information Events 1090 N/A SERVER8
> Compaq System Information Agent: Compaq Health: The server is operational
> again. The server has previously been shutdown by the Automatic Server
> Recovery (ASR) feature and has just become operational again.
> [SNMP TRAP: 6025 in CPQHLTH.MIB]
> 5/9/2004 3:00:42 AM Foundation Agents Information Service 400 N/A SERVER8
> The Compaq Foundation Agents service version 5.00 has started.
> 5/9/2004 3:00:39 AM SNMP Information None 1001 N/A SERVER8 The SNMP
Service
> has started successfully.
> 5/9/2004 3:00:38 AM Storage Agents Information Service 400 N/A SERVER8
The
> Compaq Storage Agents service version 5.00 has started.
> 5/9/2004 3:00:37 AM Server Agents Information Service 400 N/A SERVER8 The
> Compaq Server Agents service version 5.00 has started.
> 5/9/2004 3:00:36 AM NIC Agents Information Service 277 N/A SERVER8 The
> Compaq NIC Management Agent version 5.00 has started.
> 5/9/2004 3:00:17 AM EventLog Information None 6005 N/A SERVER8 The Event
log
> service was started.
> 5/9/2004 3:00:17 AM EventLog Information None 6009 N/A SERVER8 Microsoft
(R)
> Windows 2000 (R) 5.0 2195 Service Pack 4 Multiprocessor Free.
> 5/9/2004 3:00:17 AM EventLog Error None 6008 N/A SERVER8 The previous
system
> shutdown at 2:42:16 AM on 5/9/2004 was unexpected.
> So far I haven't been able to figure out if the automatic server recovery
is
> the cause or effect of the reboot.
>
> Here are the application event log entries with MssCi in them:
> 5/9/2004 4:57:08 AM MssCi Information None 4103 N/A SERVER8 Master merge
has
> completed on
>
d:\mssql2000_data\mssql\data\mssql$serials_sql\ftd ata\sql0000900005\build\in
> dexer\cifiles.
> 5/9/2004 3:04:24 AM MssCi Information None 4138 N/A SERVER8 Content index
> corruption detected in component SmartBuffer1 in catalog
>
d:\mssql2000_data\mssql\data\mssql$serials_sql\ftd ata\sql0000900005\build\in
> dexer\cifiles. Stack trace is 0x01165041
> 0x011DAD4B
> 0x011DADEE
> 0x011D8D45
> 0x011E8DED
> 0x011E57F0
> 0x011DF5F7
> 0x011DFD10
> 0x7C57438B
> .
> I noticed there were some virus definitions being downloaded about the
same
> time, could that have anything to do with it? I suppose I could turn off
> live update while the index is being rebuilt but these days timely virus
> protection is pretty important.
> I'm assuming the corruption above is the result of the server rebooting
> during indexing, as I said after that it went ahead and built the indexes
> successfully. If I hadn't checked the logs I would have thought all was
> well.
> Thanks again for your help,
> David Craig.
> rebooted
> same
> then
> 14:22:05
> drive
>
|||"John Kane" <jt-kane@.comcast.net> wrote in message
news:%23STaYl9NEHA.3816@.TK2MSFTNGP12.phx.gbl...
> DCraig,
> The error "Content index corruption detected in component SmartBuffer1 in
> catalog" could be the source of your re-boot, depending upon how you have
> your Compaq Info Agents setup. The error by itself should not (and
normally
> does not) re-boot the server.. You should place a support call with
> Microsoft PSS SQL Server support to identify the source of this error and
> get it resolved first.
>
I'll try that, thanks.
> I doubt if the virus definitions being downloaded about the same time is a
> cause, but if you can turn off the definition download (and not the virus
> protection) briefly (for a day or two), and continue to run your Full
> Population, this should determine if this is involved with the above error
> as well.
>
That is worth a try also, thanks for your time and effort.
David Craig.
[vbcol=seagreen]
> Regards,
> John
>
>
> "DCraig" <dcraig@.nospam.com> wrote in message
> news:#TTLvE4NEHA.1616@.TK2MSFTNGP12.phx.gbl...
where[vbcol=seagreen]
to[vbcol=seagreen]
disk[vbcol=seagreen]
resides[vbcol=seagreen]
FT[vbcol=seagreen]
the[vbcol=seagreen]
operational[vbcol=seagreen]
SERVER8[vbcol=seagreen]
> Service
> The
The[vbcol=seagreen]
> log
> (R)
> system
recovery
> is
> has
>
d:\mssql2000_data\mssql\data\mssql$serials_sql\ftd ata\sql0000900005\build\in[vbcol=seagreen]
index
>
d:\mssql2000_data\mssql\data\mssql$serials_sql\ftd ata\sql0000900005\build\in[vbcol=seagreen]
> same
off[vbcol=seagreen]
indexes[vbcol=seagreen]
a[vbcol=seagreen]
reboots,[vbcol=seagreen]
complete.
>
|||You have hopefully already found the answer, but if not, read this...
http://forums1.itrc.hp.com/service/f...hreadId=565419
It may be the same problem.
Stuart Bowen
Bandicoot Limited
Business and Internet Solutions
www.bandicoot.co.uk
没有评论:
发表评论