最新评论
Alvin 2011-01-07 14:27
写了这么多,我们来总结一下:
第一步:加载程序集时是否提供了public key token,如果未提供则直接使用probing(探测)
第二步:如果提供了public key token,则应用版本策略,版本策略有三种级别:应用程序级,发布者,机器级
第三步:应用版本策略后就在GAC里找
第四步:如果未找到则查看是否提供了<codeBase>,如果提供了,则查看引用是否匹配,如果不匹配则加载失败。
第五步:如果为提供<codeBase>则开始探测了。如果探测到了,则检查引用是否匹配。
在上面过程中,如果程序集成功加载后,第二次再需要加载的时候则直接使用前面加载的就行了,如果程序集加载失败,第二次再次这样加载的时候,则直接失败(这个特性是.NET 2.0新增的)。
Alvin 2011-01-07 14:27
在codeBase元素里,根据版本号,映射到具体的文件,该文件可以在本地硬盘上,也可以在远程web服务器上。如果提供了codeBase那就看看是不是我们想要的那个程序集,如果是那就传递给底层的Assembly Loader加载之。如果不是那就加载失败了。如果没有提供codeBase。那Assembly Resolver就要搜索一系列的目录,这个过程就称之为probing(探测)。probing只会搜索应用程序的根目录,以及其子目录,比如应用程序放在c:\app下面,那么probing就只会探测app以及app下面的目录,而不会探测到c:\other这个目录里面去。那如果c:\app的子目录极其复杂,那搜索起来岂不是非常费劲,如果真的是这样,我们可以通过配置文件指定探测的目录,而将其余的排除:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="common;shared" />
</assemblyBinding>
</runtime>
</configuration>
这样就只会在common和shared这两个子目录里探测了,其余的目录一律排除在外。
Alvin 2011-01-07 14:12
CLR Loader
CLR Loader可以说是整个.NET的基础元素之一,它就是用来加载托管程序集、模块、类型等的。
CLR Loader与传统的C++ Loader不同,它是按需加载,当需要的时候才加载这个程序集,这样一来就会加快程序的启动速度,降低系统要求的资源。
注意
如此一来,如果一个类型中有一个方法里引用了另外一个类型,但幸运的是,这个方法永远都没有执行过,那么被引用的类型也永远不会被加载了。
那我如果想我的程序集被加载该怎么办呢?可以在必定加载的程序集中设置一个静态字段,而这个静态字段的类型就定义在想被加载的程序集中。
CLR Loader加载程序集是由JIT编译器决定的,JIT编译器的编译单元是一个方法,当JIT编译一个方法的时候发现方法内引用了一个定义在别的程序集的类型,CLR Loader首先就会加载这个程序集。那CLR Loader又如何知道这个类型定义在哪个程序集中呢?又如何定位这个程序集呢?
类型处于哪个程序集?
这个问题就依赖Metadata。我们先来写个小程序看看:
Alvin 2011-01-07 13:50
注意
如此一来,如果一个类型中有一个方法里引用了另外一个类型,但幸运的是,这个方法永远都没有执行过,那么被引用的类型也永远不会被加载了。
那我如果想我的程序集被加载该怎么办呢?可以在必定加载的程序集中设置一个静态字段,而这个静态字段的类型就定义在想被加载的程序集中。
深蓝 2009-06-02 22:15
数据库分区的分区条件最好有实际意义,建议按天来分区,或者2天一个区之类的,一般查询都是按某天来查。当然这还要看你的查询条件,如果条件总是按月来查的,那么分区就没有多大的意义了。看你查询从表的条件吧!
我也对SQL Server 数据库优化很感兴趣,楼主有空我们可以一起探讨下,我QQ:12195844
我也对SQL Server 数据库优化很感兴趣,楼主有空我们可以一起探讨下,我QQ:12195844
elevenbus 2009-06-02 14:37
--引用--------------------------------------------------
彦斌: 大家强.
疑问:表分区是什么? 是不是一到一个月(假设月为分区单位).就要自动生成另一个表.那如果取数据是取跨月的.那就得从多个表中取值.是吗?
--------------------------------------------------------
肯定要生成一个分区表的,不过这个表是你手动生成的或利用程序生成
跨月取数据确实要到多个分区表,不过与你编写程序并没有关系,有分区函数控制,程序还是一样的
彦斌: 大家强.
疑问:表分区是什么? 是不是一到一个月(假设月为分区单位).就要自动生成另一个表.那如果取数据是取跨月的.那就得从多个表中取值.是吗?
--------------------------------------------------------
肯定要生成一个分区表的,不过这个表是你手动生成的或利用程序生成
跨月取数据确实要到多个分区表,不过与你编写程序并没有关系,有分区函数控制,程序还是一样的
彦斌 2009-06-02 13:15
大家强.
疑问:表分区是什么? 是不是一到一个月(假设月为分区单位).就要自动生成另一个表.那如果取数据是取跨月的.那就得从多个表中取值.是吗?
疑问:表分区是什么? 是不是一到一个月(假设月为分区单位).就要自动生成另一个表.那如果取数据是取跨月的.那就得从多个表中取值.是吗?
elevenbus 2009-06-02 12:51
刚才又去csdn问这个同一磁盘单一分区和多分区的问题
朋友们说把数据布在同一磁盘的不同分区和同一磁盘的单一分区,性能并不会提升
朋友们说把数据布在同一磁盘的不同分区和同一磁盘的单一分区,性能并不会提升
elevenbus 2009-06-02 11:16
--引用--------------------------------------------------
Alvin: @killkill
关于并行写入
<a href="http://www.cnblogs.com/samen168/archive/2007/06/12/780416.html" target="_new">http://www.cnblogs.com/samen168/archive/2007/06/12/780416.html</a>
文件和文件组填充策略
文件组对组内的所有文件都使用按比例填充策略。当数据写入文件组时,SQL Server 数据库引擎按文件中的可用空间比例将数据写入文件组中的每个文件,而不是将所有数据都写入第一个文件直至其变满为止。然后再写入下一个文件。例如,如果文件 f1 有 100 MB 可用空间,文件 f2 有 200 MB 可用空间,则从文件 f1 中分配一个区,从文件 f2 中分配两个区,依此类推。这样,两个文件几乎同时填满,并且可获得简单的条带化。
--------------------------------------------------------
这种方式提高的速度比较有限,我在有200W的数据测试,本来我以为分布在不同的区上,比分布在一个区上速度应该是 多个分区:1 但是事实上并没有提高那么多的,这样的简单条带只能使用一个分区索引,不能像分区表那样多分区索引,我这样理解
Alvin: @killkill
关于并行写入
<a href="http://www.cnblogs.com/samen168/archive/2007/06/12/780416.html" target="_new">http://www.cnblogs.com/samen168/archive/2007/06/12/780416.html</a>
文件和文件组填充策略
文件组对组内的所有文件都使用按比例填充策略。当数据写入文件组时,SQL Server 数据库引擎按文件中的可用空间比例将数据写入文件组中的每个文件,而不是将所有数据都写入第一个文件直至其变满为止。然后再写入下一个文件。例如,如果文件 f1 有 100 MB 可用空间,文件 f2 有 200 MB 可用空间,则从文件 f1 中分配一个区,从文件 f2 中分配两个区,依此类推。这样,两个文件几乎同时填满,并且可获得简单的条带化。
--------------------------------------------------------
这种方式提高的速度比较有限,我在有200W的数据测试,本来我以为分布在不同的区上,比分布在一个区上速度应该是 多个分区:1 但是事实上并没有提高那么多的,这样的简单条带只能使用一个分区索引,不能像分区表那样多分区索引,我这样理解
Alvin 2009-06-02 02:03
@killkill
关于并行写入
http://www.cnblogs.com/samen168/archive/2007/06/12/780416.html
文件和文件组填充策略
文件组对组内的所有文件都使用按比例填充策略。当数据写入文件组时,SQL Server 数据库引擎按文件中的可用空间比例将数据写入文件组中的每个文件,而不是将所有数据都写入第一个文件直至其变满为止。然后再写入下一个文件。例如,如果文件 f1 有 100 MB 可用空间,文件 f2 有 200 MB 可用空间,则从文件 f1 中分配一个区,从文件 f2 中分配两个区,依此类推。这样,两个文件几乎同时填满,并且可获得简单的条带化。
关于并行写入
http://www.cnblogs.com/samen168/archive/2007/06/12/780416.html
文件和文件组填充策略
文件组对组内的所有文件都使用按比例填充策略。当数据写入文件组时,SQL Server 数据库引擎按文件中的可用空间比例将数据写入文件组中的每个文件,而不是将所有数据都写入第一个文件直至其变满为止。然后再写入下一个文件。例如,如果文件 f1 有 100 MB 可用空间,文件 f2 有 200 MB 可用空间,则从文件 f1 中分配一个区,从文件 f2 中分配两个区,依此类推。这样,两个文件几乎同时填满,并且可获得简单的条带化。
killkill 2009-06-01 22:51
@Alvin
参考了园子里的一些文章 , 能不能提供地址。
-----
多磁盘时文件分布在不同磁盘上可以提高查询速度。
-----
这个是真的,但是你就4块SAS,做RAID之后,就应该看成是一块磁盘了。
-----
分别读几个较小的文件,肯定比对一个大文件快一些。
-----
这个也许是真的,但是怎么知道SQL Server是怎么做的呢?
参考了园子里的一些文章 , 能不能提供地址。
-----
多磁盘时文件分布在不同磁盘上可以提高查询速度。
-----
这个是真的,但是你就4块SAS,做RAID之后,就应该看成是一块磁盘了。
-----
分别读几个较小的文件,肯定比对一个大文件快一些。
-----
这个也许是真的,但是怎么知道SQL Server是怎么做的呢?
Alvin 2009-06-01 22:23
@Keep Walking
列名是比较特色,客户也有意见。我们项目经理随便写的!
olap因为代码都以完成,时间也允许,没有采用的可能了。
如果分区,分区函数考虑基于SessionID。因为主从表是以SessionID关联的,
且都是主键或主键的一部分,已经有聚集索引。查询时应该是最优的。日期不予考虑是因为现在已经是月表,再基于日期,粒度不好划分,并且日期不是表连接的关键字。
列名是比较特色,客户也有意见。我们项目经理随便写的!
olap因为代码都以完成,时间也允许,没有采用的可能了。
如果分区,分区函数考虑基于SessionID。因为主从表是以SessionID关联的,
且都是主键或主键的一部分,已经有聚集索引。查询时应该是最优的。日期不予考虑是因为现在已经是月表,再基于日期,粒度不好划分,并且日期不是表连接的关键字。
Alvin 2009-06-01 22:14
@killkill
并行写入是参考了园子里的一些文章,提到写入时是分别写入同一文件组的不同文件中。
读取在SQL 2005联机帮助中则明确说明,多磁盘时文件分布在不同磁盘上可以提高查询速度。
关键是RAID5本身已经条带化,多磁盘好像不适用(偶对这个也比较糊涂)?
但是,基于朴素的想法,分别读几个较小的文件,肯定比对一个大文件快一些。
并行写入是参考了园子里的一些文章,提到写入时是分别写入同一文件组的不同文件中。
读取在SQL 2005联机帮助中则明确说明,多磁盘时文件分布在不同磁盘上可以提高查询速度。
关键是RAID5本身已经条带化,多磁盘好像不适用(偶对这个也比较糊涂)?
但是,基于朴素的想法,分别读几个较小的文件,肯定比对一个大文件快一些。
Keep Walking 2009-06-01 21:59
olap是最佳方案
表分区应该至少有个分区方案吧?
一般的分区方案是基于的日期,不知道你为何基于的记录数呢?
楼主的列名很有中国特色,哈哈
表分区应该至少有个分区方案吧?
一般的分区方案是基于的日期,不知道你为何基于的记录数呢?
楼主的列名很有中国特色,哈哈