SharePoint 錯誤0x80040E14解決（續）

時間 2020-01-10

標籤 sharepoint 錯誤 0x80040e14 解決欄目 Java開源简体版

原文原文鏈接

今天SharePoint再次遇到0x80040E14的錯誤，登錄到服務器上發現又是數據庫膨脹致使系統盤空間滿了，這回與上次狀況（能夠參看這裏）不一樣，緣由引發是因爲SharePoint_Config數據庫的日誌文件膨脹到很大，17G，致使磁盤沒有空間，打開後剩餘空間爲0字節……竟然還能遠程登陸操做數據庫，幸運啊。

解決方案：收縮內容數據庫日誌。

方法一：

USE DatabaseName
GO
DBCC SHRINKFILE(<TransactionLogName>, 1)
BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY
DBCC SHRINKFILE(<TransactionLogName>, 1)

方法二：

BACKUP LOG "SharePoint_Config" WITH NO_LOG

選中某個數據庫點右鍵後，在彈出菜單中選擇任務-收縮-文件在彈出的窗口文件類型中選擇日誌，設置收縮的大小便可。

收縮數據庫日誌文件後，問題解決。

參考資料：

http://social.technet.microsoft.com/forums/en-US/sharepointadmin/thread/daf73588-3031-4e03-9afa-500005e3f47d/

http://www.cnblogs.com/perky_zhou/archive/2004/11/23/67317.html

http://mindsharpblogs.com/bill/archive/2005/01/14/181.aspx

http://www.itpub.net/viewthread.php?tid=1048025

內容：

http://social.technet.microsoft.com/forums/en-US/sharepointadmin/thread/daf73588-3031-4e03-9afa-500005e3f47d/

Sharepoint Config DB size grown to 25 GB

- Alert Me
Pramod Chavan Wednesday, March 26, 2008 4:34 AM
0 votes Vote As Helpful
My sharepoint farms' config DB size has grown to 25 GB leaving no sapce on disc. That to alone Config_log.ldf file is of 24.5 GB.
how can i truncate size of this log DB?
Is there any way to limit the size of Sharepoint Config DB?
Thanks in advance.
Report As Abuse

Reply

Quote

Answers

Moonis Tahir Monday, April 21, 2008 7:41 PM
0 votes Vote As Helpful
Truncate Config DB as a regular SQL transaction log file truncation. it has nothing to do with sharepoint programming forum. however here is how i truncate the log, run these in Query window in SQL
USE DatabaseName
GO
DBCC SHRINKFILE(<TransactionLogName>, 1)
BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY
DBCC SHRINKFILE(<TransactionLogName>, 1)
transaction log name is your config database ldf file name without .ldf extension. database name is your wss config database name.
Report As Abuse

Reply

Quote

All Replies

Pramod Chavan Monday, April 21, 2008 6:24 AM
0 votes Vote As Helpful
anyone please...
Report As Abuse

Reply

Quote

Propose As Answer
Moonis Tahir Monday, April 21, 2008 7:41 PM
0 votes Vote As Helpful
Truncate Config DB as a regular SQL transaction log file truncation. it has nothing to do with sharepoint programming forum. however here is how i truncate the log, run these in Query window in SQL
USE DatabaseName
GO
DBCC SHRINKFILE(<TransactionLogName>, 1)
BACKUP LOG <DatabaseName> WITH TRUNCATE_ONLY
DBCC SHRINKFILE(<TransactionLogName>, 1)
transaction log name is your config database ldf file name without .ldf extension. database name is your wss config database name.
Report As Abuse

Reply

Quote
Pramod Chavan Tuesday, April 22, 2008 5:02 AM
0 votes Vote As Helpful
Thank you for the response.
My apology for putting misleading question.
Actually truncating is not an issue but as my sharepoint config DB is growing to 25 GB in 2-3 days after each time I truncate the DB.And I am not able to figure out how this is happening as I am not doing any major updation on my sharepoint portal. So my problem is how I can set restrictions on Config DB so that it will not grow beyond a limit.
Thanks a lot.
Report As Abuse

