SQL Server2014 IO调控支持-20161014.docx

by 张刚 2016.12.20 11:09
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。SQL Server2014 IO调控支持-20161014 1.   概述 U9产品之前在调度服务器支持了CPU的调控功能,具体可参考附件:《转发: Job支持SQL资源调控部署方法-20131112.msg》: SqlServer2014后资源调控增加了对IO的调控支持。因此,使用SQL2014及以后版本的客户,可通过添加新的【应用】和【WorkGoup】来支持其他调度服务运行时的资源(CPU\IO)的调控。本文档通过设置U9数据库【碎片整理】调度的CPU和IO调控,来降低其CPU\IO的使用,从而避免在生产环境业务期间对服务器的资源占用。其他类似调度如此调整,可参考即可。 2.  操作步骤 1. 通过下面步骤,【系统管理工具】--【站点管理】--【数据库服务器】--双击数据库--【资源调控】--【缺省设置】, 进入到设置界面: 点【缺省设置】后,会出现U9目前已支持的CPU调控的5个节点。 2. 查询【碎片整理】调度的应用信息: 在u9的数据库中,通过数据库查询分析器,执行如下sql: SELECT c.Local_ID ,l.DisplayName ,l.Description,c.FullName,c.Name,c.Discriminator FROM dbo.UBF_MD_Class_Trl l INNER JOIN UBF_MD_Class c ON l.LOCAL_id = c.LOCAL_id  WHERE l.DisplayName LIKE '%碎片%' AND l.SysMLFlag='zh-CN' 找到其对应的BP的名称:UFIDA.U9.Base.Performance.Defragmentation(其他调度相关信息同样可这样查询,对于有些不确认的名字,可咨询相关开发)。 3. 在资源调控配置中,添加如下内容。U9IOIndex在第4步骤中创建。点【确认】。 注:由于默认策略的原因,WorkGroup的名字,必须以U9开头,否则相应功能不起作用。 4 .创建u9碎片整理所使用的资源池和工作负荷组 --1.创建碎片整理的的资源池 Use master go   CREATE RESOURCE POOL U9IOIndex WITH (      MAX_CPU_PERCENT = 20,      MIN_CPU_PERCENT = 0,      MAX_IOPS_PER_VOLUME = 20,      MIN_IOPS_PER_VOLUME = 0 ) GO --2.创建碎片整理的的工作负荷组 CREATE WORKLOAD GROUP groupU9IOIndex --group+U9IOInxdex WITH ( IMPORTANCE = LOW --MEDIUM   ) USING U9IOIndex GO   --3.更新内存中的配置 ALTER RESOURCE GOVERNOR RECONFIGURE GO   --4.创建分类器函数 if object_id('dbo.fn_U9Classifier') is not null      drop function dbo.fn_U9Classifier go   create function [dbo].[fn_U9Classifier]() returns sysname with SchemaBinding as begin    declare @grpName as sysname    declare @appName as nvarchar(128)      set @appName = App_Name()    if (left(@appName,2) = 'U9')         set @grpName = 'group' + @appName    else         set @grpName = 'default'   return @grpName end go     --5.注册分类器函数到资源调控器并更新内存中的配置 ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fn_U9Classifier) ALTER RESOURCE GOVERNOR RECONFIGURE GO   --6.查看资源池中是否添加UseIOAAAI成功? SELECT * FROM sys.dm_resource_governor_resource_pools 5. 以上步骤,就完成了对u9调度中的碎片整理的cpu、io的资源调试设置。重启调度服务(UfApplicationService),使得配置生成。 3.  测试 1.       创建索引整理调度(大部分客户已创建了此调度,则不用创建了)。 2.       通过SQL Profiloer观察,对应的ApplicationName已变成对应的工作负荷组名字。 观察计数器,其IO最高上限为20。 4.   注意事项 一般企业级级机械磁盘组成的raid,其IOPS在200至2000之间,由于限制IO后,其sql执行效率时由于占用IO较小,执行时间也相应会拉长,从测试来看,正常6分钟跑完的碎片整理,在IO限制在20后,30分钟未执行完成。因此对于IO的限制一般主要应用如下两类场景: a.       数据库碎片整理 b.       数据库备份 通过对上面两类操作做IO的限制,可减少在ERP在上班业务期间其执行的IO消耗,从而减少到正常业务的影响。  

使用IIS的失败请求跟踪规则排查疑难问题

by hbzhang 2015.12.31 16:19
主题 使用IIS的失败请求跟踪规则排查疑难问题 发件人 张红斌 收件人 范骁智; 管兆雄; 冀忠伟; 康晓龙; lkc@yonyou.com; 李一娜; 刘强亚; 马红旭; '马杰'; 孟令安; '陶华'; 魏崟; 吴高飞; wushh@yonyou.com; 余飞; 张刚; 张红斌; zhangjlg@yonyou.com; 郑江媛; 朱志强 发送时间 2015年12月31日 16:06     前两天分析域用户集成登录问题时,发现利用"失败请求跟踪规则"来排查疑难问题,是一个比较有力的手段。     问题现象     当时的错误提示如下:     由于界面上没有详细的错误信息,一时感觉无从着手,于是想到利用IIS7及更高版本所支持的失败请求跟踪能力,来分析这个问题。     启用步骤     首先,在IIS中找到U9应用,在右边的功能区中选择"失败请求跟踪规则": 双击,然后选择添加,注意屏幕右上方有一个错误提示,我们后面会进行处理: 针对我们的500错误,选择依据状态码来定义跟踪条件: 默认跟踪所有: 单击完成即配置好了失败跟踪规则。     现在还差一步,根据前面的提示,我们还需要为网站打开失败请求跟踪的能力。方法是选U9所在的网站,此处为Default Web Site: 然后在弹出的界面中设置启用:         分析问题     重启IIS后,再次运行我们的程序,在如下目录中就会发现多了一批跟踪文件: 双击打开,就可以看到详细的错误信息了: 后面解决的方法就很简单了。     要多说的一点就是,虽然这个功能被命名为"失败请求跟踪规则",实际上你可以把它作为通用的跟踪工具使用,不限于跟踪失败请求。例如,状态码我们选200,就可以跟踪分析普通的请求。不根据状态码,而根据所用时间就可以跟踪分析哪些性能有问题的请求。             张红斌 hbzhang U9事业部-平台技术部  部门经理         用友网络科技股份有限公司 yonyou Network Technology Co., Ltd. 电话 (Tel):010-62435116 手机 (Mob):18600330588 邮箱 (Mail):zhb@yonyou.com 地址:北京海淀区北清路 68 号 用友软件园 (邮编:100094) Add: yonyou software Park, No. 68 Beiqing Road, Haidian District, Beijing, China 100094 网址 (Web): www.yonyou.com        

