none
SharePoint 32位出现内存问题后想迁移到64位环境的疑问 RRS feed

  • 问题

  • 当前环境为
    SQL Server 2005 SP2 Enterprise Edition 32位
    Windows Server 2003 R2 SP2 Standard Edition 32位
    Windows SharePoint Services 3.0 SP2 32位

    公司在Windows Server 2003 (32位) 上部署了 Windows SharePoint Services 3.0 SP2. 由于一开始只是小范围使用, 所以在一个服务器上部署了全部服务器角色.

    上个月利用SharePoint做了一个Issue Tracking的列表进行全公司内的"问题跟踪".

    但由于问题增长的速度与数目超出了预期(每次至少200以上的新增项目, 此列表现有近3000项目. 网站每天近4000-5000的网站日点击.)

    于是前两天出现了System.OutOfMemoryException异常.

    未能处理请求。 Exception: System.OutOfMemoryException Message: 引发类型为“System.OutOfMemoryException”的异常。 StackTrace: 在 System.Web.CharBufferAllocator.AllocBuffer() 在 System.Web.BufferAllocator.GetBuffer() 在 System.Web.Hosting.RecyclableCharBuffer..ctor() 在 System.Web.Hosting.ISAPIWorkerRequest..ctor(IntPtr ecb) 在 System.Web.Hosting.ISAPIWorkerRequestInProc..ctor(IntPtr ecb) 在 System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6..ctor(IntPtr ecb) 在 System.Web.Hosting.ISAPIWorkerRequest.CreateWorkerRequest(IntPtr ecb, Int32 UseProcessModel) 在 System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr ecb, Int32 iWRType)


    在调整了应用程序池回收频率之后, 此现象暂时得到缓解.

    后来致电了微软800, 开了个case, 工程师建议
    1. 将SQL SERVER 数据库迁移至另一台独立的计算机。
    2. 将WSS升级至X64服务器环境。
    3. 建立多个WEB 前端

    但现在问题来了:
    1 需要迁移到域
    公司现有“XX.YYY.intra”域,而现在的SharePoint服务器上的用户认证都是基于Windows认证的。如要迁移到此域,对于最终用户,用户名会出现变化,例如:zhangsan -> zhangsan1 此种问题如何解决?
    如果新建另一个域,对于最终用户,采用相同用户名,该如何保持新旧用户的关联,以确保SharePoint的视图例如:“我创建的问题”能够仍旧正常显示迁移前后的项目。比如: 之前用户名都是 Sharepoint\zhangsan 这样的? 域的名字域如何设置也有讲究么? 由于以前都没接触过"域", 这个真是一筹莫展.
    2 经过与硬件供应商确认,现有的服务器支持em64t,在不中断现有服务器提供服务的情况下,至少需要多少台服务器呢?
    3 SQL Server 2005/2008Windows SharePoint ServiceMicrosoft Search Server Expressx86x64的版本是否对于数据内容都是完全透明的?这个迁移会影响数据么?
    4 将来做了这个灾难恢复与备份方案该如何考虑呢?
    5 对于现在的32位环境, 在真的做迁移前, 现在业务还需要跑, 大家要什么优化建议么? Web园可以使用么?
    另外现在的这个SharePoint列表中有一个"相关问题"查阅项, 现在每次新建或编辑都在读取全部近3000个标题, 页面载入前都要顿一下, 这个该如何改善呢?


    Chao Xia
    2010年2月2日 8:59