Reply

Quote

Propose As Answer
Michael Washam - MSFT MSFT , Moderator Tuesday, April 22, 2008 4:35 PM
0 votes Vote As Helpful
Moving to the admin forum
Report As Abuse

Reply

Quote

Propose As Answer
Dave Wollerman Thursday, April 24, 2008 12:53 AM
0 votes Vote As Helpful
This is happening because all the databases (Except for the search and ssp databases) are set to full recovery mode by default. Full recovery mode does not auto shrink / truncate the log files on a full backup. You can change this to simple recovery mode and it will auto truncate on full backups. Microsoft does not recommend changing to simple recovery mode in a production environment.
Full recovery mode allows the SQL admins to backup the transcation logs incrementally, simple recovery mode does not allow this and only allows full or differential backups, no transaction log backups. I assume you need full recovery mode to do log shipping and mirroring as well.

http://www.cnblogs.com/perky_zhou/archive/2004/11/23/67317.html

部署Sharepoint要注意SQL Server的事務日誌文件

公司的Sharepoint系統用到的數據庫和其餘的應用共享同一個數據庫。在規劃期，因爲缺少經驗，只考慮到了Sharepoint中存儲的內容的大小，根本沒有去考慮Sharepoint數據庫事務的日誌的大小。熟悉Sharepoint的人都知道，windows Sharepoint service v2和Sharepoint portal Server系統中幾乎全部的內容都存放在數據庫中，也就是說，每訪問一次Sharepoint站點，就會發生若干次訪問數據庫的操做，所以，Shaerpoint 數據庫的事務日誌文件長得很是之快。咱們系統中的數據文件不過10個G左右，可是，日誌文件卻達到了近30G。當數據庫的事務日誌滿了之後，許多的應用程序便沒法訪問。
那麼怎麼解決這個問題呢？
首先，咱們在規劃的時候就要考慮到這個問題，因此，建議你們將Sharepoint 數據庫和其餘應用的數據庫放在不一樣的分區內，而且考慮保留足夠的空間來存放日誌。
其次，建議單獨闢出一塊空間來存放日誌。
第三，就是要按期的收縮數據庫。您可使用自動維護任務，可是，有時候自動收縮的效果並非十分的好。那麼，我建議你按期的手工進行收縮。步驟以下：
首先修改數據庫的故障恢復模式爲「簡單」模式，而後，再收縮數據庫，最後，該回標準模式。

http://mindsharpblogs.com/bill/archive/2005/01/14/181.aspx

SQL Databases, the LDF File and SharePoint Portal Server backups

What follows is a long email thread about SQL databases, the size of the LDF File and Backups in portal server. Since this is an email thread, you'll need to start reading from the bottom and work your way to the top. This issue is about the size of the LDF file relative to SharePoint Portal Server and the backup process.

And many thanks to Sara for allowing me to post this here.

----------------------------------------------------------------------

Hi Bill – Feel free to do whatever you’d like with the info. I’m hoping it will eventually work its way into something 「official」 as it’s certainly an issue – especially as the size of the SharePoint databases begins to grow. <snip personal conversation>

Anyways, the end result was that:

(1) I was able to use the assorted tools mentioned to manually shrink the unwieldy sizes of my _SITES logfiles – these were the ones that were WAY out of hand (i.e. database size of 30-40 GB; logfile size of 50+ GB!) – so this does work, and potentially needs to become a part of one’s maintenance plan.

(2) Per Microsoft – there really is no 「rule of thumb」 to guess at what a good logfile size SHOULD be; however, it’s really a moot point now due to the final recommendation for the RECOVERY METHOD.

(3) Per Microsoft – the only supported restore method for SPS is via SPS’s backup/restore tool. It is NOT supported to restore SPS via its restore tool, and then restore some (or all) of the databases to a more current point in time via SQL using backed-up transaction logs. Hence – with SPS there’s no point to having the databases set to FULL RECOVERY at all; SIMPLE RECOVERY provides better performance.

