事情是这样的：
这周末要重抽数据，哈哈。电脑忘在家里了，周末下午才回来。
然后就开始抽数。
结果出了错。显示数据被archive request给锁住了。
那就正好来把这个理一下。不然我一直迷迷糊糊的。
归档-archive
这个数据归档，我以前也没接触过。但是其实想想也该有这个。以前经验少，没考虑那么多。
历史数据
一般情况下，BW里面我们只保存5-10年的数据，那那些年头久远的，8、9、10年这种的，就给归档起来，如果有需要再重抽回来。
如果你用BW on HANA，数据库是HANA的话，那这么多历史数据都放内存里，那得花钱啊。为个大概率不会经常用的数据，浪费钱不值得。所以就有一个概念近线存储-Near line storage.
跑报表的时候也可以读到NLS的数据的。（前提是你设置成这个[X],因为默认是[0] Do not read…）
下面这个图是CP：这样底层ADSO有近线存储可以被读到。
有这个近线存储呢，是由于什么东西都是有生命周期的，所有的东西都有寿命，到时间就没价值了。就像衣服，就算没破，但是已经没型了，就该扔了。有些东西，就算完好如新，但是已经没有了存在的价值。信息也是的，数据还是那个数据，但是时代发展了，这个数据已经没价值了，到了信息的生命周期了。
按照数据的访问频率，我们给数据分为热、温、冷三种类型。
按类型存储在不同的内存空间。
而且还要考虑到最近的数据要最快速能访问到。
历史数据可以慢速访问。
而且由于法律法规，有些数据也要持续保留特定年限的。
但是到底怎么给这些数据分类呢？BW里面肯定有大量的平时不需要访问的数据。
看下面这个图，在LSA++的各个不同层上，有不同温度的数据。
看这个图，还是不明晰，Data Mart 层一般是可以出报表的层？
Staging Layer是数据持久储存层？这两个问句是真的我的问句。
看看SAP咋推荐的：
| 热 | P层和BT层 |
|---|---|
| 频率 | 经常被报表或其他process使用 |
| 如何使用 | EDW(Data Propagation Layer)和Architected Data Mart Area(Business Transformation Layer)包含经常被BW HANA和HANA functions访问的数据，比如说ADSO的激活流程或者query |
| 解决方案 | 在HAHA 数据库主内存中 |
| 特点 | 没有function 限制 |
| 温 | A层 |
|---|---|
| 频率 | 少数情况下被使用，不需要永久保存在主内存中 |
| 如何使用 | Staging Layer(Data Acquisition Layer)从源系统获取数据，只获取一次，以便准备和harmonize数据。然后数据等在这里，以后会被删掉或归档。数据在被更高层保存，转换后，可以被删掉或者归档。因为不需要再访问这个数据源了，可以把数据保存在另外一个内存里，以后也可以用来作为数据源的重建。 |
| 解决方案 | 在HANA的动态分层使用扩展表，注意HANA动态分层的验证条件 |
| 特点 | 没有function 限制 |
| 冷 | |
|---|---|
| 频率 | 数据在BW系统中不需要了，数据偶尔被访问，不需要保存在HANA数据库 |
| 如何使用 | 经过以短时间后，在热存储中的数据过了数据保存期，但是这类数据可能偶尔还会要访问。比如，最近两年的数据要放在热存储区，而早些的数据要放在HANA之外的冷存储区。BW数据归档会把这些冷数据写到near-line storage中， 比如SAP IQ |
| 解决方案 | SAP IQ作为近线存储解决方案 |
| 特点 | 由BW NLS限制，数据只能被读 |
上面讲到温数据的扩展表存储。
extended tables and near-line storage
这两个到底啥区别啊？
温存储用扩展表，冷存储用近线存储SAP IQ
实际上是因为，当数据从一开始的被频繁访问的热数据，到最后无人问津的冷数据。那它的地位变了，就得从热位置上下来，到冷位置去。SAP HANA区它就不能待了，就给它个归档区，但是还是可以被访问的。
SAP提供的是有SQP IQ的近线存储。跟扩展表的不同点就是，最开始的主数据区是HANA，一旦数据被保存到近线存储（一个单独的服务器），那HANA上就删掉它了。就好像热数据住中宫，温数据就随便一个偏宫吧，但是冷数据，那就别在皇宫里呆着了，直接宫外去吧。冷宫也不配的,搬出去之后原先宫殿直接给别人住了。但是呢，皇上想看你，你还是能被看的。而且，还有可能被接回来（reload).
| extended tables | near-line storage with SAP IQ |
|---|---|
| 在HANA中优化了主内存使用 | 在系统环境中优化了数据持久区 |
| 扩展表是平台不可分割的一部分 | 近线存储位于单独的服务器上 |
| 扩展表处理完整的表 | 近线存储处理选定的语义数据片 |
| 支持所有类型的数据操作（创建，读取，更新，删除） | 信息提供者的数据一次写入，然后只能读取 |
| 根据业务关键服务级别协议存储数据 | 使用低服务级别协议存储数据，为了降低成本 |
在初始Finance BI设置阶段不需要使用扩展表，所以温数据的处理方式和热数据一样的。都是放在HANA里面。
归档方法
根据有关数据生命周期的决策和数据归档需求，数据归档方法如下：
以下应该每个公司都不一样，根据要求来。
根据NLS空间大小决定保存的年限，比如这里10年后的数据会被从NLS中不可逆的删除掉。
注意，当你把超过三年的数据归档之后，数据就直接从info provider被删除了。
比如中间这一条archived request,最后的状态是显示被删除，而且锁定在NLS中。
归档参数
确定了归档方法，比如说超过三年都归档。
那接下来要确定归档的具体实施了。
而且基于每个ADSO都可能有不同的归档参数。
Data Archiving Process(DAP)确定不同归档参数。
一般用特性“过账日期”或者“财年”来进行归档。也就是说数据归档过程是基于时间特性的，而且DAP会使用Selection Profile“Time Slice Archiving”
另外默认归档时间区间是三年或两年。这个值是在归档请求中用“Relative Time Restriction”来配置，而且会比较当前日期和选定的时间特性。
这个具体看各家对数据的需求，再定计划。
唉，我每天没事看八卦的时间太长了。刚才就抽空看了下八卦，看了我一个小时。
现在再回来看archive。
归档参数按需求来分配。
归档操作
具体的归档怎么做呢？
我们上面已经确定了方法和参数。
接下来看看怎么弄：
ADSO的右键-> manage进来，然后点击manage archiving进入归档请求，外面是正常的抽数请求。
进到归档请求的界面，实际上能看到归档的和重抽的请求。
小图标不一样，如果归档了，那么还可以点最后一列的status状态，还可以执行重抽。重抽完成就会被从archive删除掉。
如果手动执行归档，那么就点最底下：archiving request
进入到配置参数界面：
selection conditions,这个是会计年度变量。
我们选K4，这个我得分开来写，因为这会我只知道皮毛，下次抽空写清楚。
选relative的话，像下面这个例子：是按年来的。
System Date: 12.06.2020
Only Data Records Older Than: 2 Years
Only Complete: Year(s)
所有2018年以前的数据都会archive，而2018、2019、2020年的数据还在 HANA中。
选Absolute的话，那就是可以精确填入年份：比如2018-2019.
futher restrictions可以选择client.选定client，限制数据量。
执行选择in the background.
- 一旦归档数据，那这个数据就会在NLS中被锁定。BW不能做更改。（因为都到另外的服务器中了）
- 相同的属性时间片的数据就不能在做一次归档了。也就是说你不能加新的或者更改的数据到已经归档的时间片数据中。（如果后续数据有更改，那你得reload回来，然后再做delta loading）
- 如果用relative选时间限制，那系统会建立不覆盖的新限制，比如：
-
Archive all data for client “521” with fiscal year <= 2014
-
Archive all data for client “521” with fiscal year <= 2016
第二个归档请求只会归档2015 和2016 年的数据，不会重复归档2014年以前的。
重抽-reload
如果你reload,那就会把原先锁定的这条归档数据解锁，而且会在这条archived上面显示个垃圾桶，表明已经被reload。而且会出现一条新的reload数据，reload之后的状态不可点击了。reload和archive请求的图标正好相反。
reload的前提是，你不能在NLS中删掉这个archive request。删掉可就没办法重抽了。
重抽结束就是从NLS被删除掉了，又回到了HANA中。
扫一扫
287
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
