2019周笔记（2.25-3.01）（压缩数据库）

公司穷，硬盘少，传感数据多，时不时就需要压缩数据库，这周都在干这个事，就稍微专注的看了下[DBCC SHRINKFILE ]和[DBCC SHRINKDataBase ]的区别，发现还是没看懂，而且有文章说做过多次试验后发现msdn中的说法也不是完全正确。

那这次就只记录一些比较关键的东西。首先[DBCC SHRINKFILE ]是[DBCC SHRINKDataBase ]的一个执行子集，也就是执行[DBCC SHRINKDataBase ]其实是对多个文件进行[DBCC SHRINKFILE ]操作。

基本语法：
DBCC SHRINKFILE（文件名|文件ID,希望将日志收缩到的目标大小，EMPTYFILE | NOTRUNCATE | TRUNCATEONLY）
--文件名（很多朋友这里容易填错，这里可以去数据库右键属性中，找到“文件”菜单中，里面的“逻辑名称”）
--目标大小，也就是我们希望把文件压缩到的理想尺寸，单位Mb，如果一个日志有10G，我们希望压缩到1G，但是实际数据已经占用3G，那么最终压缩出来也是3G。
--NOTRUNCATE | TRUNCATEONLY参考下面SHRINKDataBase，这里只说EMPTYFILE。它是通过把数据迁移到文件组的中的其他文件来清空源文件，然后配合使用ALTER DATABASE [数据库名称] REMOVE FILE [FileA] 命令。（可是我自己测试执行后总是提示“文件组中空间不足，无法完成清空文件操作”，有理解的童鞋可以留言跟我说下，硬盘空间肯定是足够的。）

基本语法：
DBCC SHRINKDATABASE（数据库名|数据库ID|0,目标百分比，NOTRUNCATE|TRUNCATEONLY）
--第一个参数0，表示收缩当前数据库
--目标百分比，可选，据说是只对NOTRUNCATE起作用，因为TRUNCATEONLY只是截断尾部（这个参数是最难理解的，看了好几篇文章，每个人的说法都不一样）（其中一篇博文通过测试，说明MSDN写法有误，正确的是百分比只对TRUNCATEONLY生效，对NOTRUNCATE反而没有作用http://www.mamicode.com/info-detail-1493145.html）
--第三个参数可选，NOTRUNCATE表示将文件末尾已分配的页移动到文件前面未分配的页。文件末尾的可用空间不会返回给操作系统，文件的物理大小也不会改变。TRUNCATEONLY表示将文件末尾的所有可用空间都会释放给操作系统，但不在文件内部执行页移动操作。因此，使用此参数数据文件只能收缩最近分配的区。有文章称在不选择时，会先执行NOTRUNCATE，然后执行TRUNCATEONLY。

结果集列解释。
DbId 数据库引擎试图收缩的文件的数据库标识号。
FileId 数据库引擎试图收缩的文件的文件标识号。
CurrentSize 文件当前占用的 8 KB 页数。
MinimumSize 文件最低可以占用的 8 KB 页数。 此数字对应于文件的大小下限或最初创建大小。
UsedPages 文件当前使用的 8 KB 页数。
EstimatedPages 数据库引擎估计文件能够收缩到的 8 KB 页数。

注：收缩操作不是一件值得经常执行的操作，会带来碎片， 下面带来重建索引的方法。
整理Index的方式有两种：
DBCC INDEXDEFRAG(DB, TABLE, INDEX) WITH NO_INFOMSGS 和
DBCC DBREINDEX(TABLE, '', 0)
INDEXDEFRAG是在线重整Index，不会对Table锁定，但是由于INDEXDEFRAG是对Index的重组，所以Index的数据页不一定是连续的。

DBREINDEX会对Table进行锁定，重建索引。

 

 

 

 

--2019.02.25

压缩数据库，释放物理空间
ALTER DATABASE IotDB_Beta SET RECOVERY SIMPLE
DBCC SHRINKDATABASE(IotDB_Beta,5)

//或者直接压缩日志文件

//DBCC SHRINKFILE (N'IotDB_Beta_log' , 5) 

ALTER DATABASE IotDB_Beta SET RECOVERY FULL

 

--2019.02.26
查看数据库各个表占用的空间，以及个表的索引所占空间（这个暂时不深究了，反正挺好用，观察表数据占用空间以及索引占用的空间）
;with cte as (
(select t.name as TableName,i.name as IndexName,
sum(row_count)as row_count,
SUM (s.used_page_count) as used_pages_count

FROM sys.dm_db_partition_stats AS s
JOIN sys.tables AS t ON s.object_id = t.object_id
JOIN sys.indexes AS i ON i.[object_id] = t.[object_id] AND s.index_id = i.index_id
group by t.name, i.name)
union all
(select t.name as TableName,i.name as IndexName,
sum(row_count)as row_count,
SUM (s.used_page_count) as used_pages_count
FROM sys.dm_db_partition_stats AS s
JOIN sys.views AS t ON s.object_id = t.object_id
JOIN sys.indexes AS i ON i.[object_id] = t.[object_id] AND s.index_id = i.index_id
group by t.name, i.name)
)
select
cte.TableName,
cte.IndexName,
cast((cte.used_pages_count * 8.)/1024 as decimal(10,3)) as TableSizeInMB
from cte
order by 1 desc;
go

 