(4) If you have a standalone WSS installation (no SPS), then there are some options for using SQL tools to restore to a more current point in time – depending on your disaster recovery plan, you may or may not want to change the RECOVERY MODE of the WSS DBs.

Some of the actual 「conversation」 with Microsoft:

What size SHOULD the LDF files be for optimal SPS performance?

(came from Microsoft SQL support team)

When you back up an LDF file, you are given the opportunity to specify the new size for this file. If you don't specify a size, SQL will try to compact this file down as small as possible which might be 1 or 2 MB in size. Although this is ideal as far as drive space is concerned, it is NOT ideal for performance with the SQL databases for SharePoint. There is no set formula or rule on how large the LDF file should be, but it should be of an adequate size that will prevent it from having to grow automatically every single day when it reaches its current size limit. For instance, if you state that the new size of the LDF file is going to be 2 GB in size, the initial size of the LDF file will be 2 GB, and it will stay this size until 2GB worth of new transactions have taken place. When this point is reached, the LDF file will grow automatically, and for that short time during its automatic growth, you might see a small performance hit on the SQL Server. This is what needs to be avoided if possible. The SQL Engineer I spoke with stated that if your MDF file was around 30 to 50 GB in size, a 2 to 3 GB LDF file should be more than adequate to start out with, but again there is no hard formula for what the size of the LDF file should be.

Why are some DBs set to FULL RECOVERY and some are not? Is there even any supported SharePoint restore method that uses SharePoint’s RESTORE to restore the full databases; and then a more current Transaction Log restore within SQL to move databases set to FULL RECOVERY to a more current point in time?

(came from Microsoft SPS escalation team)

The reason that the _SITES database is the only database that has Full Recovery Mode enabled is because it is created by Windows SharePoint Services and the other databases are created by SharePoint Portal Server. [Actually – the Config DB is also set to FULL RECOVERY by default – but it stays small.] If you have a standalone deployment of Windows SharePoint services, it is possible to back up the database via SQL and add the data from the transaction logs after the fact. With a SharePoint Portal Server deployment all of the databases must be backed up and restored from the same point in time, so this option is not possible. I believe this is why the Solution Object from our Development Team stated that it would be all right in a Portal deployment to go ahead and change the Recovery method to simple as the only supported restore method is from the Full SQL Backups taken by the SharePoint Portal Data Backup and Restore utility.

Anyway – since I’m a full SPS deployment – my next (and hopefully final!) reconfig task is to set all my databases to SIMPLE RECOVERY for better performance – and this will make the whole logfile size thing a moot point!

Sara

From: Bill English [mailto:bill@mindsharp.com]
Sent: Sunday, January 09, 2005 7:25 PM
To: Sara
Subject: RE: question from an old student

At a minimum, may I turn this into a blog entry? I’ll post it at mindsharpblogs.com, if that would be acceptable to you.

Bill English, MCSE, MCT, MVP

From: Sara
Sent: Thursday, January 06, 2005 11:16 AM
To: Bill English
Subject: RE: question from an old student

I’m hoping that info about the SQL DBs & logfile sizes, maintenance plans, etc. will eventually be documented via KB or whatever for SPS admins (many of whom, like me, are probably NOT SQL DBAs so are somewhat clueless about SQL maintenance… but nevertheless have to deal with it as a part of SPS!).

I’m still muddling things through with PSS – it actually appears that, by default, the PROF & SERV DBs are set to SIMPLE RECOVERY in SQL, while the Config & SITE DBs are set to FULL RECOVERY… which means very different backup/recovery scenarios… which gets very confusing as you then end up (assuming you follow SQL guidelines for frequent & separate backup of the logfiles for the FULL RECOVERY DBs) with the SPS DBs backed up to different points in time: all of them backed up to one point via SPS’s tools, and then the FULL RECOVERY DB logfiles backed up to a more current point in time.

The whole 「logfile backup」 thing is also somewhat separate from the 「shrink the logfiles to manageable sizes」 thing, which was my original question – this task took a series of logfile backups + DBCC SHRINKFILE commands (multiple times) to finally make it work.