关于raid5磁盘阵列开启写缓存的问题说明

by 张刚 2015.1.20 11:49
问题:          很多客户的db服务器(放U9db磁盘)是配置raid5,但默认情况下,对于写缓存,是禁用的。导致U9在使用时,对于写操作因为未启用写缓存,性能较差。                       方案:                   通过raid管理程序,开启写缓存。如图:将写策略设置为:Always Write Back。                                          说明:开启写缓存,意味着数据在内存未写入磁盘时,系统认为是写入磁盘的。这样如果db服务器突然断电,会丢在一定的数据丢失风险。(一般情况下sql server根据日志信息,对事务进行前滚和后滚,丢失数据的风险一般也比较小)。在保证良好数据库备份的策略情况下,还是建议开启写缓存。来达到更优化的sql sever性能。                    ---------------------- U9平台部 张刚    

ie中加信任站点和配置xss禁用

by 张刚 2014.10.15 10:25
主题 ie中加信任站点和配置xss禁用 发件人 zhanggangb 收件人 'zhangjw@ufida.com.cn' 发送时间 2013年8月7日 16:27     配置IE8 注:从V2.5版本开始,从效率上考虑,使用IE的最低版本为IE8。 配置自动检查网页的较新版本 打开Internet选项界面,在浏览历史记录部分按下设置按钮: 确保选择的检查方式为自动: 如果选择的方式是"每次访问网页时",则包括图像文件、js脚本、css格式文件等都会每次打开网页时都重新从服务器上下载,不管是否发生了变化。IE的缓存能力就得不到发挥,会比较影响性能。 禁用仿冒网站检查 IE8支持仿冒网站检查,但目前版本的这个功能存在较为严重的性能问题,请不要使用。     禁用仿冒网站检查方法如下: 打开Internet选项对话框,在高级页签中找到仿冒网站筛选器这个项目,设置选项为"禁用仿冒网站筛选器"。 特别强调:关闭自动网站检查没有效果,必须是禁用! 禁用无关的插件 用户可能在不知情的情况下,已不知不觉下载了许多第三方插件。有些插件可能会比较严重地影响IE的性能,例如我们曾经发现由Office2007自动安装的Groove插件就比较影响性能。我们建议对于企业用户,尽量减少使用这些IE插件。     禁用IE插件的方法 选工具|管理加载项|启用或禁用加载项: 在弹出的对话框中看哪些插件不需要使用,选择禁用即可。     注意:XML DOM Document不能被禁用,u9程序需要使用     U9提供了一个IEAutoConfig工具,可以方便地关闭插件,使用方法: IEAutoConfig –all http://appServerName     appServerName请用实际的机器名代替。 设置Portal站点为信任站点 IE8有较强的安全检查机制,对于企业用户访问自己的Portal站点而言,这些安全检查特性会付出额外的消耗。我们建议把Portal站点加为信任站点。     设置方法如下 打开Internet选项对话框,选安全|可信站点,然后按下"站点"按钮: 输入Portal网站的地址,然后按下"添加"按钮即可: 关闭XSS检查 IE8在安全方面有所增强,其中一项是新增加了XSS检查,并且默认为开启状态。该功能的作用是阻止跨站脚本攻击,并阻止一些浏览器认为不安全的脚本行为。这可能导致U9某些需要访问Top属性的参照界面出现异常,因为XSS检查将其视为有跨站访问威胁。     在IE8中关闭XSS检查的方法如下: 访问工具|Internet选项菜单,在弹出的对话框中选择安全页签,选择"可信站点"区域,然后选"自定义级别": 找到"启用XSS筛选器",将其禁用: 为安全考虑,关闭XSS检查功能应该只对信任区域进行。由于U9的Portal站点被加入到信任区域,因此U9程序将可以正常工作。 其它配置 IE是一个内存敏感型的应用程序。我们建议在通过IE访问U9 Portal程序时,可以适当地关闭一些无关的应用程序。 另外,作为客户机使用的机器,也有可能安装了一些仅服务器才需要使用的服务,这些也会无端地占用内存和CPU资源。可以请求系统管理员帮助检查一下。     ---------------------- U9平台部 张刚    

系统重装后无法实现之前的输入保留(输入匹配功能)

by 张刚 2014.9.11 12:53
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 主题 系统重装后无法实现之前的输入保留(输入匹配功能) 发件人 张刚 收件人 'qiheng@yonyou.com' 发送时间 2014年9月11日 12:51     问题:          系统重装后无法实现之前的输入保留(输入匹配功能) 方案:     U9默认是禁用历史参考功能的,如果想启用,请按下面方法设置。     在portal服务器U9的Portal\UIMvcConfig.config文件中,搜索autoComplete关键字,将Disable="false"即可启用历史参考记录功能。                 ---------------------------------- 姓名:张刚

你还可以再诡异点吗——SQL日志文件不断增长 - i6first

