参考 在文章Backdooring PE Files with Shellcode中介绍了一种在正常程序中注入shellcode的方式，让程序以前的逻辑照常能够正常运行，下面复现一下并解决几个小问题。...文件的前后各插入20-40个字节，以90填充 在目标exe中添加一个新的代码段，将bin的内容导入，并设置可读、可写、可执行、包含代码等属性标志 更新header大小以及重建PE头 使用x32dbg调试...ESP值，例如0x010FFBB8，发现少了0x204 为了能够恢复之前的寄存器状态，在shellcode最后追加指令add esp, 0x204 追加popfd和popad指令，和push顺序相反 将第...PE头大小是和最终的PE头大小是一致的，检查第4步操作 每次调试exe的时候，基址可能会发生变化，所以复制的指令只能用于修改当前调式实例 在复制jmp指令的机器码的时候，注意不要和目标跳转位置太近，会复制成短地址的指令...问题3：在监听端失联的情况下，程序长时间阻塞后程序终止 应该是检查服务端失联的情况下直接终止程序了，通过调试找到终止位置nop掉即可 ?
实现思路 我们的目的是在不引入外部SDK，业务代码方完全无感知的情况下实现页面的日志采集功能。...在此之前，需要保证项目中除了日志服务之外其他的请求都会经过一个入口方法，因为 我们会将日志信息进行聚合，避免发送过多的请求以减轻日志服务器的压力。...正常情况下我们会在进入页面时发送日志信息，但是用户在每个页面的停留时间我们将很难统计到。...因此考虑在离开页面时发送日志信息，并且在页面跳转时将上一个页面的一些信息也一并加入日志信息中。 客户端日志发送 在Vue中我们将在router.afterEach钩子函数里做这个操作。...因为是在页面跳转之后发送请求，所以此时将end置为当前时间。在发送完日志之后进入页面，将start设置为当前时间。
10倍，但经过训练，它们能够做出同样精确的预测，在某些情况下比原始网络更快。...这项研究计划在新奥尔良举行的国际学习代表大会（ICLR）上发表，在大约1600份提交的论文中，它被列为会议的前两名论文之一。 如果初始网络没有那么大，为什么不能在一开始就创建一个大小合适的网络呢？...但是，我们仍然需要一种技术，在不先看到中奖号码的情况下找到赢家。” ? 研究人员的方法涉及消除神经元之间不必要的连接，以使其适应低功率设备，这一过程通常称为修剪。...他们特别选择了具有最低“权重”的连接，这表明它们是最不重要的。 接下来，他们在没有修剪连接的情况下训练网络并重置权重，在修剪其他连接后，他们确定了在不影响模型预测能力的情况下可以去除多少。...在一系列条件下，在不同网络上重复该过程数万次之后，团队报告说AI模型的规模始终比其完全连接的父网络的大小要小10％到20％。
图片在高并发的情况下，Redis事务可能会遇到以下问题：1....阻塞问题：在高并发情况下，如果Redis服务器在执行事务期间发生阻塞，例如执行一个耗时较长的命令，会影响其他等待执行的事务。...数据竞争问题：在高并发情况下，多个客户端同时提交事务，可能会导致事务执行的不确定性和数据竞争问题。 解决办法： 在Redis中，可以使用乐观锁和悲观锁来解决数据竞争问题。...请注意，以上问题都是在Redis的事务场景下可能遇到的问题，并非Redis本身的限制，因此需要根据具体业务场景和需求来选择适当的解决办法。...在Redis中，事务（Transaction）是一连串的命令集合，它们按顺序被一起执行。当执行事务过程中的某个命令失败时，Redis会继续执行事务中的后续命令，而不会回滚已经执行的命令。
标签：VBA 下面介绍一个使用少量VBA代码实现的简单实用的小技巧。 通常情况下，我们执行“保护工作簿”命令后，此时删除工作表的命令变成灰色，用户就不能轻易地删除工作表了。...然而，这样也不能进行插入、移动或复制工作表的操作了。 如果想要在不保护工作簿的情况下防止用户删除工作表，而且允许用户插入工作表并对其进行重命名，也允许用户移动或复制工作表，有没有什么好的方法实现？...在工作簿的ThisWorkbook模块中粘贴或输入下面的代码： Option Explicit Private Sub Workbook_SheetDeactivate(ByVal Sh As Object...ThisWorkbook.RemoveProtection" End Sub Sub RemoveProtection() '撤销保护工作簿 ThisWorkbook.Unprotect End Sub 此时，用户再要删除该工作簿中的工作表...的警告信息（如下图1所示），但用户仍可以在该工作簿中进行添加工作表、移动或复制工作表、对工作表重命名等操作。 图1
♣ 题目部分 在Oracle中，控制文件在缺失归档日志的情况下的恢复步骤有哪些？ ♣ 答案部分 在恢复控制文件时“recover database”命令可能需要使用归档日志。...所谓缺失归档日志，是指控制文件从备份还原之后，在执行“recover database”命令恢复时报告找不到相应的日志导致恢复终止的情况。...这种情况下的恢复操作主要步骤如下： ① 首先还原控制文件，方式不限。 ② 执行“recover database”命令将报RMAN-06054错误，即找不到某归档日志。...⑤ 再次执行“recover database”命令，还会报RMAN-06054错误，这次是找不到另一个归档日志，其序列号应该大于第二步中的。 ⑥ 查看v$log视图确定第5步中所要的是哪个日志。...& 说明： 有关控制文件在缺失归档日志的情况下的恢复可以参考我的BLOG：http://blog.itpub.net/26736162/viewspace-2152115/ 本文选自《Oracle程序员面试笔试宝典
另注：从pg 10以后，clog改名为xact，主要原因，是很多人习惯性地使用*log删除日志文件，总是会不小心删除掉原先的xlog与clog文件，导致数据库不可用，所以分别改名为wal与xact，后文依然以...除了理所当前的各路文本记录（比方数据库的运行报错日志之类），PG的二进制类日志文件主要有两个，一个就是对应传统数据库理论的redo日志，理论上，所有数据的修改操作都会被记录到这个日志，在事务提交的时候确保操作都记录到磁盘中...看到这里，就可以明白，只要事务提交的时候，设置状态为已提交，而事务回滚的时候，设置状态为已中断，就可以达到目的，的确避免了操作数百万行的事务突然要回滚时候的巨大代价。...在32位xid的情况下，假设xid限制是20亿，每个8K的clog页存储32k事务位的情况下，clog最大也才五百来MB，这部分交给操作系统的文件缓存足以保障访问效率了。 真是一个绝妙的主意不是么？...如果不考虑64位xid的情况下，clog大小完全不可控的情况的话。 还是把话题集中在clog，下面我们来探讨的是，当事务提交或者回滚的时候，其内部的运作机理又是如何呢？
01 delete一张大表引发的一点思考 今天上班的时候接收到了一个业务方的反馈，说是一个数据库在删除表的时候报错了，我让他截给我日志看看，日志中的内容如下： 语句：delete from...，是在删除一张表的时候出现了锁等待超时问题，系统提示"尝试重新开启事务"。...这里需要说明一下delete大表的时候带来的影响，delete一张大表的时候，如果记录数太多，则需要锁住很多数据，这个操作将占满整个事务日志，耗尽系统资源，阻塞很多小的但是很重要的查询语句。...2、优化删除的SQL，在这个例子中，其实id是有主键的，我当时想到的是这个日志表是按照时间的顺序增长的，而id也是增长的，如果我们知道删除某一段时间的日志的SQL，可以通过查询时间和id的对应关系，将它转化为删除某一个区间内...，这样过滤的记录数也变小了，不再是4788万行了，进行删除的时候也没有报错了。
背景 有开发者、甚至公司可能会遇到过以下几个问题： 最开始 Fork 了一个仓库，之后做了大量的修改，从功能到开发语言，已经与父仓库各自发展了 由于是 Fork 的仓库，在每次提 Pull Request...的默认目标分支是父仓库，一不注意就会提 PR 到父仓库里去了 Fork 的仓库有人贡献并使用了，但不能显示贡献者，以及该项目被哪些其他的项目所使用，这不利于项目的发展 基于这些问题，开发者会考虑与父仓库进行分离...如果直接删除项目并重建可以达到分离的目的，但这样会丢失一些重要的信息，比如项目中的 Issues，Wikis 以及 Pull Requests 等。...解决办法 在经过一番调查和测试，目前最可行的办法就是通过 GitHub Support 来处理，具体操作如下： 打开这个链接：https://support.github.com/contact?...tags=rr-forks 选择你的账户或是组织，然后在 Subject 中输入 "unfork" 会自动弹出虚拟助手，选择虚拟机助手 然后根据虚拟助手的问题然后选择答案（如下是部分截图） 最后这些对话会自动转换成文字脚本
后来事务失败，插入操作全部回滚，新分配的一些数据块还是存在的） 原因在于：在所有多用户系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要功能之一就是协调对数据的并发访问。...这张表应该是经常进行新增删除操作的表，比如我新增了1000万行数据，然后又将这些数据删除。对这个表进行全表扫描的时候，仍然会去扫描这1000万行以前所占用的那些数据块，看看里面是否包含数据。...回退条目=块信息(在事务中发生改动的块的编号)+在事务提交前存储在块中的数据 在每一个回退段中oracle都为其维护一张“事务表” 在事务表中记录着与该回退段中所有回退条目相关的事务编号（事务SCN&回退条目...commit 提交事务前完成的工作： ·在SGA区的回退缓存中生成该事务的回退条目。在回退条目中保存有该事务所修改的数据的原始版本。 ·在SGA区的重做日志缓存中生成该事务的重做记录。...·LGWR后进进程将SGA区重做日志缓存中的重做记录写入联机重做日志文件。在写入重做日志的同时还将写入该事务的SCN。 ·Oracle服务进程释放事务所使用的所有记录锁与表锁。
需更新一个数据页时： 页在内存，直接更新 页不在内存，在不影响数据一致性下，InooDB会将这些更新操作缓存于change buffer，而无需从磁盘读入页 在下次查询访问该数据页时，才将数据页读入内存...写多读少业务，页面在写完后马上被访问到的概率较小，change buffer使用效果最好。常见为账单、日志类系统。...这种情况下，本文意义在于，如果碰上大量插入数据慢、内存命中率低时，多提供一个排查思路。 然后，在一些“归档库”的场景，可考虑使用唯一索引的。比如，线上数据只需保留半年，然后历史数据保存在归档库。...问题思考 在构造第一个例子的过程，通过session A的配合，让session B删除数据后又重新插入一遍数据，然后就发现explain结果中，rows字段从10001变成37000多。...但是，session A开启了事务并没有提交，所以之前插入的10万行数据是不能删除的。这样，之前的数据每行数据都有两个版本，旧版本是delete之前数据，新版本是标记deleted的数据。
4.2 general log分析 场景2-1：全表归档，删除原表数据，非批量插入，非批量删除 从日志看起来，源库的查询和目标库的插入有先后顺序 从日志看起来，目标库的插入和源库的删除，并无先后顺序...COMMIT(对应参数--txn-size，操作数量达到--txn-size，则commit) 场景2-2：全表归档，删除原表数据，批量插入，批量删除 从日志看起来，源库的批量查询和目标库的批量插入有先后顺序...从日志看起来，目标库的批量插入和源库的批量删除，并无先后顺序。...只要不加上--quiet，默认情况下pt-archive都会输出执行过程的 --charset=UTF8 指定字符集为UTF8 --no-delete 表示不删除原来的数据，注意：如果不指定此参数，所有处理完成后...，都会清理原表中的数据 --bulk-delete 批量删除source上的旧数据 --bulk-insert 批量插入数据到dest主机 (看dest的general log发现它是通过在dest主机上
其它情况下，change buffer都能提升更新性能。 普通索引和change buffer的配合使用，对于数据量大的表的更新优化还是明显的。...k2数据页不在内存 看如下流程： 带change buffer的更新流程 图中箭头都是后台操作，不影响更新的响应。...要读Page2时，需把Page2从磁盘读入内存，然后应用change buffer里的操作日志，生成一个正确版本并返回结果。可见直到需读Page2时，该数据页才被读入内存。...问题思考 在构造第一个例子的过程，通过session A的配合，让session B删除数据后又重新插入一遍数据，然后就发现explain结果中，rows字段从10001变成37000多。...但session A开启了事务并没有提交，所以之前插入的10万行数据是不能删除的。这样，之前的数据每行数据都有两个版本，旧版本是delete之前数据，新版本是标记deleted的数据。
原则上，高级别的压缩消耗更多的CPU。 这两个选项都可以在全局范围内和会话范围内动态设置。但是，不允许在事务中间更改。...GTID的情况下生成的，除了binlog.000142，所有二进制日志都是在上次重新启动后创建的。...在本例中，MySQL总计花了6.21秒进行二进制日志的压缩，每笔事务平均略低于400微秒。相比之下，MySQL总计花了4.8分钟在二进制日志文件上做I/O，这说明压缩在写日志的时间中占比很低。...单行删除：从sysbench测试中删除其中一个表中的所有10万行。这些行逐一删除，这是压缩的最坏情况，因为事务非常小，并且每个已删除行的二进制日志中只有前镜像。...随着事务大小变小，每笔事务压缩的相对效率降低，这对单行删除尤为明显。 需要考虑的另一个因素是压缩级别。
其它情况下，change buffer都能提升更新性能。 普通索引和change buffer的配合使用，对数据量大的表的更新优化还是明显的。...数据页不在内存 看如下流程： 带change buffer的更新流程 图中箭头都是后台操作，不影响更新请求的响应。...在构造第一个例子的过程，通过session A的配合，让session B删除数据后又重新插入一遍数据，然后就发现explain结果中，rows字段从10001变成37000多。...delete 语句删掉了所有的数据，然后再通过call idata()插入了10万行数据，看上去是覆盖了原来10万行。...但session A开启了事务并没有提交，所以之前插入的10万行数据是不能删除的。这样，之前的数据每行数据都有两个版本，旧版本是delete之前数据，新版本是标记deleted的数据。
InnoDB 日志文件的作用 Innodb 数据表崩溃后，再次启动时，MySQL会扫描日志文件，看哪些记录不在表空间中，对其进行 redo 操作，从而完成数据恢复 Innodb 日志文件的大小可以通过参数...设置一个合适的日志大小是比较重要的 如何计算出合适的日志大小 思路 设为多大是合适，没有明确的定义，但有一个经验值，就是设置为一个小时产生的日志量 可以通过命令查看一分钟内产生的日志大小，然后计算得出一小时的大小...计算方法 打开页面信息过滤，只显示含有“sequence”的行，否则信息太多 mysql> pager grep sequence; 查看当前的日志顺序号，就是总的bytes数 mysql> show...影响数据恢复的其他因素 在数据恢复过程中，除了redo，还可能会有 undo（撤销）的操作 例如在一个事务中删除10万行数据，没执行完就崩溃了，当根据日志做恢复时，由于事务并没有提交，便要撤销大量的删除操作...，从而延长了数据恢复过程 这就需要在操作数据库时注意，尽量避免大的事务，这样不仅可以提高数据恢复的效率，也会减少数据库主从复制的延迟
经排查发现，这是因为我们手动开启了事务切分，这种情况下大事务的原子性就无法保证，只能保证每个批次的小事务原子性，从整个任务的全局角度来看，数据出现了不一致。 那么该如何解决这个问题呢？...通过 TiSpark 直接读写 TiKV，相当于直接通过大事务读写 TiKV 的数据，可以保证事务的原子性和隔离性，同时拥有良好的写入性能，写入速度可以达到 300 万行/min。...用了 TiFlash 以后，既不影响 TiKV 的集群性能，也不影响线下的集群业务，而且在做离线大数据分析时，依然能够保持很好的性能与吞吐量。...比如日志数据存储在 Hive，数据库数据存储在 TiDB，跨数据源访问需要大量数据迁移，耗时且费力。能否直接打通不同数据源，实现跨源互访？针对这个问题网易游戏采用了 JSpark 工具。...应用场景：前端管理平台点击查询按钮，获取某玩家 Hive 链路日志和 TiDB 数据的联合聚合结果，提炼出相关行为数据。
2.delete from记录是一条条删的，所删除的每行记录都会进日志，而truncate一次性删掉整个页，因此日至里面只记录页释放，简言之，delete from更新日志，truncate基本不，所用的事务日志空间较少...3.delete from删空表后，会保留一个空的页，truncate在表中不会留有任何页。 4.当使用行锁执行 DELETE 语句时，将锁定表中各行以便删除。...总结 1.truncate和 delete只删除数据不删除表的结构(定义) drop语句将删除表的结构被依赖的约束(constrain),触发器(trigger),索引(index);...3.delete语句不影响表所占用的extent, 高水线(high watermark)保持原位置不动 显然drop语句将表所占用的空间全部释放 truncate 语句缺省情况下见空间释放到...想删除表,当然用drop 想保留表而将所有数据删除. 如果和事务无关,用truncate即可.
领取专属 10元无门槛券
手把手带您无忧上云