I’ll be interested to see what the final recommendations end up being (assuming that there ARE some final recommendations!).

Take care,

Sara

From: Bill English [mailto:bill@mindsharp.com]
Sent: Tuesday, January 04, 2005 7:15 PM
To: Sara
Subject: RE: question from an old student

Thanks for the update, Sara. I’ll be sure to include this in my revised courseware.

Bill English, MCSE, MCT, MVP

From: Sara
Sent: Tuesday, January 04, 2005 4:07 PM
To: Bill English
Subject: RE: question from an old student

Hi again,

I actually ended up with a free case from Microsoft Premier Support, as this is apparently a current issue being tossed around by the SPS & SQL folks.

It appears that:

Although SPS can back up the SQL databases through the builtin backup/restore utility – it can’t really (supportably) affect the behavior of the SQL databases & transaction logs themselves… this has to be configured within SQL.
If SQL 2000 is installed as recommended for SharePoint (which is essentially with default configuration), then the SQL recovery mode is set to FULL RECOVERY, which logs all transactions so the installation can be recovered to the point of failure (and not just to the last backup)… which is a good thing.
Additionally, with SQL 2000 installed as recommended, transaction logs filesize is set to be unlimited… so it just continues to grow.
By default, auto shrink is NOT enabled… which they say is a good thing as auto shrink can’t be scheduled so can kick on at very inopportune times.
When a full backup is successfully completed, the committed transactions are purged from the logfile; however – the filesize itself remains the same as it doesn’t go through a shrink process; hence – the LDF filesize remains at the largest size it’s ever reached.

Current recommendations (which I’m going to try tonight):

Do NOT turn on Auto Shrink for the databases; instead create a scheduled job using the DBCC SHRINKFILE utility (KB272318) to shrink the logfile sizes (can be scheduled within Enterprise Manager using the Mgmt tools).
Leave the SQL RECOVERY MODE at 「Full Recovery」 for all SPS SQL databases; this allows for a restore up to the point of failure.
Be sure to create a scheduled job that backs up the Transaction Logs separate from the SharePoint backups; without the Transaction Logs SQL can’t be restored to the point of failure (can be done within Enterprise Manager using the Mgmt tools).

I’m going to try the steps tonight & see how it goes… it sounds like some recommendations/solutions will eventually work their way into SPS documentation since there are definitely related performance issues as well as disaster recovery issues.

Hope all is well!

Thanks,

Sara

From: Sara
Sent: Monday, January 03, 2005 11:52 AM
To: Bill English (bill@mindsharp.com)
Subject: question from an old student

Hi Bill,

In all your spare time – if you have a few moments for another question from an old student I’d sure appreciate your input!

In looking at the SQL databases housing my SPS2003 data, I see that for the larger databases (typically _SITE) the LDF file (which I believe is the SQL transaction logfile) is quite a bit larger than the MDF file (which I believe is the primary SQL database file). For example, one of my _SITE database files is about 33GB in size; its companion LDF file is about 55GB in size.

I’m successfully backing up my SPS sites with the builtin backup/restore tool [still working out issues with the CommVault Qinetix SPS backup piece] – successful backups are logged both by SharePoint as well as on the SQL box itself… and I know the backups are working as I’ve had to move my SPS sites around WAY more often than I’d like via the restore tool.

I’ve only recently begun to really take a look at the actual SQL files (had to move the databases to larger partitions) – and I guess I expected the logfiles to be purged once successful backups are done – but it appears that they just keep growing.

I got a newsgroup response saying that the behavior of the SQL LDF files actually depends on settings within SQL itself – and that I probably don’t need the logfiles if I’m using SPS backups or some other tool (which I am) – but I’m wondering if there are any SPS recommendations about the SQL logfile settings?

I pretty much installed SQL with the default settings other than file locations (but in an active/passive 2-node SQL cluster).

I can’t seem to find anything on recommended SQL settings for SharePoint – is there any info you can pass along?

(please let me know if this doesn’t make any sense)