by 张刚 2014.9.9 20:08
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 主题 你还可以再诡异点吗——SQL日志文件不断增长 - i6first 发件人 张 刚 收件人 张刚 发送时间 2013年8月26日 6:21     你还可以再诡异点吗——SQL日志文件不断增长 - i6first 博客园_首页     前言     今天算是遇到了一个罕见的案例。 SQL日志文件不断增长的各种实例不用多说,园子里有很多牛人有过介绍,如果我再阐述这些陈谷子芝麻,想必已会被无数次吐槽。 但这次我碰到的问题确实比较诡异,其解决方式也是我第一次使用。 下文将为各位看管详细介绍我的解决思路。     现象     一客户反馈数据库的日志文件不断增长,已分配的磁盘空间快使用完,尝试过事务日志截断(事务日志备份)的操作,但没有任何效果。     分析     遇到这个问题,我最直接的感受:肯定有大的事务一直在执行,导致日志备份无法截断事务日志的大小。 首先,我在该数据库下运行DBCC loginfo()                                           图一 从图一的红色框可以看到,数据库的多个VLF的状态都为2,也就是active状态。(如果为0 ,表示为inactive)。 这表明这些日志文件确实都在活动状态,一般而言,导致这种现象的原因主要有三种:长事务的运行、replication和mirroring延迟。 但这个客户没有采用replication和mirroring,所以我初步锁定问题是因为长事务的运行导致。按照常规的方法,我只需分析下这个事务是否遇到阻塞、死锁等情况,然后给出对应的解决方案即可。(但实际情况并非如此) 为保险起见,我运行如下语句来验证下我的判断: SELECT log_reuse_wait_desc, * FROM sys.databases WHERE NAME='dbname'                                                                                            图二     显然,我的判断错了,可以看到,目前【log_reuse_wait_desc】的状态为【REPLICATION】。也就是说正是事务日志分发导致日志文件不断增大的原因。 正如前文分析的,这个数据库并没有用作发布订阅,怎么会出现这个状态呢? 经与客户沟通,了解这个数据库其实是从一个发布订阅的数据库中还原过来的,尽管新的数据库并没有采用发布订阅,但数据库中发布订阅的一些配置选项还在,从而导致了数据库的误判,致使日志文件不断增大。     方案     知道了原因就好办了。 起初我想通过sp_droppublication来完全删除分发订阅的配置,但无法通过sp_helppublication获取到@publication的名字(提示:命令已执行完!),因此这条路走不通了。 在网上找些资料,发现了sp_removedbreplication这个存储过程,执行后再去收缩日志文件,问题果然解决! EXEC sp_removedbreplication dbname DBCC SHRINKFILE(Logfilename) DBCC loginfo()                                                   图三         总结     尽管本文的场景比较少见,但总体解决的思路与其他(日志文件不断增长)其实是一样的。少许地方不太明白可以通过网络等一些工具获得。这也说明了SQL原理的重要性,借用一本书的序言中的一句话【越接触本质越不会迷茫!】。多接触原理,很多东西都是触类旁通的。     本文链接:http://www.cnblogs.com/i6first/p/3281437.html,转载请注明。     Original Article: http://www.cnblogs.com/i6first/p/3281437.html     发自我的 iPhone

个性化跨页签移动到grid之后点击该列IE卡死问题

by lkc 2014.8.15 09:31
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。问题号:201408120122 问题描述:生产线料品日计划界面的行页签里面都没有存储地点或完工地点,需要到“生产”页签里面填,当修改个性化把“完工地点”和“入库存储地点”调出来放到表行里,开单的时候一点到这两项(无论哪一项)就卡死,完全没有办法填写完工地点。 问题重现:生产线料品日计划,个性化,将“基本”页签以外的页签上的字段(任何字段,任何类型)扩展到Grid,点击扩展的字段时系统就会卡死。 问题跟踪:本地重现问题之后挂上VS的异常 在callback回调时候报异常——未能找到回调的目标“u$M$p0$DataGrid8$ctl18”或未实现 ICallbackEventHandler。由于做了跨页签扩展控件到grid,所以个性化会在grid控件上挂一个模拟切换页签的关联控件,开始猜测是否由于什么原因导致个性化的关联控件没有每次都输出导致,所以先跟踪个性化的关联控件的挂接流程 if (colsMoveFromCard.Count > 0) { GridEventProcessor processor = new GridEventProcessor(this._WebPart, grid as IUFDataGrid); CallBackAction.ResisterCallBackEvent(grid as IUFDataGrid, UFDateGridEventName.OnImitateSwitchTabPage, colsMoveFromCard.ToArray(), false , processor.ProcessSimulateTabPageChanged_CallBack); }   public void Add(Control l) { if (l is IUFCanCallBack) { ((IUFCanCallBack)l).CallBackHandler = this; l.Controls.Add(this); } this._arriListSubControls.Add(l); }   跟踪发现: 1、get操作时 个性化添加的关联控件ID为ctl17 2、点击扩展列引发的callback 个性化添加的关联控件ID为ctl16 开始怀疑应用开发的代码中是否有有条件输出的关联控件 并且也是挂在grid控件下的 通过查看开发代码 发现了一处疑似点 private void Page_PostBack() { if (!base.get_Page().IsPostBack) { AssociationControl control = new AssociationControl(); control.get_InitPara().Add("TableRowChanged()"); control.set_SourceServerControl(this.DataGrid8); } } 这个逻辑正好印证了跟踪时get方式和callback方式输出的关联控件个数不一致的猜测 通过反编译跳过判断 保证每次都输出这段关联控件 问题不再出现 小结: 应用开发在写关联控件时 一定要保证一个原则——即必须无条件输出关联控件 以保证控件树在任何情况下都是完整的 如果关联控件是有条件执行的 请在关联控件内部自行判断

数据库备份和旧数据库备份文件删除