--2019.02.27
一、在普通同步方法中调用异步方法。

public async Task TestAsyncMethod()
{
//do it...
}

//在主方法中调用，加上Wait();因为场景中这里不需要异步，如果不加wait()会导致TestAsyncMethod方法还没有得到结果前，程序已经往下运行。

TestAsyncMethod().Wait();

同样的场景如果需要拿到异步方法的返回值

public async Task<int> TestAsyncMethodWithReturn()
{
    //do it...
    return 0;
}

//主方法中

TestAsyncMethodWithReturn().Wait();
int i = TestAsyncMethodWithReturn().GetAwaiter().GetResult();

 

二、相反的，如果想在异步方法中去调用同步方法。出现这想法，是因为我本来有一系列webApi异步方法在执行，异步方法的最后一步去调用spring Dao操作数据库，这个是不能异步的，所以只能在异步中去调用同步方法，最开始我的写法是这样：

public async Task<int> AsyncExecuteSql(string sql)
{
    Task<int> task = new Task<int>(() =>     baseDao.ExecuteNonQuerySql(sql));
    task.Start();
    int x = await task;
    //或者
    //int x = await Task.Run(() => baseDao.ExecuteNonQuerySql(sql)); 
    return x;
}

一直都执行的好好地，我以为没什么问题，直到有一天我写了一个大批量导入演示数据的功能，其中我用winform多次调用其中一个异步方法时，莫名其妙只执行一次，但是就是不返回信息，导致所有程序阻塞。后来查了好久，看到了微软文档中一个官方方法，用委托方法。（https://docs.microsoft.com/zh-cn/dotnet/standard/asynchronous-programming-patterns/calling-synchronous-methods-asynchronously）

/*第一步创建异步回调委托*/
/// <summary>
/// 在异步方法中调用同步数据库操作方法委托
/// </summary>
/// <param name="sql"></param>
/// <returns></returns>
public delegate int AsyncExecuteSqlCaller(string sql);

/*第二步用委托去调用需要被调用的方法*/
/// <summary>
/// 直接执行拼接好的SQL（异步）
/// </summary>
/// <param name="sql"></param>
public async Task<int> AsyncExecuteSql(string sql)
{

    AsyncExecuteSqlCaller caller = new AsyncExecuteSqlCaller(baseDao.ExecuteNonQuerySql);
    IAsyncResult result = caller.BeginInvoke(sql, null, null);
    int x = caller.EndInvoke(result);//这里会阻塞线程，所以这种方法不能用在视图层，否则会卡死界面。 
    return x;
}

修改完成后，最终测试在webApi、和winform中都能正常运行。但是我依旧不明白问题出在哪里，最近没有时间深究，后面再找高手指点迷津。

 

 --2019.02.28

一、MVC中如何给所有action加上校验特性，同时对个别action网开一面，例如

1、如何给控制器的每个方法都加上session校验特性，一般是进行登录判断。

　/*第一步、加上特性类*/
    public class AuthenticationAttribute : ActionFilterAttribute
    {
        public AuthenticationAttribute()
        {
            this.IsUsedAttribute = true;//这个构造方法在这个场景下是多余的，但是如果写的特写比较复杂，需要一些特定初始化时，就比较有效。
        }

        /// <summary>
        /// 是否启用session验证
        /// </summary>
        public bool IsUsedAttribute
        {
            get;
            set;
        }

        public override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            if (filterContext.HttpContext.Session["UserID"] == null || string.IsNullOrWhiteSpace(filterContext.HttpContext.Session["UserID"].ToString()))
            {
                if (IsUsedAttribute)
                {
                    filterContext.Result = new RedirectToRouteResult("Default", new System.Web.Routing.RouteValueDictionary(new
                    {
                        action = "Login",
                        controller = "User"
                    }));
                }
            }  
            base.OnActionExecuting(filterContext);
        }
    }

 

/*第二步，把特性加到过滤器，表示所有Action 都受这个特性约束*/
    public class FilterConfig
    {
        public static void RegisterGlobalFilters(GlobalFilterCollection filters)
        {
            filters.Add(new HandleErrorAttribute());
            filters.Add(new AuthenticationAttribute());
        }
    }

 

 

/*第三步，在不需要的action前单独设置*/

        [AuthenticationAttribute(IsUsedAttribute = false)]
        public ActionResult Login()
        {
            return View();        
        }DBCC SHRINKFILE (N'DB_Name_log' , 11, TRUNCATEONLY)