全部回复

  • Hi,

     

    您可以通过多种方式将现有服务器场迁移到 64 位环境;例如,通过将 64 位服务器添加到现有服务器场,然后移除 32 位服务器。也可以重新创建一个64的服务器场,然后将SharePoint32位服务器场迁移到64位的服务器场。

     

    注意:32位服务器场和64位的服务器场位于同一个活动目录域。

     

    有关详细的操作步骤,请参考下面的链接:

    Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

    http://technet.microsoft.com/en-us/library/dd622865.aspx

     

    希望对你有所帮助。

     

    Rock Wang


    Rock Wang– MSFT
    2010年2月3日 7:19
    版主
  • Hi,

     

    您可以通过多种方式将现有服务器场迁移到 64 位环境;例如,通过将 64 位服务器添加到现有服务器场,然后移除 32 位服务器。也可以重新创建一个64的服务器场,然后将SharePoint32位服务器场迁移到64位的服务器场。

     

    注意:32位服务器场和64位的服务器场位于同一个活动目录域。

     

    有关详细的操作步骤,请参考下面的链接:

    Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)

    http://technet.microsoft.com/en-us/library/dd622865.aspx

     

    希望对你有所帮助。

     

    Rock Wang


    Rock Wang– MSFT
    Hi, Dear Rock Wang
    非常感谢您的回复! 可是由于初期规划的不完善, 一开始在一个32位服务器上部署了全部服务器角色. 而且也没有使用"域", 使用的是windows用户认证.

    公司现有一个“XX.YYY.intra”域,而现在的SharePoint服务器上的用户认证都是基于Windows认证的。如要迁移到此域,对于最终用户,用户名会出现变化,例如:zhangsan -> zhangsan1 此种问题如何解决?如果新建另一个域,对于最终用户,采用相同用户名,该如何保持新旧用户的关联,以确保SharePoint的视图例如:“我创建的问题”能够仍旧正常显示迁移前后的项目。比如: 之前用户名都是 Sharepoint\zhangsan 这样的? 域的名字域如何设置也有讲究么? 由于以前很少接触过"域", 有点糊涂, 能给我一些提示么? 多谢了!

    Chao Xia
    2010年2月3日 16:08
  • 一开始在一个32位服务器上部署了全部服务器角色. 而且也没有使用"域", 使用的是windows用户认证.
    =============
    注意,使用“域”也是用的 Windows 集成认证,只是域用户是由域控服务器验证,而本机(单机,工作组)用户(即你目前情况)则有本机验证。
    那么,你当时选择的安装类型是“单机”?还是“服务场”?看你现有SQL 是 Enterprise,那么应该是“服务场”,如果是“单机”,不支持直接从“单机”升级到“服务场”,需要手工完成,参考:

    1 需要迁移到域
    公司现有“XX.YYY.intra”域,而现在的SharePoint服务器上的用户认证都是基于Windows认证的。如要迁移到此域,对于最终用户,用户名会出现变化,例如:zhangsan -> zhangsan1 此种问题如何解决?
    如果新建另一个域,对于最终用户,采用相同用户名,该如何保持新旧用户的关联,以确保SharePoint的视图例如:“我创建的问题”能够仍旧正常显示迁移前后的项目。比如: 之前用户名都是 Sharepoint\zhangsan 这样的? 域的名字域如何设置也有讲究么? 由于以前都没接触过"域", 这个真是一筹莫展.
    =============
    虽然我不是 Windows 系统工程师,对于部署AD,我觉得,
    首先,部署 AD 是企业信息化过程相当大的一个决策,如果目前准备部署 AD,建议做好规划,最好请专业的AD工程师,别重忙上AD。
    另外,如果你仅仅是为了解决这里提的 SharePoint 问题而重忙部署 AD 可能有些得不偿失,将来改造 AD 更麻烦,比如你上面提高的域名(包括 domain,NetBIOS 等)

    对于 2003 AD,假如你的域名是 sample.com 那么域用户格式是 username@sample.com, 也支持为 sample.com 指定 NetBIOS,比如 samp,那么此时还可以使用格式: samp\username
    对本机用户,一般用户名格式就是 machine\username 了。

    即使,你现有的机器名是 sharepoint,具有用户 user1,你新的 AD 域 NetBIOS 也叫 sharepoint,也加了一个域用户 user1,但是这个两个 sharepoint\user1 是在各自的安全上下文中,是完全不同的,即使你看到 sharepoint\user1 这个登录名一样,实际上还有一个内置属性 SID,是完全不一样的,这个 SID 才是区分 windows 用户的唯一ID。

    所以,对于新旧用户这个问题,可能没有很好的解决方案了,只能重建用户,重新授权。当然这个过程可以通过脚本或者程序来批量完成。

    2 经过与硬件供应商确认,现有的服务器支持em64t,在不中断现有服务器提供服务的情况下,至少需要多少台服务器呢?
    ==============
    多少服务器?这个没有直接答案。SharePoint 有一个 Server Farm 的概念,这个 Farm 就是用多个不同服务器分开承载不同服务角色,用多个服务均载同一个服务角色。建议好好看 TechNet 上服务场部署的文档:在服务器场环境中部署 Office SharePoint Server 2007

    个人还是建议,先部署小型服务器场(至少把 SQL Server 与 Web/App Server 分开,此外你可能还需要专门的服务器来部署 DC 或者 DNS 等),先完成迁移工作,如果性能还是有瓶颈再添加服务器。
    下面是官方文档说明:

    服务器场环境可以包含各种拓扑结构,并且可以包括多台服务器或只包含两台服务器。

    小型服务器场通常包含:一台数据库服务器(运行 Microsoft SQL Server 2005 或带有最新的 Service Pack 的 Microsoft SQL Server 2000);一台或多台运行 Internet Information Services (IIS) 和 Office SharePoint Server 2007 的服务器。在这种配置中,前端服务器被配置为 Web 服务器和应用程序服务器。Web 服务器角色向客户端提供 Web 内容。应用程序服务器角色提供 Office SharePoint Server 2007 服务,如搜索查询服务、内容爬网和索引编制。

    中型服务器场通常包含一个数据库服务器、一个运行 Office SharePoint Server 2007 的应用程序服务器以及一台或两台运行 Office SharePoint Server 2007 和 IIS 的前端 Web 服务器。在这种配置中,应用程序服务器提供索引服务和 Excel Calculation Services,前端 Web 服务器提供搜索查询服务和 Web 内容。

    大型服务器场通常包含两个或更多个群集数据库服务器、几个运行 Office SharePoint Server 2007 的负载平衡的前端 Web 服务器以及两个或更多个运行 Office SharePoint Server 2007 的应用程序服务器。在这种配置中,每个应用程序服务器都提供特定 Office SharePoint Server 2007 服务(如编制索引或 Excel Calculation Services),前端服务器提供 Web 内容。



    Hope Helpful | Xiaofeng Wang | http://www.leoworks.net
    2010年2月3日 18:08
  • 一开始在一个32位服务器上部署了全部服务器角色. 而且也没有使用"域", 使用的是windows用户认证.
    =============
    注意,使用“域”也是用的 Windows 集成认证,只是域用户是由域控服务器验证,而本机(单机,工作组)用户(即你目前情况)则有本机验证。
    那么,你当时选择的安装类型是“单机”?还是“服务场”?看你现有SQL 是 Enterprise,那么应该是“服务场”,如果是“单机”,不支持直接从“单机”升级到“服务场”,需要手工完成,参考:

    1 需要迁移到域
    公司现有“XX.YYY.intra”域,而现在的SharePoint服务器上的用户认证都是基于Windows认证的。如要迁移到此域,对于最终用户,用户名会出现变化,例如:zhangsan -> zhangsan1 此种问题如何解决?
    如果新建另一个域,对于最终用户,采用相同用户名,该如何保持新旧用户的关联,以确保SharePoint的视图例如:“我创建的问题”能够仍旧正常显示迁移前后的项目。比如: 之前用户名都是 Sharepoint\zhangsan 这样的? 域的名字域如何设置也有讲究么? 由于以前都没接触过"域", 这个真是一筹莫展.
    =============
    虽然我不是 Windows 系统工程师,对于部署AD,我觉得,
    首先,部署 AD 是企业信息化过程相当大的一个决策,如果目前准备部署 AD,建议做好规划,最好请专业的AD工程师,别重忙上AD。
    另外,如果你仅仅是为了解决这里提的 SharePoint 问题而重忙部署 AD 可能有些得不偿失,将来改造 AD 更麻烦,比如你上面提高的域名(包括 domain,NetBIOS 等)

    对于 2003 AD,假如你的域名是 sample.com 那么域用户格式是 username@sample.com, 也支持为 sample.com 指定 NetBIOS,比如 samp,那么此时还可以使用格式: samp\username
    对本机用户,一般用户名格式就是 machine\username 了。

    即使,你现有的机器名是 sharepoint,具有用户 user1,你新的 AD 域 NetBIOS 也叫 sharepoint,也加了一个域用户 user1,但是这个两个 sharepoint\user1 是在各自的安全上下文中,是完全不同的,即使你看到 sharepoint\user1 这个登录名一样,实际上还有一个内置属性 SID,是完全不一样的,这个 SID 才是区分 windows 用户的唯一ID。

    所以,对于新旧用户这个问题,可能没有很好的解决方案了,只能重建用户,重新授权。当然这个过程可以通过脚本或者程序来批量完成。

    2 经过与硬件供应商确认,现有的服务器支持em64t,在不中断现有服务器提供服务的情况下,至少需要多少台服务器呢?
    ==============
    多少服务器?这个没有直接答案。SharePoint 有一个 Server Farm 的概念,这个 Farm 就是用多个不同服务器分开承载不同服务角色,用多个服务均载同一个服务角色。建议好好看 TechNet 上服务场部署的文档:在服务器场环境中部署 Office SharePoint Server 2007

    个人还是建议,先部署小型服务器场(至少把 SQL Server 与 Web/App Server 分开,此外你可能还需要专门的服务器来部署 DC 或者 DNS 等),先完成迁移工作,如果性能还是有瓶颈再添加服务器。
    下面是官方文档说明:

    服务器场环境可以包含各种拓扑结构,并且可以包括多台服务器或只包含两台服务器。

    小型服务器场通常包含:一台数据库服务器(运行 Microsoft SQL Server 2005 或带有最新的 Service Pack 的 Microsoft SQL Server 2000);一台或多台运行 Internet Information Services (IIS) 和 Office SharePoint Server 2007 的服务器。在这种配置中,前端服务器被配置为 Web 服务器和应用程序服务器。Web 服务器角色向客户端提供 Web 内容。应用程序服务器角色提供 Office SharePoint Server 2007 服务,如搜索查询服务、内容爬网和索引编制。

    中型服务器场通常包含一个数据库服务器、一个运行 Office SharePoint Server 2007 的应用程序服务器以及一台或两台运行 Office SharePoint Server 2007 和 IIS 的前端 Web 服务器。在这种配置中,应用程序服务器提供索引服务和 Excel Calculation Services,前端 Web 服务器提供搜索查询服务和 Web 内容。

    大型服务器场通常包含两个或更多个群集数据库服务器、几个运行 Office SharePoint Server 2007 的负载平衡的前端 Web 服务器以及两个或更多个运行 Office SharePoint Server 2007 的应用程序服务器。在这种配置中,每个应用程序服务器都提供特定 Office SharePoint Server 2007 服务(如编制索引或 Excel Calculation Services),前端服务器提供 Web 内容。


    Hope Helpful | Xiaofeng Wang | http://www.leoworks.net

    非常感谢您的回复! 我确实使用的是高级安装, 但是全部服务器角色都安装在一个机器上了.
    您的回复让我茅塞顿开! 再次感谢!

    关于Windows用户认证的问题中您提到的SID, 之前我在网上找了一篇文章, 利用这里提供的这个语句, 我曾经将现在这个服务器环境迁移到另一个服务器上, 建立同名用户, 同时保持了所谓"我创建的问题"类似这样的对最终用户一致性. (但密码迁移不过来.)

    先把问题描述一下:已把AD用户“User1”加到SharePoint站点中,然后进行如下类似操作:将“User1”从SharePoint站点中删除,将“User1”从AD中删除,在AD中增加一个新用户“User1”,在SharePoint站点中增加一个用户“User1”,这时,您会发现很有意思的问题:可能可以成功增加这个用户,但是这个用户始终无法登录到SharePoint站点中;或者根本增加不了这个用户到SharePoint站点中,提示您站点中已经存在这个用户了。

    在上次CSDN站点的SharePoint技术聊天活动中,有参与的网友询问了类似的问题,由于当时我在聊天活动中无法给出非常详细的解释,所以只是给出了一个相关的链接。今天用这篇文章详细解释一下。

    这个问题出现的原因,是出自SharePoint对于站点用户的存储机制所造成的。SharePoint站点用户信息保存在站点对应的内容数据库的UserInfo表中,如果站点管理员删除了站点中的某个用户,您可能会惊奇的发现,这个用户相应的记录并未从UserInfo表中删除,而只是将“tp_Deleted”这个列的数据进行了设置。(这种机制的原因所在是这条记录可能已经通过外键关联了其他表的其他记录,比如此用户编写的文档,所以将此记录直接删除是不可取的。)

    在以后,如果站点管理员将一个同名的用户增加到这个站点中,由于UserInfo表中已经有这条用户记录的存在,所以SharePoint也只是将这条记录的“tp_Deleted”列的数据再进行设置。

    这时候,问题就来了。在UserInfo表中,有一个“td_SystemID”列,这个列是用来记录这个用户的Security Identification Number(SID)的。我们在AD中删除一个用户,再新增一个同名用户,这先后两个用户的SID肯定是不同的。而SharePoint使用了这个“td_SystemID”列来识别用户,由于前后两个用户的SID肯定不同,所以SharePoint站点就“不认”在AD中重新增加的这个用户了。

    解决方法就是把UserInfo表的“td_SystemID”列的数据和当前AD中的用户信息进行同步。在SqlServer中有一个SUSER_SID()函数,可以返回某用户的SID信息。在Dean的Blog上,他已经给出了一个完整的Sql语句,大家可以直接使用。

    顺便题一下,在Deam的Blog上,他也描述了这个问题所造成的另外一个问题:如果我们备份站点的时候,将用户信息也一起备份了下来,在恢复到另外一个AD中时,如果站点用户有同名的现象,也同样会造成SharePoint“不认”这个AD用户。

    Thanks to my good friend Jeremy McMahan for finding the suser_sid() function for me -- My original solution was a crazy mix of linked servers and the Directory Services provider for OLEDB!

    Ever migrate your SharePoint site to a totally new environment and discover that your efforts to re-create your Active Directory were all for nothing, since all the users got new SIDs?  Symptoms like: The administrator of the server can log in, but nobody else can, even though you're SURE their usernames and passwords are right.

    Here's a script that'll fix that up for you in a jif.  Open Query Analyzer and run it against the content database for your site, and it will update all the SIDs for your users to the SID that is reported for that user by Active Directory.

    Big fat disclaimer: Microsoft does NOT support ANY modifications to your SharePoint databases.  That's not to say they won't support your SharePoint site, but if this operation breaks your server, Microsoft won't help you.  I'm not responsible for the results, either, while we're on the subject of passing the buck.  BACK UP YOUR DATABASE.

    Okay, now that we've gotten that mumbo-jumbo out of the way, here's the code.

    DECLARE @login varchar(40), @systemid varbinary(128)
    DECLARE curUsers CURSOR LOCAL FOR
    SELECT tp_login, tp_systemid FROM userinfo where tp_deleted = 0
    OPEN curUsers
    FETCH NEXT FROM curUsers INTO @login, @systemid
    WHILE @@FETCH_STATUS = 0
    BEGIN
    PRINT 'Resetting user ' + @login + ' to new SID '
    PRINT suser_sid(@login)
    UPDATE UserInfo
    SET tp_systemid = suser_sid(tp_login) WHERE CURRENT OF curUsers
    FETCH NEXT FROM curUsers INTO @login, @systemid
    END
    CLOSE curUsers
    DEALLOCATE curUsers
    GO
    是否按照此方法, 也可以将 这些 Windows 用户迁移到域.

    比如 现有的Windows 用户有一个 Sharepoint\zhangsan 在公司的域中这个用户叫做 XX\zhangsan1 我将 Sharepoint 数据库中userinfo 表的 Sharepoint\zhangsan 对应的用户名 和 sid 都分别更新成新的  XX\zhangsan1 所对应的用户名和sid 是否就能够做到平稳迁移呢?

    尽管MS并不支持这么做.

    再次感谢您的回复!
    Chao Xia
    2010年2月4日 6:06
  • 比如 现有的Windows 用户有一个 Sharepoint\zhangsan 在公司的域中这个用户叫做 XX\zhangsan1 我将 Sharepoint 数据库中userinfo 表的 Sharepoint\zhangsan 对应的用户名 和 sid 都分别更新成新的  XX\zhangsan1 所对应的用户名和sid 是否就能够做到平稳迁移呢?

    ==========

    只能说,看起来挺有希望的,但没有试验过,谁知道呢?我知道,很有挑战力 :)

    理论上,如果能够将 SharePoint 数据中(主要是contentdb) 中涉及 User 的引用数据(应该都是用 Windows User SID 吧,呵呵,我不确定....)都更新到,应该没问题,但这个过程很艰巨,你不知道会出什么莫名其妙的问题,除非 MS SharePoint Team 的人来做成功率比较大,因为他们知道内部数据结构。

    不过,你可以先建一个部署一个新的包含域的SharePoint试验环境,尝试迁移,说不定真的很容易就被你搞定了,记得分享

    Good luck!
    Hope Helpful | Xiaofeng Wang | http://www.leoworks.net
    2010年2月6日 17:32
  • 比如 现有的Windows 用户有一个 Sharepoint\zhangsan 在公司的域中这个用户叫做 XX\zhangsan1 我将 Sharepoint 数据库中userinfo 表的 Sharepoint\zhangsan 对应的用户名 和 sid 都分别更新成新的  XX\zhangsan1 所对应的用户名和sid 是否就能够做到平稳迁移呢?

    ==========

    只能说,看起来挺有希望的,但没有试验过,谁知道呢?我知道,很有挑战力 :)

    理论上,如果能够将 SharePoint 数据中(主要是contentdb) 中涉及 User 的引用数据(应该都是用 Windows User SID 吧,呵呵,我不确定....)都更新到,应该没问题,但这个过程很艰巨,你不知道会出什么莫名其妙的问题,除非 MS SharePoint Team 的人来做成功率比较大,因为他们知道内部数据结构。

    不过,你可以先建一个部署一个新的包含域的SharePoint试验环境,尝试迁移,说不定真的很容易就被你搞定了,记得分享

    Good luck!
    Hope Helpful | Xiaofeng Wang | http://www.leoworks.net

    谢谢您, 最近正在部署x64的测试环境, 稍后会作测试!
    如果成功一定会同大家分享! 感谢您的鼓励:-)
    Chao Xia
    2010年2月9日 11:42