by 张刚 2014.4.29 16:53
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 使用sql server 2012 always功能的用户,其数据库恢复模式为完整,默认情况下,如果日志不做备份,会导致日志文件因日志无法截断而一直增长下去。这样最后会导致磁盘空间一直在增长。通过设置日志备份(日志截断)即可解决此问题。同时对于一般客户而言,建议按这种方式来设置。但前提是一定要注意,因为自动删除了3天前的备份。如果哪天出现异常导致数据3天没有备份成功。可能就没有最近的数据库备份文件了。所以IT部维护人员应定期检查数据库作用执行情况,并对出现的问题做及时修正。         步骤一:数据库备份          a.  打开SQL Server Management Studio,启动SQL SERVER代理服务(注意在"控制面板-管理工具=服务"中设置"SQL Server Agent (SQL)"服务的启动类型为自动)。启动后点击"作业-新建作业",弹出一个作业属性的窗口,在"常规"栏目里可以先给作业命名,假设为"u9备份"。          b.  在"步骤"栏目里新建一个步骤名为"备份当前u9数据库",类型为"T-SQL",数据库选择你要操作的数据库(假设为"u9"),命令窗口里填入备份的SQL语句,假设备份数据放在"D:\u9databack"里,备份文件命名格式为"u92012-03-02.BAK",那么语句如下:          declare @filename varchar(255)          select @filename='D:\u9databack\u9'+convert(varchar(10),getdate(),121)+'.BAK'          backup DATABASE [totnetcms] to disk=@filename WITH NOFORMAT, NOINIT,  SKIP, REWIND, NOUNLOAD, COMPRESSION,STATS = 10          go          在步骤属性的高级的"成功时要执行的操作"选择"转到下一步"即可,这样"备份当前u9"的步骤已经建立好。          c.  u9备份"作业属性的计划栏目里,设置作业的执行时间。新建一个作业计划,命名为"u9databack备份",再选择执行的周期,例如每天凌晨2点开始执行。          最后保存整个"u9备份"的作业,每天凌晨2点就会自动备份数据库u9了。     步骤二:删除旧数据库备份文件 "u9备份"作业属性的计划栏目里,设置作业的执行时间          新建一个作业计划,命名为"u9databack备份删除",再选择执行的周期,例如每天凌晨2点开始执行。          最后保存整个"u9备份"的作业,每天凌晨2点就会自动备份数据库u9,并且自动删除3天前的u9数据库备份文件了。                    a.  打开SQL Server Management Studio,启动SQL SERVER代理服务(注意在"控制面板-管理工具=服务"中设置"SQL Server Agent (SQL)"服务的启动类型为自动)。启动后点击"作业-新建作业",弹出一个作业属性的窗口,在"常规"栏目里可以先给作业命名,假设为"u9备份"。          b.  我们可以设置只保留3天内的备份数据,那么必须删除3天前的数据备份文件。在"U9备份"作业属性窗口的步骤栏目里,建立第二个步骤命名为"删除旧有u9"。同样类型为"T-SQL",命令窗口里填入一下SQL语句:          DECLARE @date DATETIME          SELECT @date= getdate()-3--删除3天前备份          execute master.dbo.xp_delete_file 0,N'D:\u9databack',N'bak',@date,1          go          此命令会删除"D:\u9databack"里3天前的.BAK或.TRN格式的文件,不用指定文件名什么,因为SQL SERVER的备份文件里包含了时间属性在里面。在步骤属性的高级的"成功时要执行的操作"选择"退出报告成功的作业"即可。这样第二个步骤已经建立好。          c.  u9备份"作业属性的计划栏目里,设置作业的执行时间。新建一个作业计划,命名为"u9databack备份",再选择执行的周期,例如每天凌晨2点开始执行。          最后保存整个"u9备份"的作业,每天凌晨2点就会自动备份数据库u9了。     步骤三:备份数据库日志          在备份数据库日志(做截断)前,要先做一次数据库的完整备份和一次日志备份。          新建作业计划,设置为"备份当前u9数据库日志",执行脚本如下(注意根据实际修改相应路径和数据库名称)。设置执行时间为每30分钟执行一次。          declare @filename varchar(255) declare @time varchar(255) select @time= replace(replace(replace(CONVERT(varchar, getdate(), 120 ),'-',''),' ',''),':','') select @filename='S:\databack\'+@time+'.trn' BACKUP LOG [JSXR14] TO  DISK = @filename WITH NOFORMAT, NOINIT, SKIP, REWIND, NOUNLOAD,  STATS = 10 go            步骤四:删除旧数据库日志备份          新建数据库日志删除作用,每天执行一次即可。执行脚本如下(删除3天前日志备份):          DECLARE @date DATETIME          SELECT @date= getdate()-3--删除3天前备份          execute master.dbo.xp_delete_file 0,N'S:\databack',N'trn',@date,1          go         ---------------------------------- 姓名:张刚 部门:U9平台技术部    

U9并行环境配置指南

by 张刚 2014.2.26 11:27
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 environment.xml配置[注意:是2个文件都要修改] portal\bin\environment.xml、portal\applicationserver\bin\environment.xml文件中,如下节点是并行计算的配置节: <Parallel>            <MaxDegreeOfParallelism>8</MaxDegreeOfParallelism> 说明:这里16应该根据客户的app服务器的CPU核数来配置,规则是配置为APP服务器CPU核数的一半。如果是8核CPU,则配置为4.            <EnableParallelEngine>true</EnableParallelEngine>            <EnableDTCTransaction>true</EnableDTCTransaction> </Parallel> 修改后重启IIS。 DTC配置 DTC配置【注意:应用服务器和数据库服务器都要检查】 在应用服务器和数据库服务器的【管理工具】——【组件服务】中配置一下即可,如图: 配置DTC应注意: 1)应用服务器和数据库服务器都需要启动DTC服务 2)应用服务器和数据库服务器最好关闭防火墙,如果开启,请把DTC加入例外 3)应用服务器不能安装群集服务组件,如果安装请删除,删除如图     -------------------------------- 姓名:张刚 部门:U9平台技术部      

关于SQL Server中U9数据库表文件损坏报错修复说明

by 张刚 2013.9.5 15:01
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。问题:       在u9的日常操作功能点操作中,有时会收到如下错误:系统断定检查已失败。有关详细信息,请查看 SQL Server 错误日志。通常,断定失败是由软件错误或数据损坏导致的。若要检查数据库是否已损坏,请考虑运行 DBCC CHECKDB。一般这类问题,表明u9或系统数据库文件出现损坏了,需要人工对数据库进行修复。(如果是系统数据库表损坏,可能就无法修改了,需要重新sql server服务或换db服务器部署u9数据库)。  造成这类问题的原因,一般有如下三类:  1.  非法关闭db服务器造成磁盘出现故障,如坏道等。造成数据库表出现损坏。 2.       磁盘使用年限达到寿命(服务器磁盘一般寿命为3到5年) 3.       Sql Server出现故障,导致数据表出现不符合数据库规则的数据,导致sql执行报错。 目前对此类问题,已处理过三类,下面分别说明处理方法。 u9数据库表出现分配错误和一致性(系统表出现此类错误,一般无法修改系统表)处理方法:  1.       在u9的数据库上,执行dbcc checkdb。执行结果如下:          2.       根据错误提示,是对象2104199092的索引存在问题。 重建表MRP_BOMMapping的所有索引。在执行dbcc checkdb不在报错。前台操作MRP计算,成功报告完成。 U9数据库表损坏或出现异常记录。 1.       通过dbcc checkdb可找到出现问题的数据表。 2.       可以使用DBCC CHECKTABLE来修复。 use 需要修复的数据库实体的名称 declare @dbname varchar(255) set @dbname='需要修复的数据库实体的名称' exec sp_dboption @dbname,'single user','true' dbcc checktable('需要修复的数据表的名称',REPAIR_ALLOW_DATA_LOSS) dbcc checktable('需要修复的数据表的名称',REPAIR_REBUILD) ------把' 需要修复的数据表的名称'更改为执行DBCC CHECKDB时报错的数据表的名称 exec sp_dboption @dbname,'single user','false' 3.       如果是出现异常记录,一般根据提示的sql,可以定位是哪个表的记录出现了问题。对于这种情况,一般无法通过dbcc checktable方式修复。可采用重新建议新表,将正确数据移到新表的方法解决。同时给新表加上原表的索引。 数据库服务器异常 如果通过dbcc checkdb后,没有u9数据库分配错误和一致性错误,有可能是数据库服务内部出现问题。最近处理的三雄客户,查看sql server日志,提示是数据库内存锁存在冲突。后续重启数据库后,问题解决。  

并行计算技术案例分享:生产订单备料查询效率问题

