flashback to timestamp 耗时

 flashback pluggable database XX to timestamp to_date('2024-02-26 13:11:56','yyyy-mm-dd hh24:mi:ss');

1TB 花费2小时,如果做了还原点好像很快

select   trunc( a.FIRST_TIME,'HH24'),count(*) from v$flashback_database_logfile a  group by trunc( a.FIRST_TIME,'HH24') order by 1;

TRUNC(A.FIRST_TIME,'HH24')   COUNT(*) 

26/02/2024 11:00:00 AM            117
26/02/2024 12:00:00 PM            119
26/02/2024 1:00:00 PM             117
26/02/2024 2:00:00 PM             143
26/02/2024 3:00:00 PM             166
26/02/2024 4:00:00 PM              48
26/02/2024 5:00:00 PM              25
26/02/2024 6:00:00 PM              29
26/02/2024 7:00:00 PM              17
26/02/2024 8:00:00 PM               1

69 rows selected


SQL> 

SQL> select distinct bytes from v$log ;

     BYTES
----------
2097152000

SQL> select distinct bytes from v$flashback_database_logfile ;

     BYTES
----------
2097152000

SELECT SID, decode(totalwork, 0, 0, round(100 * sofar/totalwork, 2)) "Percent", message "Message", start_time, elapsed_seconds, context, Time_remaining, inst_id 
from GV$session_longops
where  (SID = :sid  AND INST_ID = :inst_id AND SERIAL# = :SERIAL#)
ORDER BY SID

61.95    Flashback Database: Flashback Data Applied : 639419 out of 1032074 Megabytes done    26/02/2024 6:39:21 PM    4781    1    2936    1

----ALERT.LOG

flashback pluggable database PDB to timestamp to_date('2024-02-26 13:11:56','yyyy-mm-dd hh24:mi:ss')
2024-02-26T18:38:51.708082+08:00

--
Flashback Restore Start
2024-02-26T18:39:36.826902+08:00

--
Restore Flashback Pluggable Database PDB (4) until change 14687995287
Flashback Restore Complete
2024-02-26T20:51:48.339124+08:00


Flashback Media Recovery Start
2024-02-26T20:51:48.342610+08:00
Serial Media Recovery started
--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13504.55200.1161954227
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8517.35702.1161954223
2024-02-26T20:52:48.414607+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8518.39200.1161954255
2024-02-26T20:52:51.490107+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13505.17093.1161954353
2024-02-26T20:53:26.904154+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8519.54815.1161954283
2024-02-26T20:53:39.383717+08:00
Thread 1 advanced to log sequence 13915 (LGWR switch),  current SCN: 14705377679
--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8520.20688.1161954349
2024-02-26T20:54:35.053371+08:00
ARC1 (PID:26011): Archived Log entry 305637 added for T-1.S-13914 ID 0xe314bddd LAD:1
--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8521.52144.1161954371
2024-02-26T20:55:35.686146+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13506.3643.1161954495
2024-02-26T20:56:26.048895+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8522.24341.1161954421
2024-02-26T20:57:11.591965+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8523.21024.1161954493
2024-02-26T20:58:11.393814+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8524.15057.1161954549
2024-02-26T20:58:18.992720+08:00

--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13507.21890.1161954627
2024-02-26T20:58:53.672950+08:00

--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8525.16652.1161954595
2024-02-26T20:59:33.530424+08:00
Thread 1 advanced to log sequence 13916 (LGWR switch),  current SCN: 14705383076
--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8526.20148.1161954625
2024-02-26T21:00:25.702412+08:00
ARC2 (PID:26014): Archived Log entry 305639 added for T-1.S-13915 ID 0xe314bddd LAD:1
--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8527.5533.1161954653
2024-02-26T21:01:41.970995+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13508.21427.1161954661
2024-02-26T21:02:47.222020+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8528.44889.1161954679
2024-02-26T21:03:12.815217+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13509.12098.1161954693
2024-02-26T21:04:02.899066+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8529.36994.1161954707
2024-02-26T21:04:08.285176+08:00
Thread 1 advanced to log sequence 13917 (LGWR switch),  current SCN: 14705389678
--
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_1_seq_13510.25097.1161954729
2024-02-26T21:04:52.634305+08:00
Flashback Media Recovery Log +RECO01//ARCHIVELOG/2024_02_26/thread_2_seq_8530.37542.1161954733
2024-02-26T21:05:09.131946+08:00
ARC3 (PID:26017): Archived Log entry 305641 added for T-1.S-13916 ID 0xe314bddd LAD:1
--
Flashback Media Recovery Complete
2024-02-26T21:05:18.369174+08:00
Flashback Pluggable Database PDB (4) recovered until change 14688014921, at 02/26/2024 13:11:57
Completed:  flashback pluggable database PDB to timestamp to_date('2024-02-26 13:11:56','yyyy-mm-dd hh24:mi:ss')
2024-02-26T21:06:35.825426+08:00
alter  pluggable database PDB  open read only
[oracle@n2pdblinu0001 trace]$

---------------------------------------------------------

-----------------------------

According to Oracle® Database Backup and Recovery Basics 10g Release 2 (10.2), chapter 5.1.4.2
using restore points without flashback logging should cause each modified block to only be saved one time. Yet tests show that updating the SAME data blocks each time causes more flashback logs to be generated and the flash recovery area usage grows.

 

SOLUTION

The flashback data being generated is related to generation of UNDO and some changes to
SYSAUX due to AWR stats collection. Each update will generate REDO and UNDO and each block in the UNDO tablespace that is used for the first time, will require flashback data to be written. The
guideline figure is:

if your database is 1Gb then potentially, the flashback data where only a guaranteed restore point is used, should be at most 1Gb.-----保证还原点才是1:1,好像又不太对

---

After issuing any FLASHBACK DATABASE command, is there a way to monitor the progress of the flashback database? There is no entry in v$session_longops and nothing showing any progress in the alert.log.
 

SOLUTION

As with media recovery, flashback database will change the checkpoint_change# and checkpoint_time of the database files. So you should be able to query those two columns from v$datafile_header;

The first part of the flashback database uses the flashback logs to roughly get close to the SCN or time of the until clause. The last part uses the archivelogs to fine-grained get to the exact SCN or time. This means that the checkpoint_change# and checkpoint_time values should go backwards in time when working with the flashback logs, then go forward as redo is applied during the fine-grained media recovery of the last part.

SQL> select distinct checkpoint_change# , checkpoint_time     from v$datafile_header a where CON_ID=1;

CHECKPOINT_CHANGE# CHECKPOINT_TIME
------------------ ---------------
       14705316905 26/02/2024 8:13
       14705313228 26/02/2024 8:09
       14705326036 26/02/2024 8:13

 
SQL> select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=4;

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
       14687969687 26/02/2024 1:03 YES     YES

SQL>  select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=5;

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
       14705316905 26/02/2024 8:13 NO      YES

SQL> 
SQL> select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=2;

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
        5946401139 27/09/2023 9:42         NO

SQL> 

-----read write

SQL> select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=4;

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
       14705417495 26/02/2024 9:18 NO      YES
       14705414228 26/02/2024 9:17         NO

SQL>  select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=4;

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
       14705434827 26/02/2024 9:22 NO      YES

SQL> 

-----------------rollforward

SQL> select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=4;

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
       14688009767 26/02/2024 1:10 YES     YES

SQL>  select distinct checkpoint_change# , checkpoint_time, recover,fuzzy  from v$datafile_header a where CON_ID=4;
 
 

CHECKPOINT_CHANGE# CHECKPOINT_TIME RECOVER FUZZY
------------------ --------------- ------- -----
       14688014921 26/02/2024 1:11         NO

SQL> 

----flashback 第一步估算准确,第二步 估算了30000s!!!!实际 800s
100    Media Recovery: Log Files : 806 out of 806 Files done    26/02/2024 8:51:47 PM    802    4    0    1

100    Flashback Database: Flashback Data Applied : 1032074 out of 1032074 Megabytes done    26/02/2024 6:39:21 PM    7913    1    0    1
100    Media Recovery: Log Files : 806 out of 806 Files done    26/02/2024 8:51:47 PM    802    4    0    1
100    Media Recovery: Average Apply Rate : 33321 out of 33321 KB/sec done    26/02/2024 8:51:47 PM    803    2    0    1
100    Media Recovery: Redo Applied : 26129 out of 26129 Megabytes done    26/02/2024 8:51:47 PM    802    3    0    1
100    Media Recovery: Recovery ID : 1 out of 1 RCVID done    26/02/2024 8:51:47 PM    784    11    0    1
100    Media Recovery: Apply Time per Log : 34 out of 34 Seconds done    26/02/2024 8:51:47 PM    803    8    0    1
0    Media Recovery: Standby Apply Lag : 0 out of 0 Seconds done    26/02/2024 8:51:47 PM    803    10        1
100    Media Recovery: Elapsed Time : 803 out of 803 Seconds done    26/02/2024 8:51:47 PM    803    7    0    1
100    Media Recovery: Maximum Apply Rate : 59065 out of 59065 KB/sec done    26/02/2024 8:51:47 PM    803    2    0    1
100    Media Recovery: Active Apply Rate : 55715 out of 55715 KB/sec done    26/02/2024 8:51:47 PM    803    1    0    1
100    Media Recovery: Active Time : 751 out of 751 Seconds done    26/02/2024 8:51:47 PM    803    6    0    1
100    Media Recovery: Checkpoint Time per Log : 1 out of 1 Seconds done    26/02/2024 8:51:47 PM    803    9    0    1
100    Media Recovery: Last Applied Redo : 1 out of 1 SCN+Time done    26/02/2024 8:51:47 PM    802    5    0    1
0    Serial Media Recovery: Buffer Ping Time : 0 out of 0 Microseconds done    26/02/2024 8:51:59 PM    789    0        1
0    Serial Media Recovery: CV Applied Reapplied : 0 out of 0 Vectors done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: Total CV Processed Size : 385920 out of 385920 Bytes done    26/02/2024 8:51:59 PM    789    0    0    1
0    Serial Media Recovery: CV Applied Corrupt : 0 out of 0 Vectors done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: CV Applied Repair : 0 out of 0 Vectors done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Number of Redo Cache Full : 0 out of 0 Times done    26/02/2024 8:51:59 PM    790    0        1
0    Serial Media Recovery: Apply Delay Range (4,8] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Apply Delay Range (256, 1000] us : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Number of Reap Wait IO : 0 out of 0 Times done    26/02/2024 8:51:59 PM    789    0        1
0    Serial Media Recovery: Apply Delay Range (0,16] us : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: CV Applied OK : 2074 out of 2074 Vectors done    26/02/2024 8:51:59 PM    789    0    0    1
0    Serial Media Recovery: Apply Delay Range (64,256] us : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Number of Buffer Cache Full : 0 out of 0 Times done    26/02/2024 8:51:59 PM    789    0        1
100    Serial Media Recovery: Total CV Parsed : 2091 out of 2091 Times done    26/02/2024 8:51:59 PM    790    0    0    1
100    Serial Media Recovery: Number of Wait All Read : 13 out of 13 Times done    26/02/2024 8:51:59 PM    789    0    0    1
100    Serial Media Recovery: Total CV Applied : 2074 out of 2074 Vectors done    26/02/2024 8:51:59 PM    789    0    0    1
0    Serial Media Recovery: Apply Delay Range (64,128] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Apply Delay Range Unkown : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: Number of Redo Cache Copy : 408 out of 408 Entries done    26/02/2024 8:51:59 PM    790    0    0    1
0    Serial Media Recovery: Read Issue Time : 0 out of 0 Microseconds done    26/02/2024 8:51:59 PM    789    0        1
0    Serial Media Recovery: Apply Delay Range (2,4] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: Recovery ID : 1 out of 1 RCVID done    26/02/2024 8:51:59 PM    772    0    0    1
0    Serial Media Recovery: Apply Delay Range (1,2] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: CV Applied Ckpt : 0 out of 0 Vectors done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Apply Delay Range (128,1000] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Apply Delay Range (1,inf) s : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: Process ID : 1 out of 1 PID done    26/02/2024 8:51:59 PM    772    0    0    1
0    Serial Media Recovery: Number of Buffer Retries : 0 out of 0 Times done    26/02/2024 8:51:59 PM    789    0        1
0    Serial Media Recovery: Apply Delay Range (8,16] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Apply Delay Range (16,32] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: CV Applied Stuck : 0 out of 0 Vectors done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: Number of Read Request Issued : 14 out of 14 Times done    26/02/2024 8:51:59 PM    789    0    0    1
100    Serial Media Recovery: Number of Reap No Buffer : 1 out of 1 Times done    26/02/2024 8:51:59 PM    789    0    0    1
100    Serial Media Recovery: Number of Reap Request : 1 out of 1 Times done    26/02/2024 8:51:59 PM    789    0    0    1
0    Serial Media Recovery: Number of Unrcv Condition : 0 out of 0 Times done    26/02/2024 8:51:59 PM    789    0        1
0    Serial Media Recovery: Apply Delay Range (32,64] ms : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
100    Serial Media Recovery: Total Redo Read Bytes : 27404811776 out of 27404811776 Bytes done    26/02/2024 8:51:59 PM    790    0    0    1
0    Serial Media Recovery: Apply Delay Range (16,64] us : 0 out of 0 Counts done    26/02/2024 8:51:59 PM    791    0        1
0    Serial Media Recovery: Number of Buffer Pinged : 0 out of 0 Times done    26/02/2024 8:51:59 PM    789    0        1
100    Serial Media Recovery: Number of CV Cached : 408 out of 408 Entries done    26/02/2024 8:51:59 PM    790    0    0    1
100    Serial Media Recovery: Number of Influx Buffer Flushed : 40 out of 40 Times done    26/02/2024 8:51:59 PM    789    0    0    1
0    Serial Media Recovery: Number of Max Reads Issued : 0 out of 0 Times done    26/02/2024 8:51:59 PM    789    0        1
 


 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/705595.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

ADC制剂生产过程中的微粒控制-隧道烘箱在线粒子监测系统 中邦兴业

ADC制剂生产过程中的污染和交叉污染控制需要从多个方面入手,包括生产环境、设备、原辅料、生产过程、人员卫生和培训以及微生物监控等。只有全面、有效地实施这些控制措施,才能确保ADC制剂的质量和安全性。 ADC制剂生产过程中的微粒控制 ADC制剂生产中的…

StarRocks之监控管理(内含DashBoard模板)

先看下最终效果图 架构 Prometheus 是一个拥有多维度数据模型的、灵活的查询语句的时序数据库。它可以通过 Pull 或 Push 采集被监控系统的监控项,存入自身的时序数据库中。并且通过丰富的多维数据查询语言,满足用户的不同需求。 Grafana 是一个开源的 Metric 分析及可视化系…

右值引用的意义 以及 move函数,forward完美转发

文章目录 右值引用的意义move 函数forward 完美转发 右值引用的意义 直观意义: 为临时变量续命,也就是为右值续命,因为右值在表达式结束后就消亡了,如果想继续使用右值,那就会动用昂贵的拷贝构造函数。(关…

k8s 进阶实战笔记 | NFS 动态存储类的部署与使用

文章目录 NFS 动态存储类的部署与使用演示环境说明NFS subdir external provisioner准备 NFS 服务器手动部署 NFS Subdir External Provisioner部署 StorageClass验证使用更多信息 NFS 动态存储类的部署与使用 演示环境说明 演示环境信息:单机K3s 1.28.2 操作系统…

配置用户通过IPv6方式上网

组网需求 运营商为企业分配了WAN侧的IPv6地址1111:2222:A0EE:6::2/64和LAN侧的IPv6地址1111:3333:E840:2::1/64,企业通过运营商提供的IPv6地址配置上网。 图1 配置用户通过IPv6方式上网 操作步骤 1、在IPS上的配置 interface GigabitEthernet0/0/4 ipv6 enable…

代码随想录Leetcode377. 组合总和 Ⅳ

题目&#xff1a; 代码(首刷看解析 2024年2月27日&#xff09;&#xff1a; class Solution { public:// 思路&#xff1a;动态规划int combinationSum4(vector<int>& nums, int target) {// 1条件判断:无// 2定义dp 初始化 总和为target的数量vector<int> dp…

.NET高级面试指南专题十一【 设计模式介绍,为什么要用设计模式】

设计模式是软件工程中常用的解决特定问题的通用设计方法。它们提供了经过验证的解决方案&#xff0c;可用于解决在软件开发过程中经常遇到的一些常见问题。设计模式不是一种具体的编程语言特性或语法&#xff0c;而是一种通用的设计思想或模板&#xff0c;可以帮助开发人员设计…

【数电符号】9 Selectable Functions

1 AND 与门 2 OR 或门 3 NOT(Inverted) 非门 4 NAND 与非门 5 NOR 或非门 6 NANDOR 与或非门 … 7 XNOR 同或门 相同为1&#xff0c;不同为0 8 XOR 异或门 不同为1&#xff0c;相同为0 9 Buffer 缓冲器 也有不带施密特触发器的 //-----------Example---------------------…

基于springboot+vue的抗疫物资管理系统(前后端分离)

博主主页&#xff1a;猫头鹰源码 博主简介&#xff1a;Java领域优质创作者、CSDN博客专家、阿里云专家博主、公司架构师、全网粉丝5万、专注Java技术领域和毕业设计项目实战&#xff0c;欢迎高校老师\讲师\同行交流合作 ​主要内容&#xff1a;毕业设计(Javaweb项目|小程序|Pyt…

c++数据结构算法复习基础--1

一、大体复习内容 复习思路&#xff1b; 二、数据结构算法-常见复杂度汇总介绍-性能对比-图表展示 数据结构: 相互之间存在一种或者多种特定关系的数据元素的集合。在逻辑上可以分为线性结构&#xff0c;散列结构、树形结构&#xff0c;图形结构等等。 数据结构说的是组织…

kubectl使用及源码阅读

目录 概述实践样例yaml 中的必须字段 kubectl 代码原理kubectl 命令行设置pprof 抓取火焰图kubectl 中的 cobra 七大分组命令kubectl createcreateCmd中的builder模式createCmd中的visitor访问者模式外层VisitorFunc分析 结束 概述 k8s 版本 v1.24.16 kubectl的职责 1.主要的…

vue基础概念(1)

1. 前言 此项目基于vue2开发 1.1. vue组件 1.2. 文本插值表达式 用于返回data方法中的对象属性 也可以用于数据判断例如{{age >xx ? 老年 &#xff1a;青年}} 1.3. 属性绑定 v-bind :xxx 一般用于input输入框等 1.4. 事件绑定 v-on 1.5. 双向绑定 v-model 表单输入项…

UTONMOS元宇宙游戏发展趋势是什么?

UTONMOS元宇宙游戏的发展趋势包括以下几个方面&#xff1a; 更加真实的体验&#xff1a;随着技术的进步&#xff0c;UTONMOS元宇宙游戏将提供更加逼真的视觉、听觉和触觉体验&#xff0c;让玩家更加身临其境。 社交互动&#xff1a;UTONMOS元宇宙游戏将越来越注重社交互动&am…

记录一次主机不能登录的异常现象解决的问题

故障现象:客户5台云主机不能root登录,提示认证失败。 发现每次都会在/etc/host.deny 文件夹里面出现&#xff56;&#xff50;&#xff4e;的内网地址 经过仔细排查发现&#xff1a; 客户在进行等保整改的时候&#xff0c;修改了&#xff0f;&#xff45;&#xff54;&…

算法竞赛备赛之斜率优化的DP问题

目录 1.任务安排1 2.任务安排2 3.任务安排3 4.运输小猫 在处理下图的最小截距问题上面&#xff0c;我们该如何在维护的凸包中找到战距最小的点&#xff1f; 相当于在一个单调的队列中&#xff0c;找到第一个大于某一个数的点。 斜率单调递增&#xff0c;新加的点的横坐标也…

如何判断一个元素是否在可视区域中?

文章目录 一、用途二、实现方式offsetTop、scrollTopgetBoundingClientRectIntersection Observer创建观察者传入被观察者 三、案例分析参考文献 一、用途 可视区域即我们浏览网页的设备肉眼可见的区域&#xff0c;如下图 在日常开发中&#xff0c;我们经常需要判断目标元素是…

AcWing 860. 染色法判定二分图

本题链接 &#xff1a;活动 - AcWing 题目&#xff1a; 样例&#xff1a; 输入 4 4 1 3 1 4 2 3 2 4 输出 Yes 思路&#xff1a; 根据题目意思&#xff0c;我们明确一下二分图的含义。 二分图是图论中的一个重要概念。一个图被称为二分图&#xff0c;当且仅当能够将其所有顶…

今日早报 每日精选15条新闻简报 每天一分钟 知晓天下事 2月27日,星期二

每天一分钟&#xff0c;知晓天下事&#xff01; 2024年2月27日 星期二 农历正月十八 1、 应急管理部&#xff1a;彻查各类消防隐患&#xff0c;集中治理电动自行车进楼入户。 2、 电动车引发火灾事故频发&#xff0c;强制性国家标准即将出台。 3、 医保局&#xff1a;近年来纳…

vite+vue3图片引入方式不生效解决方案

vitevue3图片引入方式不生效解决方案 引入方式改成 const wordImgnew URL(/src/assets/MicsosoftWord.png,import.meta.url).href;原理

代码随想录Leetcode518. 零钱兑换 II

题目&#xff1a; 代码(首刷看解析&#xff09;&#xff1a; 这里的这个递推公式可以这么理解&#xff1a; 想象二维数组dp[ i ][ j ]其中i表示用前i种硬币&#xff0c;j表示价值总金额。dp[i][j]表示总方法数量。 那么dp[i][j]意义为&#xff1a; 用前i种硬币凑j的价值&…