Thanks,

Sara

http://www.itpub.net/viewthread.php?tid=1048025

如何壓縮WSS3.0的ldf日誌文件（利用SQL2005 express管理工具壓縮WSS3.0日誌文件）

由於最近也遇到這個問題，並且是在生產環境中，WSS3.0所在分區只剩不到10%空間，狀況十分嚴重。通過多方查找（本人在SQL方面連個菜鳥都算不上）終於找到了解決的方法。由於是學習多位大俠的方法，因此寫在這兒，以供遇到同類問題的朋友參考。
環境：WSS3.0 安裝的數據庫是SQL簡化版
問題：WSS的WSS_Content_log.LDF/ SharePoint_Config_cab00c0b-ee12-434b-aed3-482add86567f_log.LDF兩個日誌文件分別達到了50G和17G左右，並且還在不斷增大。
解決方法：先安裝SQL2005 express版的管理工具（在迅雷裏找的）安裝後將服務器名稱設爲： \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
進行鏈接。
打開數據庫目錄後，能夠發現WSS_Content 和SharePoint_Config_cab00c0b-ee12-434b-aed3-482add86567f兩個數據庫（個人機器是這樣的）選中某個數據庫點右鍵後，在彈出菜單中選擇任務-收縮-文件在彈出的窗口文件類型中選擇日誌（下面一步很關鍵）這個時候選擇「確實」來收縮日誌文件實際是收縮不了的。必須採用一個命令來中斷日誌，而後才能夠收縮成功，個人做法是：在右鍵菜單裏選擇新建查詢輸入命令：BACKUP LOG "SharePoint_Config_cab00c0b-ee12-434b-aed3-482add86567f" WITH NO_LOG （這裏的數據庫名稱中有不規則字符，因此要""起來），點執行完成後，再回到剛纔的收縮界面中，便可以收縮成功（注意這裏的收縮操做有3種，我本身總結應該用第二種，不過第二種須要指定容量）。
再說一個我本身遇到的問題，由於很菜，因此遇到。
在我收縮WSS3.0 config日誌後，在WSS管理中心中，進行備份時沒法進行。
也沒法刪除備份任務，刪除時即提示未知錯誤。管理中心的不少功能也沒法執行。用WSS的修復功能也沒法解決。重壓之下，偶然用到了收縮窗口中的收縮操做第二項「在釋放未使用的空間前從新組織頁」而後從新進行了一次收縮（在未中斷日誌的狀況下），結果所有恢復正常。估計是收縮日誌時選了第一項收縮，引發日誌錯誤了。寫這麼多，是由於被日誌問題困擾了一個多月。但願其它的朋友沒必要象我這樣麻煩

職場解決休閒 SharePoint

1javascript

收藏css

上一篇：SharePoint 2007在... 下一篇：（記錄）操做多層Iframe嵌套...

BearStudyHard

150篇文章，12W+人氣，0粉絲

Ctrl+Enter 發佈html

發佈java

取消node

猜你喜歡

個人友情連接備忘：SharePoint默認的歡迎WebPart中超連接樣式發現大量的TIME_WAIT解決辦法解決：cannot execute binary file apache Internal Server Error 解決方法解決mysql：The server quit without updating PID file 服務器排障之 nginx 499 錯誤的解決 Gos：GOMODULE和GOPROXY解決方案 ××× 鏈接800錯誤的解決辦法(轉) Nginx常見的錯誤及解決方法 Java Scoket之java.io.EOFException解決方案解決 Warning: Permanently added (RSA) to the list of known hosts. PostgreSQL VFD機制支付結算系統如何應對高併發、熱點帳戶等問題 PostgreSQL WAL解析：構建WAL記錄準備 playbook自動安裝kafka集羣 PostgreSQL的B-tree索引 PostgreSQL pg_rewind實例--could not find previous WA redis geo 地理位置系應用戰案例 PostgreSQL邏輯備份pg_dump使用及其原理解析

掃一掃,領取大禮包mysql

1jquery

0ios

BearStudyHard