by hbzhang 2013.3.26 11:21
从去年U9引入并行计算以来,并行计算技术已多次在关键时刻立功。并行计算无法在U9应用的场景,主要发生在那种有N层主子关系的实体。计算开销集中在子孙层级,但用并行计算优化后,发现Session.Commit会触发对最上层父实体的修改,导致大量的实体已修改并发冲突。
相反,我们发现,对于纯查询逻辑的场景,可以说是最易于采用并行计算技术的时候。毫无风险,且改造代价极低。值得在后续工作中大力推广。

本案例最有趣的地方在于,并行粒度的选择对并行效果的显著影响!以前只是在理论书看到这个反模式,这次实际发生了一次,的确教训深刻。
[更多...]

如何排查多个工作流引擎连接同一数据库的情况

by 吕洪雨 2012.12.14 10:21
工作流 同一数据库 [更多...]

主子关系批量加载子实体

by 周运禄 2012.11.23 14:42
应用代码中批量加载子实体,以大幅减少后台查询语句 [更多...]

windbg抓指定SQL的调用栈分享

by 张刚 2012.9.20 08:35
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 主题 windbg抓指定SQL的调用栈分享 发件人 zhanggangb 收件人 'zhb@yonyou.com'; 'yangy@yonyou.com'; 'yinhl@yonyou.com'; 'zhangguo@yonyou.com'; 'zhangjlg@yonyou.com'; 'chenlib@yonyou.com'; 'zhanggangb@yonyou.com'; 'liuxla@yonyou.com' 发送时间 2012年9月18日 15:23     大家好:          以前经常在SQL Trace中,看到一些有问题的SQL语句,由于不清楚SQL代码的业务,无法确定其调用栈。后续由于UMTrace工具的出现,找w3wp进程中的SQL调用栈问题基本上解决了。但对于一些Job服务,MailServer等服务发出的SQL,由于UMTrace不支持,所以不得还得考虑一种更好的方式来达到目的。 目前主要有两种方式来根据SQL找到其相关调用栈。但这两种方法在使用时,经常由于SQL执行次数等原因,有时很难获得想要的调用栈。一直有想通过用windbg,在Query方法执行时,加条件断点,判断SQL参数中,是否包涵指定的SQL字符串,来决定是否中断并输出所用要关注SQL的调用栈。但几次动手写这个脚本,都没成功。这次由于前段时间在分析MailServer的消耗,要找一些SQL的调用栈,过程很痛苦,就下决心研究下如何实现以前的这个想法,这次终于成功了。和大家分享下。同时也非常感谢尹洪亮的指导。     第一种方式:阻塞表的执行 ALTER DATABASE [u9shuanghu20111104jichushuju] set READ_COMMITTED_SNAPSHOT on WITH ROLLBACK IMMEDIATE     begin tran select COUNT(*) from [CA_AllocationMethod] with (tablock,xlock)     rollback tran     select  A.*, A1.[Name], A1.[Description], A2.[Code] as SysMlFlag from  [CA_AllocationMethod] as A  left join Base_Language as A2 on (A2.Effective_IsEffective = 1) left join [CA_AllocationMethod_Trl] as A1 on (A1.SysMlFlag = A2.Code) and (A.[ID] = A1.[ID]) where  (A.[ID] = @ID)     第二种方式:阻塞表的执行 begin tran aa alter table  [CS_Workflow_DefineVersion] ADD address VARCHAR(30)     rollback sp_who2     dbcc inputbuffer(73)     第三种方式:在windbg中过滤SQL表输出调用加条件断点,判断SQL参数中,是否包涵指定的SQL字符串,来决定是否中断并输出调用栈     步骤: 1.通过!name2ee XXX.Util.DataAccess.dll XXX.Util.DataAccess.AbstractDataAccessor.Query,找到其Query方法的编译后的JITTED Code Address。如:000007ff01593b00 2.Query参数是(SqlConnection conn,string Sql)。由于sql是函数的第二个参数,因此!do rdx后将结果赋值给变量,在通过$spat来做字符串判断是否包涵指的字符串,来决定是否中断并输出调用栈     主要命令如下:     !name2ee UFSoft.UBF.Util.DataAccess.dll UFSoft.UBF.Util.DataAccess.AbstractDataAccessor.Query     bp 000007ff01593b00 ".foreach( wordxxx {!do @r8;} ) { .if($spat(\"${wordxxx}\", \"*CS_Workflow_DefineVersion*\")) {!do @r8;!clrstack}; };g;"     输出结果如下: ---------------------------------------------------------------------------- Email:zhanggangb@ufida.com Add:023030 TEL:62437521 Mobie:15652302617 QQ:175582488 U9性能优化部 张刚    

关于修复会计期间实时更新Bug导致U9环境性能下降问题

by 张刚 2012.8.3 10:44
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 主题 关于修复会计期间实时更新Bug导致U9环境性能下降问题 发件人 张刚 收件人 zhanggangb@yonyou.com 发送时间 2012年8月3日 10:44     适用范围。 目前需要修改的只有v2.1sp1版本,且其InvTrans补丁还没有更新到2012年3月16日的客户。其他版本没有此问题,无需修改 手工修复步骤。 操作前重要提示: 下列步骤可能会对现有数据造成影响,操作前请务必对客户现有数据进行备份操作!没有特别说明,请按步骤顺序执行,每步都要复制该步骤的完整脚本(如果该步骤有脚本),并确定执行成功,再进行下一步操作! 确定环境版本,注意查询结果的红色部分,如果环境版本是V2.1SP1且InvTrans补丁日期小于2012年3月16,则依次执行下列步骤, 否则直接从步骤c开始执行。 --检查环境版本 select*from dbo.system_InstalledServicePack select UpdateTime,Code from[system_InstalledAppModulePack]where ModuleCode='INVTrans'order by UpdateTime desc ----select count(id) from UBF_Job_Request         确认会计期间实时更新参数已置为false,设置方法:Portal->库存管理->参数设置,设置会计期间实时更新为不勾选。 首先执行数据库查询 select count(0) from ubf_job_request where state = 2, 如果返回的记录数>10万,则依次执行步骤d和步骤e,否则直接执行步骤f. 创建清理Job存储过程 --创建存储过程:清除状态为完成且超过天的UBF_Job_Request 的数据 IF EXISTS(SELECT*FROM sys.objects WHERE object_id=OBJECT_ID(N'[dbo].[P_CleanJob]')AND type in(N'P',N'PC')) DROP PROCEDURE[dbo].[P_CleanJob] GO create procedure[dbo].[P_CleanJob] as begin     declare @lastMonth as datetime set @lastMonth=DATEADD("Month",-1,GETDATE())     --保留近一个月的数据     delete UBF_Job_Request_Trl where ID in(select top(400)id from UBF_Job_Request where state=2 and CreatedOn<@lastMonth) delete top(400)from UBF_Job_Request where state=2 and CreatedOn<@lastMonth while @@ROWCOUNT> 0 begin        delete UBF_Job_Request_Trl where ID  in(select top(400)id from UBF_Job_Request where state=2 and CreatedOn<@lastMonth)        delete top(400)from UBF_Job_Request where state=2 and CreatedOn<@lastMonth     end end 执行清理Job存储过程 --执行清除 exec P_CleanJob 注意: 最好选择用户不操作的情况下来操作,避免影响作现场用户使用,  操作过程会比较长,但中止并不会产生不良影响,下次仍可再次执行。 系统调度配置    首先再请求监控—查询,查找状态为"等待执行"的,在查询结果里面看编码里面是否包含有 "R-logdeleteConfigBP"字样的调度: A:如果有多个,则可以只保留一个,将其余几个挂起、删除;或者可以都保留。然后退出操作即可! B:如果没有,则到系统管理—系统日志清除—执行调度—重复执行,选择调度方案-保存,然后退出操作即可!    如果调度方案不合适的话可以新建调度方案(调度方案周期单位选"周"即可)。 (这里说的"不合适"的意思是调度方案的执行时间为上午6点—晚7点,因为执行调度的时候 系统运行速度可能会受点影响,所以选择用户不使用系统的时候操作,比如晚上12点或凌晨3点 等,这些时间点都是可以的。) 下图大概演示了操作过程。    3.保存             ---------------------------------------------------------------------------- Email:zhanggangb@ufida.com Add:023030 TEL:62437521 Mobile:18601103824 QQ:175582488 U9性能优化部 张刚    

