解决ADCampus使用一段时间之后终端无法成功导致用户上线失败的经验案例

某学校局点使用ADCampus组网，在正常使用一段时间之后终端无法正常上线。

终端无法上线。

通过收集认证过程中调试级别的UAM日志，在日志中记录UAM回应了CODE 2类型的认证通过报文，但是因为表空间不足导致插入数据库失败，进而导致认证失败，用户无法上线。

%% 2018-01-03 10:14:08.254 ; [ERR] ; [15176] ; DbOper ; exeDbOps: error message: Could not allocate space for object &＃39;ead.TBL_ACM_DETAIL_1&＃39;.&＃39;PK_ACM_DETAIL_1&＃39; in database &＃39;ead&＃39; because the &＃39;PRIMARY&＃39; filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup. when executing insert into tbl_acm_detail_1 (event_seq_id, user_id, service_id, nat_ip, nas_ip, nas_ipv6,nas_slot, nas_sub_slot, nas_port,vlan_id, vlan_id2, wlan_ssid, access_start_time, access_end_time, access_session_time, in_octets, out_octets, in_gigawords, out_gigawords, access_rule_id, offline_cause, framed_ip_address, framed_ip_v6, mac_address, terminal_type, terminal_vendor, terminal_os, bound_domain_name, device_sn, imsi_code, imei_code, proxy_type, proxy_user, fee_type, bill_id, in_cash_used, out_cash_used, cash_used, bonus_cash, bonus_cash_used, acct_session_id, event_id, user_group_id, user_name, service_template_id, client_version, service_name, full_name, nas_id, ap_address, ap_longitude, ap_latitude, signal_strength, harddisk_sn, access_ip, access_if_desc) values (&＃39;kCNhGzEY&＃39;, 7358, 7358, 1845494270, 1845494270, &＃39;&＃39;, 0, 0, 0, 1, 0, &＃39;SDSFJY&＃39;, CONVERT(datetime, &＃39;2018-01-03 10:14:08&＃39;, 120), CONVERT(datetime, &＃39;2018-01-03 10:14:08&＃39;, 120), 0, 0, 0, 0, 0, 5, 6, 0, &＃39;&＃39;, &＃39;4C:18:9A:07:A3:AB&＃39;, &＃39;&＃39;, &＃39;OPPO&＃39;, &＃39;Android 6.x&＃39;, &＃39;&＃39;, &＃39;&＃39;, &＃39;4C-18-9A-07-A3-AB&＃39;, &＃39;&＃39;, 1, &＃39;stu72&＃39;, 2, 0, 0, 0, 0, 0, 0, &＃39;0000000420180103101154001f678708100459&＃39;, 0, 1, &＃39;stu72&＃39;, 5, &＃39;&＃39;, &＃39;4c189a07a3ab&＃39;, &＃39;stu72&＃39;, &＃39;AC&＃39;, &＃39;AC:74:09:03:0C:C0&＃39;, &＃39;&＃39;, &＃39;&＃39;, &＃39;&＃39;, &＃39;&＃39;, &＃39;110.0.1.254&＃39;, &＃39;&＃39;).
%% 2018-01-03 10:14:08.259 ; [WARN] ; [15176] ; DB ; INF  D  :||Ado error code=3092, error message=Could not allocate space for object &＃39;ead.TBL_ACM_DETAIL_1&＃39;.&＃39;PK_ACM_DETAIL_1&＃39; in database &＃39;ead&＃39; because the &＃39;PRIMARY&＃39; filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup..

%% 2018-01-03 10:14:08.259 ; [ERR] ; [15176] ; DB ; ERR  D  :||Execute sql error.

查看智能部署监控代理中运行环境，看到数据库的ead表空间已经占满，有10GB左右，如下图所示：

正常情况下数据库表空间在即将占满时会自动增长，登录数据库查看ead表的属性，也是设置了自动增长了。

那么此问题就可能出在数据库是内嵌数据库，登录数据库，新建查询语句，输入“select @@version”之后点击执行，会列出此数据库的版本，执行之后得到结果如下：

Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64)  Oct 19 2012 13:38:57  Copyright (c) Microsoft Corporation Express Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: )

通过结果可以看出此版本为内嵌数据库，是数据库的精简版，只有10GB大小的限制，当数据库达到10GB之后无法继续扩容空间。正式的数据库企业版一般都是Enterprise版本。

要实现数据库空间能自动增长，需要重新安装SQL SERVER数据库，安装企业版，而不是内嵌的数据库，同时也需要重新安装DR2000软件。而且因为涉及到数据，所以还要进行数据备份恢复操作。具体的操作步骤如下：

第一步：通过智能部署监控代理点击立即备份，将所有的数据进行备份，并且记住此时DR2000上的各个组件的版本和数据库的版本，恢复的时候要保证组件版本以及数据库版本一致；

第二步：卸载掉DR2000软件和SQL SERVER数据库，卸载之后重启服务器生效；

第三步：安装下载好的企业版数据库和DR2000软件；

第四步：登录智能部署监控代理，在运行环境中点击“立即恢复”进行数据恢复，CTRL+A选择所有的数据一起恢复即可；第五步：恢复成功之后将之前的license文件导入，然后重启服务器。起来之后再次进行认证，问题解决。

注意：

DR2000中自带的内嵌数据库只适用于测试使用，如在实际环境中使用以及安装了EIA等组件，必须使用独立的企业版数据库，否则就会导致10GB空间占满进而导致表空间无法扩容的问题。