ufida.u9.sql.clrlib.dll环境问题总结

by 张刚 2012.8.3 10:30
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 主题 ufida.u9.sql.clrlib.dll环境问题总结 发件人 张刚 收件人 尹洪亮 抄送 zhb@ufida.com.cn; 舒展; 'houchao'; 张刚; yangy@ufida.com.cn; 丁佰超 发送时间 2012年1月4日 9:38 附件 <<UFIDA.U9.SQL.CLRLib.dll>>     大家好:       在平常支持客户现场中,时不时的会出现一些由于ufida.u9.sql.clrlib。dll引起的一些环境问题。比如今天早上出现的美心恢复数据库的加载ufida.u9.sql.clrlib.dll问题。现对出现过的与ufida.u9.sql.clrlib.dll问题做下总结,方便大家在日常支持中快速找到对应方案.对应的DLL是ufida.u9.sql.clrlib。最新版本见附件。       问题一:错误如下(今天早上美心客户反馈在恢复数据库后,报的错误): 在尝试加载程序集 ID 65537 时 Microsoft .NET Framework 出错。服务器可能资源不足,或者不信任该程序集,因为它的 PERMISSION_SET 设置为 EXTERNAL_ACCESS 或 UNSAFE。 请重新运行查询,或检查有关的文档了解如何解决程序集信任问题。有关此错误的详细信息:  System.IO.FileLoadException: 未能加载文件或程序集"ufida.u9.sql.clrlib, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null"或它的某一个依赖项。发生与安全有关的错误。 (异常来自 HRESULT:0x8013150A) System.IO.FileLoadException:     在 System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& st... ...       对于此问题,我找到杨砚发表在u9blog上的解决方案处理好了。具体方案如下:    现象:portal可以登录,但保存单据时生成ID的过程中会报"CLR异常..."或 "System.IO.FileLoadException: 未能加载文件或程序集"ufida.u9.sql.clrlib, Version=0.0.0.0。。" 解决方法:此问题以前黄卫提供个一个脚本如下: --直接执行 EXEC sp_configure 'clr enabled', 1 RECONFIGURE WITH OVERRIDE GO     --将yourdatabasename替换 /****/ Alter Database yourdatabasename SET TRUSTWORTHY ON   go use yourdatabasename go EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false go /****/     问题二:在portal查询时,会报如下错误: 解决方法:(UFIDA.U9.SQL.CLRLib.dll文件见附件) EXEC dbo.sp_changedbowner @loginame = N'sa', @map = false GO alter database pengchi20110105zg set trustworthy on  --换成相应的数据库 go     alter ASSEMBLY CLRLib FROM 'f:\newclr\UFIDA.U9.SQL.CLRLib.dll' WITH PERMISSION_SET = UNSAFE  ,UNCHECKED DATA; go alter FUNCTION [dbo].F_GetIDTable2                     (@StringSerials nvarchar(max))          RETURNS TABLE (id nvarchar(128)) AS EXTERNAL NAME [CLRLib].[UFIDA.U9.SQL.CLRLib.F_GetIDTable2].[CLR_charlist_split] GO     ---------------------------------------------------------------------------- Email:zhanggangb@ufida.com.cn Add:023030 TEL:62437521 Mobie:18601103824 U9性能优化小组 张刚

Grid上使用callback返回时产生的一些问题

by lkc 2012.5.22 10:15
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。问题现象:杂发单个性化——通过关联计算,弹性域字段z001*库存数量=成本数量,可正常算出成本数量,但手工修改成本数量保存后,成本数量又恢复到个性化计算出的数量。 经过跟踪发现,修改成本数量时会引发引用开发的callback,这个逻辑返回的js如下 "var ThisGrid = $find('u_M_p0_DataGrid8');ThisGrid.SetReferenceCellValue(0,ThisGrid.GetColumnIndex('SUToCURate'),'2.3333333','2.3333333','2.3333333');;var ThisGrid = $find('u_M_p0_DataGrid8');ThisGrid.SetReferenceCellValue(0,ThisGrid.GetColumnIndex('SUToCURate'),'2.3333333','2.3333333','2.3333333');var ThisGrid = $find('u_M_p0_DataGrid8');ThisGrid.SetReferenceCellValue(0,ThisGrid.GetColumnIndex('CostMny'),'0.000000000','0.000000000','0.000000000');;var ThisGrid = $find('u_M_p0_DataGrid8');ThisGrid.SetReferenceCellValue(0,ThisGrid.GetColumnIndex('SUToCURate'),'2.3333333','2.3333333','2.3333333');var ThisGrid = $find('u_M_p0_DataGrid8');ThisGrid.SetReferenceCellValue(0,ThisGrid.GetColumnIndex('CostMny'),'0.000000000','0.000000000','0.000000000');var ThisGrid = $find('u_M_p0_DataGrid8');ThisGrid.SetReferenceCellValue(0,ThisGrid.GetColumnIndex('StoreUOMQty'),'6','6','6');;;;"  平台的固有逻辑认为只要是调用参照赋值逻辑,能赋值就一定应该触发事件 代码如下     SetReferenceCellValue : function(rowIndex,columnIndex,value,code,text,isSynchUpdateValue4P)     {         if(this.m_gridFaciesManager!=null)         {   //设置参照单元值             //this.get_element().NotEndEdit = true;             //this.m_gridBodyEventsHandler.CanEndEdit(false);             //this.get_element().NotEndEdit = false;               this.m_gridFaciesManager.SetReferenceCellValue(rowIndex,columnIndex,value,code,text,isSynchUpdateValue4P);             /*     delete status change                 var row =this.D_Body.rows[rowIndex];                             if(row.Status==RowStatus.Empty)             {   //设置行位被修改状态                            row.Status=RowStatus.Added;             }else if(row.Status==RowStatus.UnChanged)             {   //设置行位被修改状态                            row.Status=RowStatus.Modified;             }                    */             var cellData = new CellDataContent("",value);              this.OnCellDataValueChanged(cellData,rowIndex,columnIndex);         }        }   而本例中列StoreUOMQty实际上是一个数字列 也就是在赋值时应该使用SetCellValue 在该方法中会比较新旧值以判断是否触发事件   if(valueString!=oldV){                       var cellData = new CellDataContent("",valueString);                        this._owner.OnCellDataValueChanged(cellData,rowIndex,columnIndex);             } 小结:如果使用SetReferenceCellValue方法赋值,则每次赋值都会触发值改变事件,不论新旧值是否相等;使用SetCellValue方法赋值,则会比较新旧值,不等时才会触发值改变事件 所以这是应用开发使用方法不当而在个性化中暴露出来的问题 反思:callback的时候可能会修改很多列 也可能产生庞大的脚本来更新界面上grid控件上的值 但是在服务器端多判断一下这个值是不是需要回写(也许现在前端值和model值就是一样 的呢)根据判断结果去掉多余的脚本会不会也有一定的性能优化呢?    留个小疑问:怎么判断产生的js是调用参照赋值还是普通赋值呢?      

U9性能监控工具UMTracer V1.1发布啦

by 张刚 2012.5.8 16:00
U9性能监控工具UMTracer V1.1发布啦 [更多...]

关于碎片脚本的改动说明

by 张刚 2011.9.29 16:51
注:脚本执行有风险,对于客户正式环境请在研发指导下执行。 说明:由于V2.5版本,将碎片整理整合到了产品中(在调度里面配置),具体可参见下面说明 大家好! V2.1SP1/V2.5版本(补丁更新到6月1号(PUB/UBF/BS)),请通过在U9 UI界面配置调度方案来执行碎片整理。 建议: 在配置碎片整理时,统一为:编码:U9Index。请求名称:碎片整理。这样便于查找是否配置了碎片整理。 配置完成之后,请删除原来数据库配置碎片整理任务。 具体方法如下: 在 系统管理->请求管理 里面,保存及提交一个新的请求即可。调度方案,一般设置为一周执行一次(周六晚上执行)。     以下内容过期。 大家好:以前的碎片脚本,最近在两个客户的数据库服务器上(大运和赛棋)配置作业后,运行都报错。 对原来的脚本,做了一点改动。以后如果出现有客户碎片整理报错的,可尝试用这个新脚本试下。    SET QUOTED_IDENTIFIER ON SET NOCOUNT ON;DECLARE @objectid int;DECLARE @indexid int;DECLARE @partitioncount bigint;DECLARE @schemaname nvarchar(130); DECLARE @objectname nvarchar(130); DECLARE @indexname nvarchar(130); DECLARE @partitionnum bigint;DECLARE @partitions bigint;DECLARE @frag float;DECLARE @command nvarchar(4000); -- Conditionally select tables and indexes from the sys.dm_db_index_physical_stats function -- and convert object and index IDs to names.SELECT    object_id AS objectid,    index_id AS indexid,    partition_number AS partitionnum,    avg_fragmentation_in_percent AS fragINTO #work_to_doFROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL , NULL, 'LIMITED')WHERE avg_fragmentation_in_percent > 10.0 AND index_id > 0and object_name(object_id)<>'UBF_Assemble_Page'and object_name(object_id)<>'UBF_Sys_ExtEnumValue'; -- Declare the cursor for the list of partitions to be processed.DECLARE partitions CURSOR FOR SELECT * FROM #work_to_do; -- Open the cursor.OPEN partitions; -- Loop through the partitions.WHILE (1=1)    BEGIN;        FETCH NEXT           FROM partitions           INTO @objectid, @indexid, @partitionnum, @frag;        IF @@FETCH_STATUS < 0 BREAK;        SELECT @objectname = QUOTENAME(o.name), @schemaname = QUOTENAME(s.name)        FROM sys.objects AS o        JOIN sys.schemas as s ON s.schema_id = o.schema_id        WHERE o.object_id = @objectid;        SELECT @indexname = QUOTENAME(name)        FROM sys.indexes        WHERE  object_id = @objectid AND index_id = @indexid;        SELECT @partitioncount = count (*)        FROM sys.partitions        WHERE object_id = @objectid AND index_id = @indexid; -- 30 is an arbitrary decision point at which to switch between reorganizing and rebuilding.        IF @frag < 30.0            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REORGANIZE';        IF @frag >= 30.0            SET @command = N'ALTER INDEX ' + @indexname + N' ON ' + @schemaname + N'.' + @objectname + N' REBUILD with (Data_Compression=page)';        IF @partitioncount > 1            SET @command = @command + N' PARTITION=' + CAST(@partitionnum AS nvarchar(10));        EXEC (@command);        --PRINT N'Executed: ' + @command;    END; -- Close and deallocate the cursor.CLOSE partitions;DEALLOCATE partitions; -- Drop the temporary table.DROP TABLE #work_to_do;GO 主要改动如下: 1. 去掉job中的sql语句中的print语句 2. 在脚本开关加 SET QUOTED_IDENTIFIER ON             发件人: xieql [mailto:xieql@ufida.com.cn] 发送时间: 2011年9月29日 14:01 收件人: 张刚 抄送: 扬砚 主题: Re: 答复: 山西大运执行作业错误,请帮忙看看     经试验执行成功     2011-09-29     xieql     发件人: 张刚 发送时间: 2011-09-29  12:44:01 收件人: 解其亮 抄送: 扬砚 主题: 答复: 山西大运执行作业错误,请帮忙看看 附件里面的脚本,我测试了一下。在出错的环境上,成功执行了。请解其亮将这个脚本替换下试试看。     另附微软对此问题的说明: 这是针对sql 2000的一个微软方案,sql 2008暂时没有测试。后续需找个有问题的环境测试下。     数据库维护作业重建索引失败(因QUOTED_IDENTIFIER SET 选项的设置不正确 )      近日用户反应数据库反应很慢,查看原因为:维护作业没有执行成功,出现 [Microsoft SQL-DMO (ODBC SQLState: 42000)] 错误 1934: [Microsoft][ODBC SQL Server Driver][SQL Server]DBCC 失败,因为下列 SET 选项的设置不正确: 'QUOTED_IDENTIFIER, ARITHABORT'。      查看相关资料,microsoft提出为"当数据库包含计算列上具有索引的表时,就会出现此问题",但跟踪数据执行并没发现异常,先作个记录便于后面查询,microsoft提出变通解决此问题:EXECUTE master.dbo.xp_sqlmaint N'-S ServerName \ InstanceName -PlanID <GUID>-WriteHistory-RebldIdx 10-SupportComputedColumn',其中ServerName \ InstanceName 代表服务器名称和实例名,如果使用的 SQL Server 2000 默认实例可以使用 – S ServerName 参数中,也可以安全地忽略该参数。     详细资料地址:http://support.microsoft.com/kb/902388         ---------------------------------------------------------------------------- Email:zhanggangb@ufida.com.cn Add:023030 TEL:62437521 Mobie:18601103824 U9性能优化小组 张刚     发件人: 张刚 [mailto:zhanggangb@ufida.com.cn] 发送时间: 2011年9月29日 11:52 收件人: 解其亮 抄送: 扬砚 主题: 答复: 山西大运执行作业错误,请帮忙看看     解其亮:   你们内部有大运的数据库吗?如果有的话,可以测试下面几个方案。测试时,叫上我一块看下。 大运报的这个错误。我早上经过测试对一个我这里的一个报这个错误的库。去掉脚本中的with (Data_Compression=page) ,Job成功执行完成了。后续需要验证下面的几个方案。     对于碎片整理脚本报错的客户,目前我测试的环境有如下错误。具体有一些方案,但未完全验证完。后续需要针对不同情况进行充分验证。 查看一下job执行的历史记录,看最后脚本报错是什么错误。针对如下错误。可尝试相关方案来解决下。如果问题都可以解决。则碎片整理脚本,可做如下修改: 1. 去掉job中的sql语句中的print语句 2. SET QUOTED_IDENTIFIER ON     问题一:[SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [pk_...  该步骤失败。 解决方法:去掉job中的sql语句中的print语句     问题二:ALTER INDEX 失败,因为下列 SET 选项的设置不正确: 'QUOTED_IDENTIFIER'。请确保 SET 选项正确无误,可以用于 计算列上的索引视图和/或索引和/或筛选的索引和/或查询通知和/或 XML 数据类型方法和/或空间索引操作。。 [SQLSTATE 42000] (错误 1934).  该步骤失败。 解决方法:碎片整理的脚本前面加: SET QUOTED_IDENTIFIER ON     问题三:如果是sql 2005数据库,则将job sql 脚本中的 with (Data_Compression=page) 去掉 目前未能严格验证。晚上用赛棋客户和大运 出现错误的一个客户远程验证下。     目前情况是:赛棋客户的数据库(int7上),执行碎片整理时,报问题二错误。我将 with (Data_Compression=page)去掉,在执行就成功了。关于加SET QUOTED_IDENTIFIER ON的方法。我正在验证中。         ---------------------------------------------------------------------------- Email:zhanggangb@ufida.com.cn Add:023030 TEL:62437521 Mobie:18601103824 U9性能优化小组 张刚     发件人: 杨砚 [mailto:yangy@ufida.com.cn] 发送时间: 2011年9月29日 11:38 收件人: '张刚' 主题: 转发: 山西大运执行作业错误,请帮忙看看             发件人: xieql [mailto:xieql@ufida.com.cn] 发送时间: 2011年9月28日 17:16 收件人: 杨砚 抄送: wuzhenga@Ufida.com.cn 主题: 山西大运执行作业错误,请帮忙看看     附件中的脚本,在单独的查询窗口中执行是没有问题的,但是通过建立作业的方式执行就报如下所示的错误,请帮忙看看                     09/28/2011 02:00:01,U9_RebuiltIndex,错误,0,SQL2008,U9_RebuiltIndex,(作业结果),,该作业失败。  计划 23 (day) 调用了该作业。最后运行的是步骤 1 (span1)。.,00:00:31,0,0,,,,0 09/28/2011 02:00:01,U9_RebuiltIndex,错误,1,SQL2008,U9_RebuiltIndex,span1,,已以用户 DAYUN\Administrator 的身份执行。 Executed: ALTER INDEX [pk_SPR_SalePriceLine] ON [dbo].[SPR_SalePriceLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [IX_SalePriceLine_3] ON [dbo].[SPR_SalePriceLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [IX_ItemDepended_SPR_SalePriceLine] ON [dbo].[SPR_SalePriceLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [IX_SalePriceLine_SrcRowID] ON [dbo].[SPR_SalePriceLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [IX_SalePriceLine_CusterSite] ON [dbo].[SPR_SalePriceLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [pk_FA_AssetCardAccountInformation_Trl] ON [dbo].[FA_AssetCardAccountInformation_Trl] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [pk_AR_RecBillLine] ON [dbo].[AR_RecBillLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [UFIDA_U9_AR_Receival_RecBillLine_BusinessKey_Index] ON [dbo].[AR_RecBillLine] REBUILD [SQLSTATE 01000] (消息 0)  Executed: ALTER INDEX [pk_CA_ExpenseCostAllocRecord] ON [dbo].[CA_ExpenseCostAllocRecord] REBUILD [SQLSTATE 01000] (消息 0)  ALTER INDEX 失败,因为下列 SET 选项的设置不正确: 'QUOTED_IDENTIFIER'。请确保 SET 选项正确无误,可以用于 计算列上的索引视图和/或索引和/或筛选的索引和/或查询通知和/或 XML 数据类型方法和/或空间索引操作。。 [SQLSTATE 42000] (错误 1934).  该步骤失败。,00:00:31,16,1934,,,,0     2011-09-28     xieql

实体Cache--熊悦阅

by dbc 2011.9.19 16:35
实体Cache ,二级缓存 [更多...]

RecentComments

评论 RSS

Statistics

989 篇文章
0 个单页
613100 条评论
11 次评分
700376 次访问
访问统计开始于 2019年9月14日
平均日访问 8239 次
当前 175 人在线